[MUD-Dev] Semireliable UDP-based protocol development

[Scott Hilbert]

This is not explicitly MUD-related, per se, but as this list has
attracted a lot of very experienced game networking specialists, I
thought it might be a good place to pick peoples' brains. :)

I'm currently working on developing a totally-free-license UDP-based
networking system for game use; higher layers are planned, but the
current focus is creating an efficient and reliable layer over UDP
to provide connection management and optional reliable
sending. (It's in C# right now, which isn't the most
down-to-the-bare-metal language, but it's proven to be surprisingly
fast, and it's what the rest of my current project is going to be
written in. A C++ port wouldn't be that hard somewhere down the
line.) This is about my third iteration at writing such a system
(having written some working prototypes in C++ a few years back),
and it's about 1/3 done right now, but I'd like to ask you guys for
some input on what methodologies are good and bad, to complement
actual efficiency testing.

The first issue regards using bitstreams rather than composing
packets at the byte level. So far this is how it's implemented, and
clearly doing so won't actually increase packet size for sending any
given amount of unique data. The downside, of course, is that it's
somewhat more computationally intensive; however, my routines are
pretty darned fast so far, such that the times look irrelevant
compared to the actual time of sending the packets. I've estimated
based on some simple tests that they would take around 1-2% of the
frame time at 100 FPS for an average "lower end desktop machine"
(~1.6 GHz) serving 64 clients to actually compose outgoing packets,
assuming that you're sending ~10 kB/s to each client. (This is, of
course, more of an extreme FPS style scenario.) You could probably
double the figure to account for packet parsing/decomposing on the
other side, given it's already somewhat rough.

So, the real question is whether anyone has found that the effort to
do things at the bit level really pays off. As it stands I'm very
happy with it, but I'd like to be aware if anyone has any horror
stories of things that go wrong with them before I have thousands of
lines permeated with them :P

Also, one of the things I'm trying out this time around is packet
coalescing. The code currently combines smaller packets into larger
physical UDP ones to save on header space. The actual goal size is
controlled by a target MTU setting, which doesn't have to be the
same as the actual network MTU, of course. So, the question here is
if anyone has any useful information to share about this technique,
and also any tips on what type of packet sizes are optimal for
saving header space while also avoiding waiting too long to send
packets and not becoming too large to cause trouble if they're
dropped. (Of course, the optimal size/wait times will change with
different connection types; I'm pretty much targeting DSL/Cable
currently, although any information regarding 56k connections is a
plus.) I would assume sending packets nearing the full MTU might be
pushing your luck as far as packet loss, but I haven't tested it
yet.

One last thing -- I'm planning on building a simple network
simulator program (i.e. listens on certain local ports and
artificially lags/reorders packets passing through it in realtime)
for testing and statistics gathering, but I haven't gotten around to
it yet. Does anyone know if there happen to be any (free) tools that
do similar things nowadays? I've only been able to find "network
simulators" in the sense that you draw out router diagrams and it
calculates traffic throughput and such.

I have some in-progress specs and the subversion repository
available if anyone wants to see them. However, they're both pretty
sparse and again, the code is roughly 1/3 done, so it wouldn't
really help posting them here at this point unless someone really
wants to see them. I'd rather not have more 'hype' than code at this
point. (Once the spec document is more fleshed out I'll gladly post
it, I'd love to hear comments.)

Hope I haven't put anyone to sleep with this ridiculously long
message ;)

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