From: Francis Cianfrocca <garbagecat10@...>
Date: 2007-11-30T14:09:10+09:00
Subject: Re: Custom Protocol

------=_Part_10135_31892282.1196399353867
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Nov 29, 2007 9:52 PM, thefed <fedzor@gmail.com> wrote:

>
> On Nov 29, 2007, at 8:37 PM, Francis Cianfrocca wrote:
>
> > I'm planning to look the implementation over and give it a try.
> > Maybe even
> > wrap it as a Ruby extension. Based on my limited reading of the
> > spec, all of
> > the data needed to relate packets to streams goes into the UDP
> > packets. I'm
> > still seeing no need for you to use raw sockets.
>
> Where would you recommend, then, including the excess information?
> The Payload?
>

According to the spec,  the header of a UDT data packet is 16 bytes long.
That's going to the first 16 bytes of the UDP packet's data. You don't need
to do anything with the "UDP header" that IP looks at. This implementation
is completely in userland and not in IP-land, which is a positive thing.
(They could have defined another IP-level protocol instead, which would have
been a pain.)

However, I'm considerably less impressed with this protocol after reading
the spec, and I decided not to spend any time on it. There is no
straightforward way to do end-to-end encryption. They've redone from scratch
all of the painstaking work of congestion avoidance, etc. that has been
fine-tuned in TCP for decades. And who knows what kind of security
vulnerabilities they've introduced. For one thing, packet numbers are
sequential, a problem that TCP got rid of years ago.

>
> Also, is there a way to get C++ libraries loaded into C?
>
Look at the C wrapper in Ruby/EventMachine, which includes an extension
written in C++.

>
> Thanks again,
> ari
>
>

------=_Part_10135_31892282.1196399353867--