This project has moved. For the latest updates, please go here.

SocketAsyncEventArgs and/or future plans

Apr 1, 2010 at 1:44 PM

I have two questions about this nice library ...:

1.- How many connections can a dedicated server (average with 2GB or 4 GB) manage simultaneously (Estimated)?
2.- Is this library using or is going to use the new asynchronous pattern "SocketAsyncEventArgs Class" which is supposed to be performant?

I like to implement this library on my projects because as I read previously it can manage efficiently dropped connections ..., and I need to inform almost inmediatly to connected clients about other connections that not exist anymore at that moment.

Thanks in advance.

Apr 1, 2010 at 5:41 PM

1 - Nito.Async.Sockets only adds a small overhead of context switching whenever a socket event happens, so the answer to this is entirely up to the OS. A few thousand connections is not difficult, but you also need to consider the turnover rate: if these are short-lived connections, then your scalability is restricted considerably (due to the limited range of ephemeral ports and the TIME_WAIT state; both of these values can be tweaked but I really don't recommend it).

2 - It currently uses the Begin/End pattern. I've considered adding the Async pattern, but there are a couple of things that make me hesitate:

  A) The performance benefits of Async over Begin/End are entirely based around reusing overlapped I/O structures instead of allocating and disposing of them. To actually see the performance gains, one would have to know a good deal about exactly how the socket is going to be used. Nito.Async.Sockets is a general sockets library, and cannot make those assumptions. The best we could do is create a sort of configurable cache of the structures; this would be quite complex (raising the possibility of bugs quite a bit), damage the performance of "unusual" applications at the expense of "common" ones, and likely provide only a small performance boost over the existing asynchronous solution.

  B) There have been several reports of the Async methods failing to work correctly (i.e., incorrect semantics) under heavy load conditions. Although these reports have not been confirmed or reproduced by Microsoft, multiple independent ISVs have run into similar problems.

I am considering the Async approach just for the sake of Silverlight compatibility. However, there are no plans to add it in the near future, and it may be restricted to client sockets and placed in a separate assembly.


Apr 1, 2010 at 10:53 PM

Thanks Steve for your fast answerm I really appreciate that ...

Well, the performance that you gain in reusing overlapped Y/O is really good when you know you'll have too many active connections.

So, this is my scennario: I like to enable at least 4000 - 5000 concurret active connections per machine (even a little more if possible), the informatin interchanged between server and clients is not heavy/huge, in fact is short but this need to be alive and broadcasting to the rest of active clients (if a client sent some info, the rest must know about it). What king of resources (machince, memory, ...) estimated I need to achieved what We like (initially We liked 10.000 but I think is not possible at leat you redistribute in other computers).

Once again, ...

Thanks in advance.

Apr 2, 2010 at 6:09 AM

As a complement to the previous question, I would like to add, that We would like to load the most possible quantity of concurrent connections but using packets alive, that  is the only way to handle in a good manner dropped connections (as I think, I don't know another way, do you?)

Thanks ...

Apr 2, 2010 at 9:22 AM

Sorry, I'm not clear on what your question is. Could you rephrase it?


Apr 2, 2010 at 6:08 PM

Sorry for my English.

1.- I like to enable at least 4000 - 5000 concurret active connections per machine (even a little more if possible), can We achieve that?

2.- Some connections usually drop, and nobody know about it at least the server try to send some info to the disconnected client. We would like to handle dropped connections as you did in your library, but I was wondering if that represent a little overload and affect the possibility to achieve the objetive in point 1.

3.- In fact, We really need to enable 8.000 concurrent connections per server (for low budget), but I think that is not possible, isn't it?

Some help is really appreciated ...

Thanks in Advance.

Apr 3, 2010 at 11:07 PM

Several thousand long-lived connections with short messages sounds like it should be fine. There is some overhead to detecting dropped connections but it is not a lot (just a couple more small messages).

Regarding exact numbers, it totally depends on your operating system, any other programs that are running (i.e., do not try this when running a BitTorrent client), and the server and network hardware. The only way to know these limits are to build a solution (or a fake solution, sending meaningless data) and stress-test it.


Apr 4, 2010 at 2:44 AM

Many thanks for your answer, I really appreciate that.

Yes, We're going to install an application with this library in a exclusive machine, no other programs running on it, of course depending of our budget maybe postgresql or mysql too. A good machine 4GB/8GB Ram or more and Windows 2003 or even XP. Maybe a good license of Windows 7 64bits.

Just one more question, please, when We're talking about short messages, how small this messages should be in Kb?


Apr 5, 2010 at 7:44 PM

I would call any message less than or equal to 1460 bytes "short", since it fits into a single standard Ethernet frame.


Apr 16, 2010 at 1:41 AM

That's really, I can see that you're now upgrading to VS 2010 ... I guess that when you're ready to target fw 4.0 it will come with some nice new features or performance ...

Excellent library ...

Apr 19, 2010 at 5:28 PM

To be clear, I've been upgrading only the solution/project files. Nito.Async and Nito.Async.Sockets still target 3.5 SP1.

4.0 brought even more changes than expected, particularly considering the Parallel Extensions Extras: Most of what I was planning for Nito.Async on 4.0 is already provided by those code examples.

It will be some time before I reconcile all the changes and determine a best direction forward.


Apr 19, 2010 at 7:34 PM

Yes,  I know. It's too fast to upgrade and use all new features that come with new framework. However, I was wondering it's possible to compile with no issue your lib against to Framework 4.0. As you know the new framework is smaller in size than fw 3.5sp1, so just targeting, even with no change in the code is a gain.

Apr 19, 2010 at 8:05 PM

Nito.Async and Nito.Async.Sockets will work just fine in a .NET 4.0 application, even though they target .NET 3.5.


Jul 4, 2010 at 6:05 AM

Hi Steve, as you can guest I am using your excellent library in some of my projects but now I have this little issues and concerns ...:

- The socket server is listening for incoming connections (can be 1000-2000 till now) and all is working ok but sometimes I can see that the RAM consumed by my application is growing when the server is active for days (weeks) uninterrupted. For test We just set the listening socket and keep the connection active until the client disconnet. What could be wrong? What could be do that consumed memory increase, even if no transfer of messages exist just the active connection?

- The server need to know when the client connection is dropped or disconnected, sometimes if possible the client stay Idle (no problem) but if for some reason in that state (idle) the connection is dropped the server doesn't know about that (it only knows when the connection is closed correctly or an error occur while interchanging data). I don't know how correctly use the KEEP ALIVE packets, Do you have a good example on how to use it?

- If I use Keep Alive Packets, Will those break the connection logic already created to keep the clients and server connected and interchange messages? some messages are serialized and I was wondering if adding those packet will force me to change the logic of the application.

Thanks in advance ...

Jul 5, 2010 at 9:33 PM

Are you using the Simple sockets or the regular? The regular sockets should not be showing increasing RAM over time, but the Simple sockets have keepalive packets built-in, so they do.

My blog has some information regarding keepalive packets, along with my recommendations: