5 proposals to enhance network socket classes in .NET

[Boris]

I just posted 5 proposals to enhance network socket classes (the classes in
namespace System.Net.Sockets) in .NET at
http://usingvisualstudio.net/flexWiki/default.aspx/CTPWiki.SystemNetSockets.
If others commented on these or added more proposals how to improve network
socket classes we all would benefit (only if these proposals will be
implemented in .NET Framework 2.0 of course). However 4 of my 5 proposals
shouldn't be very difficult to implement (only providing a SSLSocket seems
to be a lot more of effort).

Boris

 

[Chris Mullins]

However 4 of my 5 proposals shouldn't be very difficult
to implement (only providing a SSLSocket seems
to be a lot more of effort).

The SSL Socket class is already in the Whibdey release of VS.NET.

Client Stream:
http://longhorn.msdn.microsoft.com/lhsdk/ref/ns/system.net/c/sslclientstream/sslclientstream.aspx

Server Stream:
http://longhorn.msdn.microsoft.com/lhsdk/ref/ns/system.net/c/sslserverstream/sslserverstream.aspx


For the current VS.NET, you can use the SSL socket provided by Mentalis,
found at mentalis.org.

 

[Boris]

The SSL Socket class is already in the Whibdey release of VS.NET.

Ah, I updated my wish list and removed SSL Socket.

[...]
For the current VS.NET, you can use the SSL socket provided by
Mentalis, found at mentalis.org.

Thanks, looks good. However it could be improved as eg. their SecureSocket
class is not derived from System.Net.Sockets.Socket (so you can't use it
with Socket.Select()). I hope .NET 2.0 will provide a more consistent
approach and support non-blocking SSL sockets, too.

Boris

 

[Chris Mullins]

Thanks, looks good. However it could be improved as eg. their
SecureSocket class is not derived from
System.Net.Sockets.Socket (so you can't use it with Socket.Select()).

I think that's a feature - not a drawback.

Why would you be using Socket.Select with the .NET Framework? The Async
Methods are going to perform alot better and are really quite excellent.

 

[Boris]

I think that's a feature - not a drawback.

Why would you be using Socket.Select with the .NET Framework? The
Async Methods are going to perform alot better and are really quite
excellent.

Not if your server needs to serve hundreds or more clients concurrently. If
I understand the Async Methods correctly they use background threads so you
would have hundreds of them. It's even worse when the clients have to
interact with each other because of synchronizing issues.

However I am interested in why you think Async Methods perfom (in general)
better than Socket.Select()?

Boris

 

[Chris Mullins]

Not if your server needs to serve hundreds or more clients concurrently.

For that exact reason, the async methods are signifigantly better. When
using the Async methods, you get to bring the complete I/O Completion Port
infrastructure along for the ride. This makes for a highly scalable server.

The socket.select stuff isn't going to give you that same infrastructure.

However I am interested in why you think Async Methods perfom (in general)
better than Socket.Select()?

Using the Socket.Select (BSD style sockets) you're leaving the entire IOCP
infrastructure unused. This is the most powerfully socket interfaces there
is on Windows. Without it, you have to manage your own threading, your own
events, and all sorts of other things that the Windows Kernal is
signifagantly better at than code you write yourself is ever going to be.
The IOCP thread pool is excellent at performing these opertions quickly and
in a very reliable manner.

The Async Socket stuff has no troubles scaling to (on a Win2K3 machine with
enough ram) 50K simultanious TCP sockets connected to it and sending /
receiving data at an IM type pace. Even this limitation is due to the 2GB
per process barrier in Win32 rather than any socket limitations.

I've written big network apps (that's what I do for a living) using both
mechanisms, and would not willingly return to the Socket.Select methodology.

 

[William Stacey [MVP]]

Is it documented somewhere that the async methods use IOCP? I thought they
were just async wrappers around the same sync versions? TIA

 

[Chris Mullins]

Is it documented somewhere that the async methods use IOCP? I
thought they were just async wrappers around the same sync versions?

I can't find it "officially" documented anywhere, but:

I heard a rumor (I would never disassemble MS code) that if you used
Reflector (http://www.aisto.com/roeder/dotnet/) , and looked at the Socket
Class, there is a method "BindToCompletionPort" that is called from
EnableCompletionPort, which in turn is called by SetUnmanagesStructures,
which in turn is called by BeginSend and BeginReceive.

In the event this rumor is true (which is, I gotta say, pretty darn likley)
it seems like pretty conclusive proof that the AsyncSocket stuff in .NET is
indeed using IOCP.

 

[William Stacey [MVP]]

Thanks Chris. That is good to know. Reflector is a friend. I will look
harder at it.

 

[Feroze [MSFT]]

Yes! Socket uses IOCompletionPorts on platforms that support it (NT). On 9x
platforms, it uses Overlapped I/O.

Either way, we dont simulate async by creating a background thread and doing
sync on it.

Thanks.

--
feroze
http://weblogs.asp.net/feroze_daud
============

Remove "user" from the email address to reply to the author.

This posting is provided "AS IS" with no warranties, and confers no rights

Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Is it documented somewhere that the async methods use IOCP? I thought they
were just async wrappers around the same sync versions? TIA

 

[William Stacey [MVP]]

Thanks for the info. Cheers!

--
William Stacey, MVP

Yes! Socket uses IOCompletionPorts on platforms that support it (NT). On 9x
platforms, it uses Overlapped I/O.

Either way, we dont simulate async by creating a background thread and doing
sync on it.

Thanks.

--
feroze
http://weblogs.asp.net/feroze_daud
============

Remove "user" from the email address to reply to the author.

This posting is provided "AS IS" with no warranties, and confers no rights

Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

 

[Boris]

[...]
Using the Socket.Select (BSD style sockets) you're leaving the entire
IOCP infrastructure unused. This is the most powerfully socket
interfaces there is on Windows. Without it, you have to manage your
own threading, your own events, and all sorts of other things that
the Windows Kernal is signifagantly better at than code you write
yourself is ever going to be. The IOCP thread pool is excellent at
performing these opertions quickly and in a very reliable manner.

The Async Socket stuff has no troubles scaling to (on a Win2K3
machine with enough ram) 50K simultanious TCP sockets connected to it
and sending / receiving data at an IM type pace. Even this limitation
is due to the 2GB per process barrier in Win32 rather than any socket
limitations.

Ah, thank you very much for this information! I come from the Unix world
just stepping into .NET so I didn't know that. Thanks again!

Boris