[MUD-Dev] UDP Revisted

David H. Loeser Jr. daklozar at home.com
Fri Oct 19 01:56:15 CEST 2001


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).

Underneath all of the above is the actual implementation of each
protocol.  TCP has four output states, IDLE, TRANSMIT, PERSIST,
RETRANSMIT. The state machine for input has numerous states, CLOSED,
LISTEN, SYN SENT, SYN RCVD, ESTABLISHED, CLOSE WAIT, LAST ACK, FIN
WAIT-1, CLOSING, TIME WAIT, FIN WAIT-2 and they are
interconnected. I tried to find a state machine for UDP... couldn't
find anything similar to what I located for TCP - so I can't compare
the state machines for the implementation of the protocols. I did
find an interesting chart that graphed the total lines of code that
were used to implement each major protocol as a percentage of the
total. Here are some comparison numbers:

  PROTOCOL    %LINES    %FUNCTIONS
  TCP          20.7%        22.3%
  SNMP         19.2%        19.6%
  OSPF         14.4%        14.4%
  IP           12.0%        13.6%
  ICMP          3.1%         2.2%
  RIP           3.2%         3.3%
  UDP           2.5%         2.2%

The Summary of this text (Internetworking with TCP/IP second edition
volume 2 ISBN:0-13-125527-4, Comer, Stevens) reads like this: An
analysis of the code provides few surprises. As expected, TCP
requires the most code because it provides the most services and
handles the most problems....

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...

Additionally, a quick look check of the MORPGs that have tried to
utilize TCP and haven't had much success in terms of server response
(or player enjoyment) and had to drop back and punt or retrofit,
should be enough of a reason to decide against TCP.

Hope that is helpful... it's nearly 2:AM and I'm out of Dew so I'm
finished -

Good Luck,
David "Dak Lozar" Loeser



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



More information about the mud-dev-archive mailing list