What TCP-algorithm does dotnet use ?

  • Thread starter Thread starter zing
  • Start date Start date
Z

zing

Our company is in the startup phase of a large project involving lots
of network traffic. At this point, I'm trying to find out whether TCP
will be fast enough for the task. I've read a few articles that promote
UDP, claiming that TCP is slow, mainly written by gamers. But I've also
read some articles by more scientific sources, which made it clear that
a lot of progress has been made during the last 15 years or so. I
actually find it quite hard to believe that TCP should be slow, unless
an algorithm from the early 90's is used.
My question is: can anyone tell me what TCP-algorithm is used by dotnet
(For example TCP-Reno, TCP-Vegas, or maybe an even more recently
developed algorithm ?)
 
zing said:
Our company is in the startup phase of a large project involving lots
of network traffic. At this point, I'm trying to find out whether TCP
will be fast enough for the task. I've read a few articles that promote
UDP, claiming that TCP is slow, mainly written by gamers. But I've also
read some articles by more scientific sources, which made it clear that
a lot of progress has been made during the last 15 years or so. I
actually find it quite hard to believe that TCP should be slow, unless
an algorithm from the early 90's is used.
My question is: can anyone tell me what TCP-algorithm is used by dotnet
(For example TCP-Reno, TCP-Vegas, or maybe an even more recently
developed algorithm ?)
Click to expand...

This does not depend on .NET framework, but rather on operating system. TCP
is not slow by definition, however if you need fine controll over timeouts
or improvements based on you specific netwerk requirements (TCP is general
purpose protocol) UDP offers much finer control. You have to implement flow
control, congestion control and error correction/retransmission yourself if
you use UDP (all come free with TCP). There are some parameters of TCP which
are configurable through socket interface, some through registry. TCP
registry parameters should not be changed by user application, which may
represent a problem.

There was a document on Microsoft site describing TCP/IP implementation in
w2k. As far as I rememeber, it was newer version of protocol with SACK
(selective acknowledgements).

Regards,
Goran
 
Thanks Goran,
The knowledge that the algorithm is part of the OS was of great help. I
found several interesting articles, I think one of them may be the one
you mentioned: http://rdweb.cns.vt.edu/public/notes/tcpip2000.pdf
http://technet2.microsoft.com/WindowsServer/en/Library/8032dd80-9d51-4ad7-8b57-5267d61f1b411033.mspx

The first link I got from this page:
http://rdweb.cns.vt.edu/public/notes/win2k-tcpip.htm
In this article, Carl Harris describes a shortcoming of the Win2k
implementation of tcp (which has been repaired in the 2003
implementation), which I believe may well be responsible for the
aforementioned claims that tcp is slow.

By now I'm quite convinced that the people at Microsoft have thought
things through pretty well and that it won't make much sense to write
any UDP stuff myself. Btw, Windows Vista will have a whole new
tcp-layer:
http://www.microsoft.com/technet/community/columns/cableguy/cg0905.mspx

Regards,
Zing
 
zing said:
Thanks Goran,
The knowledge that the algorithm is part of the OS was of great help. I
found several interesting articles, I think one of them may be the one
you mentioned: http://rdweb.cns.vt.edu/public/notes/tcpip2000.pdf
http://technet2.microsoft.com/WindowsServer/en/Library/8032dd80-9d51-4ad7-8b57-5267d61f1b411033.mspx

The first link I got from this page:
http://rdweb.cns.vt.edu/public/notes/win2k-tcpip.htm
Click to expand...

This is the one.
....
By now I'm quite convinced that the people at Microsoft have thought
things through pretty well and that it won't make much sense to write
any UDP stuff myself. Btw, Windows Vista will have a whole new
tcp-layer:
http://www.microsoft.com/technet/community/columns/cableguy/cg0905.mspx
Click to expand...
.....

Be carefull when choosing. Do tests in early phase and verify against
requirements early. You may find your self in troubles later in the project
if you fail to. Also, consider separating low level transport from rest of
your code (abstractions), so you can change without lot of problems.
Networking is extremly complex subject.

Beware that TCP timeouts are long (in range of minutes). There is a
difference if you connect to unreachable host and host that is connected to
network but has no service started. Also, retransmission can take lot of
time. In some situations, you can allow some packet loss (e.g. video
streaming). What you will actually choose is dependant on the problem you
are solving and your requierements.

Regards,
Goran
 
Back
Top