<div dir="ltr"><div><div>Erik Anderson:<br><div id=":33i">
<br>> UDT is not a replacement for TCP or UDP - it is a data transfer protocol<br>
> built on top of UDP, with some additional TCP-like features to aid in data<br>
> integrity (negative ACKs to be specific).<br>
> <br><br>I understand that UDT isn't part of the kernel, but am not <br>sure why you disagree with the term replace.    <br>Here's an exchange I found on a forum.  The UDT author<br></div><div id=":33i">replies to the question with 3 paragraphs.<br>
</div><div id=":33i"><br>"Can you provide some data on how the protocol overhead <br>compares to TCP?"<br>
<br>
The UDT packet header is 4 bytes longer than TCP <br>(UDT/UDP/IP headers vs 
TCP/IP headers). Since UDT is at <br>user space, it uses more CPU (up to 2x,
 especially at low <br>throughput: the design of UDT makes it more efficient
 at <br>higher throughput) and also likely more memory buffers <br>are required 
(exact number is application specific but <br>usually it should not require 
significant more buffers).<br>
<br>
The TCP's throughput usually suffers significantly from <br>packet loss over
 long distance links due to its congestion <br>control algorithm. UDT has a 
new algorithm that can <br>overcome the problem.<br>
<br>
I am not recommending completely replacing TCP with <br>UDT. Instead, I 
think UDT can be a nice alternative as a <br>user option or when TCP 
connections cannot be setup <br>(e.g., due to firewall) or perform too 
poorly.<br><br></div><div id=":33i">------------  end of UDT author's reply -------------<br></div><div id=":33i">
<br></div><div id=":33i">Perhaps the person who suggested I consider UDT was <br>thinking about the long distance links the UDT author <br>mentions there.  Currently I have one location to serve <br>the world...<br></div>
<div id=":33i"><br>> I've never used UDT, so I can't speak specifically about it. In general,<br>
> though, my feelings on technologies like this is that they're great to<br>
> consider, if and only if they would solve a specific problem you're having.<br>> This isn't something you'd want to put into production just for the fun of<br>
> it. If you have a very high-speed network, say 10Gbps+, and you're<br>
> schlepping a *lot* of data around, it may be worth implementing.<br>
</div><br></div>I don't have a 10Gbps network or a specific problem yet.<br></div><div>I'm wanting to be prepared for future traffic like Noah <br></div><div>got ready for a flood he was warned about.  <br></div>
<div><div><br></div><div>I'm also thinking about using nginx instead of apache.<br></div><div>From what I've read --<br><a href="http://blog.zhuzhaoyuan.com/">http://blog.zhuzhaoyuan.com/</a><br>nginx is faster with static pages and that's all I have <br>
at the moment.   Nginx is smaller in terms of disk space <br>so that's in its favor.<br><br></div><div>-- <br><div dir="ltr">Brian Wood<br>Ebenezer Enterprises - in G-d we trust.<br><a href="http://webEbenezer.net" target="_blank">http://webEbenezer.net</a>          (651) 251-9384<br>
<br><br><br></div>
</div></div></div>