[MUD-Dev] UDP Revisted

[Daniel.Harman at barclayscapital.com]

From: Dave Rickey [mailto:daver at mythicentertainment.com]

> So you number your packets, and count them, and using a TCP stream
> inform the other end of the connection "packet 17 did not arrive".
> Using TCP for this purpose keeps you from having to error-check
> your error-checking (which would itself need it's own error
> checking....).  It eventually gets this message and retransmits
> packet 17.  Now, the tricky part here is to be sure not to
> over-write the data delivered by packet 63 (which is a more recent
> and accurate version of the same data) with that from 17.  This is
> essentially just a bunch of stacks, where lower-numbered datagrams
> cannot over-write more recent ones.

Hmm, interesting approach. When Brian mentioned using both together
not working too well due to syncronisation, I think he was referring
to using the TCP channel for the actual guaranteed channel rather
than for re-send requests. I can see where your approach works and
the other doesn't.

Of course the traditional approach, and the one I'm taking, is to
build some of TCPs reliability protocol into my UDP framework. I
don't need to 'error-check [my] error-checking' any more than TCP/IP
does, and it doesn't require any special case code.

The only advantage to a ground up approach over the type Dave
espouses, is that UDP sockets don't have the kind of per-socket
overhead that TCP ones have. Its really a scaleability issue, and
dependent on your requirements.

Having said that, the win2k TCP socket overhead has gone down by a
factor of 10 over win nt. With regard to Unix sockets, I have no
idea of what the costs are, they scale differently to NT.

Do you have non-reliable packets in DAoC Dave? I have no intention
on even resending location/heading information packets if they go
missing. I figure its easier to wait for the next update tick and
re-send than to go through a resend which is going to take
200ms+ping (round trip) assuming the first resend gets through.

> So the information received over UDP is not guaranteed to be
> complete, but it is guaranteed to be timely, and vice-versa for
> TCP.  For most applications in games operating in anything
> approaching real-time, timely trumps complete.
 
> Camelot uses both UDP and TCP normally, but is capable of
> operating on either one alone (with some degradation in either
> case).  If the system is operating purely on a TCP stream, players
> witness bursts of lag, if it is purely on UDP they see jumpiness
> and unreliability from health-bars, damage messages, and
> NPC/Player movement.  Both are usually problems with either
> firewalls or routers between them and the game servers.

AO is the only large multiplayer game I know that uses TCP. It
exhibits the symptoms mentioned above.

Dan
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev