1

I have a server socket that I have configured to allow one connection at once (by blocking Accept calls with a semaphore), with a backlog queue size of 1. That is, I called .Listen(1).

I then follow the following process:

  • I call AcceptAsync on my server socket (only once)
  • I have a client ConnectAsync (connects successfully)
  • I have a client ConnectAsync (connects successfully, supposedly in the queue... a way to tell would be nice)
  • I have a third client ConnectAsync

These three ConnectAsync calls happen in rapid succession.

The expected result for the third ConnectAsync is to have the SocketAsyncEventArgs "SocketError" property be something other than "SocketError.Success". I actually expect "SocketError.ConnectionRefused", to be specific.

About 95% of the time, this is the case. The third client's callback gives me a SocketError value other than Success.

Every now and then, though, the third ConnectAsync "works", in the same way the second one does. The EventArgs.SocketError gives me SocketError.Success, and the corresponding Socket.Connected property reads "true".

What's going on? I call AcceptAsync exactly once (I have verified this carefully with breakpoints), so only one client should be accepted, and the rest should be on the backlog queue. My queue size is 1, so how is the third client connecting successfully every now and then?

Please don't tell me to use a larger queue size. This is for a test function I've written, and not code that is actively serving clients. At this point it's more curiosity. :)

Sapph
  • 6,118
  • 1
  • 29
  • 32
  • Could it be that your second pending connection got closed (during debugging) and there appeared to be place for one more connection? – Eugene Mayevski 'Callback Jan 08 '11 at 10:14
  • I don't believe so. I have a breakpoint set that triggers 5 seconds after the connections are attempted. At that point, if I inspect all three sockets, all three have .Connected set to true. – Sapph Jan 08 '11 at 21:22

1 Answers1

0

That won't work. The system will raise your listen backlog of 1 to its own minimum which is going to be at least 50.

Just make your server single-threaded. Then it will only process one connection at a time. Subsequent connections will wait in the backlog queue. When the backlog queue is full they will get 'connection refused' if the server is a Windows platform. Not otherwise.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Only, it does work, almost every time. The test fails only occasionally. I'm asking what circumstances cause it to fail. Like I said, I'm not interested in running this sort of server in a production environment. The question is to satisfy my own curiosity. – Sapph Jan 13 '11 at 02:11
  • @Sapph: It may work but not for that reason. The minimum backlog value on Windows is 5 (Winsock specification). And you can hardly call 'fails only occasionally' a success. – user207421 Feb 14 '11 at 03:34
  • Alright, well, can we try to figure out why it's working most of the time? Does the .NET framework try to enforce a separate software limit regardless of OS specification? The "why" is sort of the entire point of this question. :) – Sapph Feb 14 '11 at 21:08
  • I can't comment on the .NET framework, or on why your code works the way it does without seeing it. – user207421 Feb 14 '11 at 22:56