[MUD-Dev] UDP Revisted

[Adam Martin]

----- Original Message -----
From: "David H. Loeser Jr." <daklozar at home.com>
> From: "Travis Nixon" <tnixon at avalanchesoftware.com>

>> Er, then I truly do not understand why you don't just use TCP.

>> Good point about the chat messages though.

>> If you've implemented ALL the features of TCP though, then why
>> aren't you just using TCP?  Brian mentioned sync issues, but
>> there's no reason that TCP packets and UDP packets couldn't get
>> put into a single container based on timestamp.  And most of the
>> sync issues are caused by the in-order requirement anyway, I'd
>> think.

>> Unless, of course, you've looked at the TCP implementation,
>> decided it sucked, and thought you could do better.  That's
>> certainly a valid reason.  But if you implement all the same
>> features, you have all the same problems.

>> Not criticizing, just trying to understand. :)

> Basically the difference between TCP and UDP are:

>   (I presume that you know or at least have a basic knowledge of
>   this but I post it for completeness)

> TCP is of course connection oriented and TCP provides all the
> reliability necessary for two (or more) machines to communicate
> across the internet. TCP verifies that the data arrives, and
> automatically retransmits segments that do not arrive. TCP
> computes a checksum over the data to guarantee that the data was
> not corrupted during transmission. It uses sequence numbers to
> ensure that the data arrives in order, and automatically
> eliminates duplicate packets. TCP provides flow control to ensure
> that the sender does not transmit data faster than the receiver
> can consume it. Finally, TCP informs both the client and server if
> the underlying network becomes inoperable for any reason.

> UDP is connectionless and there are no guarantees that the data is
> delivered. When UDP sends data, it may be lost, duplicated,
> delayed or delivered out of order, from both server and client (or
> client to client).

...

> I take the old adage that as a game programmer, I can write linked
> list code that will be faster and take up less memory than that
> canned list class that comes with the compiler (is my age showing,
> anyone remember writing 6502 assembly and searching for one free
> byte to use?). My (albeit elitist/programmers ego) attitude about
> TCP -vs.- UDP is inline with just that kind of thinking -- I will
> implement my own sequencing and by the way make it reliable
> guaranteeing that the data arrives ect...

To anyone who's not done a UDP-looking-like-TCP protocol before, I
urge them to look at the source for TCP to start with. You don't
want to end up being screwed unexpectedly by things like
collision-retransmit-timeouts. E.g. I managed to write a java
program that will bring any hub-based LAN to its knees (90%+ packet
loss) just because the [win32] implementation of RMI appears to be:

  1) Using UDP
  2) Use its own reliable-transport algorithm
  3) Appears to NOT use random back-offs.

So, where you get more than one client on the same LAN-segment, if
you're transmitting a reasonable amount of data (e.g.some
kilobytes), and two clients get a collision, the non-random-delay
back-off scheme ensures they both retry at almost precisely the same
time, and collide again. I think its obvious what happens next! I've
seen a 10Mbps LAN take several minutes to transfer what sould have
been a few hundred k in total from two clients to a server (no other
traffic on the LAN). This of course is exacerbated by the fact that
RMI adds an overhead of approximately 20-40 bytes (or even more!)
per 4-byte integer transferred. In case anyone is shocked at my
foolishness for using RMI, I was trying it out - and was severely
disappointed that it effectively can't handle raw data that comes to
more than maybe a few hundred bytes (then multiply this by 10-30)
without this behaviour.

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