[MUD-Dev] datagrams

[Greg Underwood]

At 08:33 PM 4/27/00 +0200, Ola Fosheim Gr=F8stad wrote:
>The technicalities of Internet is not one of my strong points.  I'm
>trying to figure out what the best strategy for an UDP based protocol
>is, but I don't really have the pragmatic data which would make the
>process easier.
>
>1. What is the smallest datagram size that makes sense in combating
>packet loss? =20

Cant help you there.  My knowledge is mostly theoretical, with only a minor
amount of practical experience.  I should think there'd be a way to find
out on the fly...

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

mm.  Well, it sounds like you want to gaurentee transmission, which is not
really what UDP is designed for.  Basically, my understanding is that in
most real-world situations, if you want to make sure data gets through, you
should use TCP.  UDP is really only good if you don't mind loosing data
packets now and then, and if you try to build transmission gaurentees into
it, you will most likely have a less-efficient system than a plain old TCP
connection.

can you define more clearly what it is you want to do?  Are there just some
packets you want to gaurentee?

I've been leaning towards using 2 connections, one TCP and one UDP.  The
TCP connection would be used for stuff like conversation, while the UDP
would be used for sending room descriptions piece-meal, with different
information (sight, sound, etc) spread out across different packets.  That
way, the longer you stay in a room, the finer resolution of a description
is available. =20

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

Unless you have something like ScramNET (reflective memory) boards to
connect your machines, TCP and UDP between servers is fine.  As for the
overhead, again, it depends on whether you need to gaurentee transmission
or not.  Surprisingly enough, it's pretty easy to loose UDP packets even
over an ethernet patch cable.  If the sender or receiver gets a signal
during the recvfrom() call, blamo, no UDP packet for you.  Overhead should
not be the issue you choose between TCP and UDP on.

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

Most of the work I have done with UDP was for DoD simulation stuff... DIS
and HLA specifically.  Our approach is to usually send as many "events" per
packet as we can.  Internally, each event usually conveys just enough
information for the target system to ID the participating entities and
fulfill the event.  IE: a position update event contains entity ID,
position, velocity, orientation, and similar info for any articulated
parts.  If you're interested in the IEEE standard on DIS, a quick web
search should point you towards a copy of the standard.  IIRC, the IEEE
number is something like 1284-1 - 1992 or something.

Also, I recall bringing it up on the list in the past, so a search of the
archives will probably help too.

>(Please don't tell me that sticking to TCP is my best option, I know
>that already...)

Well, as I said, that depends on what you want to do.  :)

-Greg




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