What TCP-algorithm does dotnet use ?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

zing - 13 Mar 2006 11:55 GMT

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

Reply to this Message

Goran Sliskovic - 13 Mar 2006 12:59 GMT

> 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
[quoted text clipped - 7 lines]
> (For example TCP-Reno, TCP-Vegas, or maybe an even more recently
> developed algorithm ?)

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

Reply to this Message

zing - 14 Mar 2006 13:29 GMT

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-5
267d61f1b411033.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

Reply to this Message

John Bailo - 14 Mar 2006 16:26 GMT

> 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

That may be the case. What would concern me more is their implementation
of sockets in .NET That's where you'd find your bottleneck.

Reply to this Message

Goran Sliskovic - 14 Mar 2006 17:21 GMT

> 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-5
267d61f1b411033.mspx

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

This is the one.
...

....

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

Reply to this Message

Rate this thread:

What TCP-algorithm does dotnet use ?

Free Magazines