[gameprogrammer] Re: Rich Interent Application System for Games

I'm using tcp in my roguelike specifically because it
requires very little bandwidth and in that scenario it
seems silly to have to worry about packet loss.
You should also keep in mind that since tcp is
lossless, it _will_ catch up in times of latency,
producing a rubber band effect in real-time
applications.  Anarchy Online demonstrated this issue
very vividly in their beta.  The rule that I've
adopted is this:  Use UDP for anything real-time
(shooter, rts, etc.) and save TCP for things like
authentication, turn-based games, or anything that
doesn't require sync'ing a lot of clients.
The Quake engines and variants use UDP exclusively,
but in the event that you're planning on having
something more massively multiplayer, you could keep a
socket open to each client, verifying that they're
still there while broadcasting your more
time-sensitive data in the background.

Those are just my thoughts on the matter, good luck
with your project, it sounds very interesting.

Vince~

--- Olof Bjarnason <olof.bjarnason@xxxxxxxxx> wrote:

> Yeah that's a good idea. Still, datagrams should be
> inherently faster
> than sockets - because sockets have at least one ACK
> message going
> underneath the surface. Please keep us updated of
> your progress!
> 
> /Olof
> 
> On 6/11/05, Chris Nystrom <cnystrom@xxxxxxxxx>
> wrote:
> > On 6/10/05, Chris Nystrom <cnystrom@xxxxxxxxx>
> wrote:
> > >=3D20
> > > Also, I do not really need the rpc ACK. I am
> using TCP and I have not
> > > seen any lost messages, and I have no mechanism
> to retransmit them or
> > > anything anway. In this new architecture, I am
> thinking that both
> > > channels can just stream thier data and not have
> to wait for
> > > responses. I am thinking that this should
> improve the speed by about
> > > 50%.
> >=20
> > Actually, now that I think about it, it might be
> significantly faster
> > than 50%. I was thinking that I would be saving
> the return trip with
> > the ACK, but if there is no ack and the data is
> just streamed out,
> > then the second message, or rpc call, would not
> have to even wait for
> > the first mesasge to arrive. It can go out
> immediately after the first
> > one.
> >=20
> > With a streaming protocol, a WAN would be like a
> dam. A dam takes a
> > while to fill up, but once it starts flowing, it
> flows at the same
> > rate as it did before. Likewise a streaming
> protocol should take a
> > while to start and stop (beacuse when you start it
> takes a while for
> > the first packet to get there, and when you say
> stop it takes a while
> > for the last packet to get there), but once it did
> start or stop it
> > should flow at pretty much the same rate as it
> does on a LAN.
> >=20
> > It would be like when you are talking over a very
> long distance voice
> > communication, like radio to astronaughts. for
> example. The voice is
> > transmitted at the same rate and so it sounds the
> same, you just have
> > to wait longer for the other person to get it, and
> to receive the
> > responce to it.
> >=20
> > However if I am waiting on an event it should
> still be at most a 50%
> > speed gain which should help, and if you are
> waiting on an event
> > perhaps speed is not quite so critical at this
> point anyway.
> >=20
> > I will find out.
> >=20
> > Chris
> >=20
> > --=3D20
> > E-Mail: Chris Nystrom <cnystrom@xxxxxxxxx>
> > Business: http://www.shaklee.net/austin
> > Blog: http://conversazione.blogspot.com/
> > AIM: nystromchris
> >=20
> >=20
> > ---------------------
> > To unsubscribe go to
> http://gameprogrammer.com/mailinglist.html
> >=20
> >=20
> >
> 
> 
> ---------------------
> To unsubscribe go to
> http://gameprogrammer.com/mailinglist.html
> 
> 
> 



                
__________________________________ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 


---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html

Other related posts: