On Nov 30, 2007, at 12:09 AM, Francis Cianfrocca wrote:

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

That's good news. Does this mean their alternate information is  
contained in the UDP Payload?
				   
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

I saw the sequential number issue and the cryptography problem, but I  
figured two things.
a) These people aren't **that** stupid, so they probably know someway  
to protect against injection.
b) I was going to try to use some fast one-way encryption algorithm,  
and use public keys and a central server, if I bundled this with some  
other software.
b 1) Or i was going to  wrap something secure and simple around it,  
and figure out of to get the symmetric key across the net.

Thanks for your help anyways,
Ari