From: Francis Cianfrocca Date: 2007-12-01T00:35:43+09:00 Subject: Re: Custom Protocol ------=_Part_1162_22104536.1196436946082 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Nov 30, 2007 7:43 AM, thefed wrote: > > 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. > Strictly out of curiosity, what's your need for this protocol? Are you running up against the long-fat-pipe limitation in TCP? ------=_Part_1162_22104536.1196436946082--