unmanaged WinSock V.S. System.Net.Sockets

[Guest]

Hi,

I am about to write a performance critical application and I wonder what is the best way to implement it... Should I use the standart Win32 winsock DLL or should I rather use the new managed System.Net.Sockets library... from bench-marking tests I have done I have reached to the following conclusion:
Test description:
Bougth of the projects used a single IO Completion port for communication ( the managed proj used NetworkStream that use a common completion port internally ), bougth of the projects allocated the requiered memory apriory so the reception process will not require redundunt allocations.
the unmanaged C++ project resulted better performance, about 1.333 times of the managed project...
Taking those results in mind, I wonder...
1. Will microsoft keep supporting the 'old' winsock DLL ( which apparently give much better performance ) for porposes other then backword compatibility?
2. Does the .NET framework use the WinSock DLL or it rather communicate with the tcpip.sys driver directly through IOCTL calls?
3. What are the plans for Longhorn and for the next version of VS.NET? would the System.Net.Sockets library be optimized???

What should I choose to implement a performance critical application? unmanaged WinSock or System.Net.Sockets ?

Should I use Mixed mode C++? Would the wedby version of VS.NET have major changes for the Mixed mode C++?

Nadav
http://www.ddevel.com

 

[Steve McLellan]

Bear in mind that code you write as unmanaged code may not necessarily be
the best implementation in managed code; it's possible you could squeeze
some performance out of the managed version by structuring things
differently. .NET makes development time MUCH shorter; unmanaged c++ is
quicker for processor intensive applications. But the limiting factor here
will be network bandwidth; unless you're doing tonnes of real-time
processing on the data you shouldn't see a big performance difference. You
usually only see a performance hit for really intensive computation (image
processing, for example).

Try posting the benchmark code you used; one of the gurus may be able to
give you some pointers.

Steve

Hi,

I am about to write a performance critical application and I wonder what

is the best way to implement it... Should I use the standart Win32 winsock
DLL or should I rather use the new managed System.Net.Sockets library...
from bench-marking tests I have done I have reached to the following
conclusion:

Test description:
Bougth of the projects used a single IO Completion port for communication

( the managed proj used NetworkStream that use a common completion port
internally ), bougth of the projects allocated the requiered memory apriory
so the reception process will not require redundunt allocations.

the unmanaged C++ project resulted better performance, about 1.333 times of the managed project...
Taking those results in mind, I wonder...
1. Will microsoft keep supporting the 'old' winsock DLL ( which apparently

give much better performance ) for porposes other then backword
compatibility?

2. Does the .NET framework use the WinSock DLL or it rather communicate

with the tcpip.sys driver directly through IOCTL calls?

3. What are the plans for Longhorn and for the next version of VS.NET?

would the System.Net.Sockets library be optimized???

What should I choose to implement a performance critical application?

unmanaged WinSock or System.Net.Sockets ?

Should I use Mixed mode C++? Would the wedby version of VS.NET have major

changes for the Mixed mode C++?

 

[MikeFl]

You are correct there is a performance difference between the two as yo
note. We are looking at performance improvements to th
System.Net.Sockets class. Feel free to email (e-mail address removed) t
request a feature or performance improvement to any of the classes i
the System.Net namespace.

Btw, did you go with Winsock or System.Net for your project? I'd lik
to hear why you chose one over the other.


The system.net team blog: http://blogs.msdn.com/wndp


-Mike
http://blogs.msdn.com/mflasko[/url - MikeF