Exactly. that's why i said 'for short scans and gets' and perhaps a combo. As soon as it exceeds a frame, we'd rather not to mess with reassembly. But I agree it is most likely not worth it. Most likely reason for my latencies is not this.
On Thu, Apr 21, 2011 at 11:22 PM, Ted Dunning <tdunn...@maprtech.com> wrote: > Yeah... but with UDP you have to do packet reassembly yourself. > > And do source quench and all kinds of things. > > Been there. Done that. Don't recommend it unless it is your day job. > > We built the Veoh peer to peer system on UDP. It had compelling advantages > for us as we moved a terabit of data per second 5 years ago, but it was > distinctly non-trivial to get right. The benefits we had included: > > - we could make our flows very aggressive, but less aggressive than TCP. > That made them feel like smoke relative to web-surfing. (not a benefit > here) > > - we could handle thousands of connections if necessary (not a benefit here) > > - we could penetrate firewalls more easily by state spoofing (not a benefit > here) > > - our protocol did magical window reassembly from multiple sources (not a > benefit here) > > But getting this to work was weeks of work and months of testing with > thousands of different clients. I wouldn't want to repeat that without > serious reasons. > > > On Thu, Apr 21, 2011 at 11:12 PM, Dmitriy Lyubimov <dlie...@gmail.com>wrote: > >> > What do you see here D? >> >> I am not sure. I am not very good at understanding network frames. but >> tcp kind of spends a lot of resources to ensure the flow. While udp >> wouldn't bother with all that nonsense. >> >
