> And to anyone that still considers UDP to be TCP's poor cousin and not robust
> enough to handle a mud, take a look at NFS -- its UDP :)
Gah. That was a poor example. Even the developers kindly
refer to it as "Network Failure System". It is not a very 'good'
example.
> UDP would allow:
> *multicast communications
> *streaming (which could lead to some really cool stuff)
> *vastly reduced network overhead
> I realize that in heavy lag conditions you'd lose a lot of packets, but we've
> all heard the excuse "I didn't see it -- it scrolled by too fast after I
> unfroze from lag." leading me to believe that lost data packets would not
> severely impact the majority of players. If a player wishes to see all that
> info, then there is no reason why the burden can't be shifted to the client
> side of the house. In fact, UDP can be configured to fire off variable byte
> size packets depending on network latency (many small packets in high lag,
> fewer giant packets in light lag -- a synced buffering system comes to mind).
> Of course, nanny.c and the extraction rules would need to be retooled for this
> to even begin to be possible (not to mention clients), but that's why I'm
> asking you guys for suggestions. Someone tell me this is a bad, bad idea. :)
Simply, you can do just about everything you can in UPD, in TCP,
and vicea-versa. (Almost - there are a few exceptions, like multicasting,
etc...ignore those for now, you'll really never have to use them in a mud
environment, and thats what I'm talking about). The main difference
between TCP and UDP is reliability. Simply, TCP makes sure that the data
packet makes it to the client, performs error checking, and the whole nine
yards, while UDP depends on the existing underlying protocol. TCP
delivers its packets in a nice ordered stream, retransmitting only
when an error has been recieved, whereas UPD fires off packet after
packet, assumedly until they reach their host.
What UPD leaves us with is a system which is more fit to be run
on a local-net scale, as UPD connections become increasingly unreliable
the larger the distance they must travel. The network traffic on this
local-net would be about the same as that of a tcp network, although the
computing power needed would be noticably less. Outside the local net,
you'd probably have to end up increasing network traffic in order to
achieve a packet delivery rate of a usable level. Let me be the first to
say "Bad! Bad!" =)
One of my first muds was based in Sweeden. While it was not
exactly a blazing fast connection for me, it was usually pretty good - lag
of 30 seconds about 20-30 times a day was not unexpected, but usually it
wasn't noticable. If this was a UPD mud, it would have been literally
unplayable. If there was any point of network congestion between Chicago
and Sweeden, the mud would effectively disappear.
Even the Stevens series of books define the protocols in the
following abbreviated manner:
TCP = reliable, full-duplex, byte-stream.
UPD = unlike tcp, which is a reliable protocol, there is
no guarentee that datagrams reach their destination.
For Muds, UPD = bad.
PjD
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/08/00 PST