[vworld-tech] Some resources for ... TCP UDP

[bradley newton haug]

> widely/freely available implementation around, but people have suggested
> several others to me, including:
>     RAKnet (sp?)

RakNet (available at http://www.rakkarsoft.com) is not a protocol, it's a
layer that sits on top of UDP and implements a lot of TCP-like behavior
(reliability, sequencing), and some other nice features (encryption).

<babble>

While its goals are admirable, it is done in C++ (I like c++ as a client
language, not as a library/low level language) and the author is prone to
blaming template problems and cross platform packing and ordering
differences on compilers instead of keeping up with the ever evolving c++
language.  I have used it as a client and server using vs7.1 on windows,
however though the author claims it works under un*x/linux, it does not
without some serious work.  Work I didn't feel like spending on a library
that was supposed to be saving me time.

Prior to that I tried a UDP/TCP hybrid, the advice I received was along the
lines of 'just use udp, moron', the sync problems were more than annoying, I
ran into situations where TCP retransmits would freeze the entire stack, and
low and behold, the udp side of it was doing just fine.  I even got to the
point where I was using udp to send debugging information about the total
mess that the TCP side had become.

I now use enet, it's C, it's simple, and it works.  The reason I like C over
C++ in lib use is its usually easier to bind to whatever internal language
your server uses.

You can find all the white papers and unimplemented tweaks you want, but
what you have to work with what is in use today, and next year, not what
might be in 5 years.

Another thing to consider (from a programming standpoint).  What would you,
as a programmer like to do (assuming you're a client of the networking
layer, and not the author), create command tokens to be streamed almost
blindly, or would you rather form your own packets containing discrete
casted structs, required only a cast on the receiving end to obtain raw
data.  With tcp you have to implement a parser that is operating on a
stream... looking for newlines or terminal chars on every single operation
seems clunky to me, and a lot more than a cast (which can be blind if you
have a reliability layer).   

It was also pointed out by Jeremy, that even if you use your own 'packet'
(misleading in the context of a networking protocol) you cannot control how
that packet gets ripped up, what happens to your parser when you get a
buffer from tcp that has half of one your data or tokens? What do you do
then? Do you wait? If you are doing it async then what happens when the rest
of it comes in?  So if you do it asyc you have to always be checking with
some kind of locking, and if you poll you're screwed if that other packet
comes in before timeout, nevermind whats going to happen when the other side
manages to retransmit after a disrupted connection.  You can get by some of
these problems, but you end up 'fixing' tcp, instead of just adding some
functionality to udp (which was created for this very reason).

To me, the best argument regarding udp was that *your* packets and structs
are *the* structs that are sent.  You don't need to parse, you don't need to
sit there with regexs, you have a packet, and you can check it's header and
that determines what it gets cast to.  You need reliability or sequencing?
Wrap it a little higher up with enet or roll your own and get back to the
task at hand.  Sending data structures across the net.

Debugging is another issue for the programming, as a the network programmer
would you rather sift though the soup of a captured stream for pre parsed
tokens (that you didn't implement) or see the data packet by packet (packet
in the datagram sense) in a context that makes sense with a quick glance at
a header file.

I'm certainly far from the most experienced networking coder around, but
from a system programming standpoint I just wanted to move structs from one
machine to another, and I use udp for the reasons listed above.  That and I
hate parsing.

</babble>

-brad