[MUD-Dev] datagrams

Ola Fosheim Grøstad <o.f.grostad@notam.uio Ola Fosheim Grøstad <o.f.grostad@notam.uio
Fri Apr 28 11:51:48 CEST 2000


Greg Underwood wrote:
> 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.

I need serial numbers to throw away duplicates. I do not want TCP,
because I don't want to delay data that isn't dependant on a information
contained in a lost packet. I also want a single simple protocol (Ok, I
am asking for more than I can easily get :) In an ideal world I should
utilize all kinds of dependency information, but my own sketches of such
approaches has turned out to be rather complicated, so I'll go for
something less ambitious and general...

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

ID overhead is one problem I need to resolve.  I developed a simple
protocol for TCP that would use bytes for IDs based on a most recently
used scheme.  With datagrams compressing IDs is not as easy.  I've
thought about establishing multiple contexts, but then the message
cannot be processed until I know that the receiver has the appropriate
context. What am I going to do if a message depends on a past context.
well, I would have to retain all contexts until they are "obviously" too
old to be useful. (Conclusion it is easier to be clever with TCP than
UDP, with the latter you risk being too clever :)

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

I want efficiency, flexibility and simplicity :P

--
Ola





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



More information about the mud-dev-archive mailing list