Re: Circle's net protocol

From: d. hall (dhall@APK.NET)
Date: 11/10/97


: thus on Sat, 8 Nov 1997 20:26:38 -0500, Big virtually wrote:

Big> I have been toying with this idea, and I'm asking you guys from some
Big> input: What are the pros and cons of redoing circle to make use of
Big> UDP?  I'm a network/software engineer, and may be because I use UDP, I
Big> can't take that objective "step back" and see the flaws, but I feel as
Big> though a good case could be made. UDP would allow: *multicast
Big> communications *streaming (which could lead to some really cool stuff)
Big> *vastly reduced network overhead I realize that in heavy lag
Big> conditions you'd lose a lot of packets, but we've all heard the excuse
Big> "I didn't see it -- it scrolled by too fast after I unfroze from lag."
Big> leading me to believe that lost data packets would not severely impact
Big> the majority of players.  If a player wishes to see all that info,
Big> then there is no reason why the burden can't be shifted to the client
Big> side of the house.  In fact, UDP can be configured to fire off
Big> variable byte size packets depending on network latency (many small
Big> packets in high lag, fewer giant packets in light lag -- a synced
Big> buffering system comes to mind). Of course, nanny.c and the extraction
Big> rules would need to be retooled for this to even begin to be possible
Big> (not to mention clients), but that's why I'm asking you guys for
Big> suggestions. Someone tell me this is a bad, bad idea. :) And to anyone
Big> that still considers UDP to be TCP's poor cousin and not robust enough
Big> to handle a mud, take a look at NFS -- its UDP :)

TCP can do MTU discovery, actually it's the only way to do MTU discovery,
TCP is a full duplex connection, it requires a connection.  There is
already a widely available client that does TCP, it's called telnet.  This
is the main reason as to why muds are so popular, the underlying client
doesn't have to be that great.

If you want a good example of a UCP client, netrek, the paradise server.
But then you limit yourself to those who have clients.

Multicasting in theory is very nice, and the mbone has been interesting to
play with, but I fail to see how multicasting helps in a mud environment.
The best pro for multicasting is the cut back in local area traffic caused
by broadcasting, the multicasted data only exceeds the datalink layer by
one step, the protocol layer, it never reachs transport layer.  This can be
a considerable savings in CPU, it doesn't apply to muds unless you want to
connect several servers togethers.

d.


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