[MUD-Dev] Re: datagrams

[Chris Gray]

[Ola Fosheim:]

> 1. What is the smallest datagram size that makes sense in combating
> packet loss?  Is 256 bytes too big in windy weather? It would be a
> relief if I could avoid splitting atomic messages like utterances (say,
> emote etc) over many datagrams and still have good performance. What is
> the best heuristic for switching to smaller/larger datagrams?

If you change your basic datagram size, how do you co-ordinate that size
change between sender and receiver? The receiver has a 'recv' call
outstanding - if that doesn't match the size that the sender sends,
can you recover?

At work, we've always used fixed size header packets, possibly followed
by some number of "tails", which are fully described by the initial
header. Just so happens that we used 256 byte headers. On UNIX systems,
this sort of scheme got us quite acceptable performance when about 2/3
of our messages were header-only. On Windows NT, the exact same code
ran abysmally, and we never were able to get decent performance. We
also tried using WIN32 named pipes, and they were better, but still
abysmal. Shrug!

> 2. Is serial numbering of messages and "acknowledge" messages from the
> recipient the best basic structure? (I probably should read a book on
> TCP/IP implementation gore, but I don't want to :). Or are there
> advantages with having the recipient request "lost serial numbers"?  How
> do I combat lost "acknowledge" messages? Should I send them multiple
> times in bad weather?

Sequence numbers work well. You can "piggy-back" them on other messages
in order to cut down on some overhead. That is, don't send an explicit
ACK message unless a short timeout has gone off since the message you
want to ACK arrived. Putting 3 or 4 acks/naks in the fixed header of
each message works pretty good. I believe TCP does something like that.

> 3. Do you use TCP or UDP between your own servers on your local network?
> Is the overhead with TCP large enough to warrant using UDP locally?

I use TCP for my binary protocol. UDP is a pain, and perhaps hard to get
going well on non-UNIX systems. We had to use UDP at work, but so far,
TCP has worked fine for my MUD client.

> 4. If somebody feel inclined to share the main structure used in their
> datagram based protocols, then please do so! :)

Hmm. I'd have to steal it from work, if you want the UDP stuff. It's
*possible* that it would be OK for me to send you the whole sources,
but I wouldn't bet on it! :-)

--
Don't design inefficiency in - it'll happen in the implementation.

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA
               http://www.GraySage.Edmonton.AB.CA/cg/



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