Async Sockets

Question

4.33/5 (4 votes)

See more:

I've just recently ported a sockets client from .Net 2.0 to .Net 3.5 ...
and now it runs into reoccurring problems, of which I'm a little suspicious may be related to subtle differences between the frameworks that I'm not allowing for.
*Update* I've made significant changes following Suggestion 1 - which did improve things (in other areas), and along the way corrected the problem mentioned by Suggestion 2 - but still the problem persists. To keep things working I've actually altered the overall error handling, but thanks to my diagnostics I know that the underlying problem still persists - I'm only working around it.
Specifically the Receive Callback function is being invoked, but the socket itself is no longer connected (and probably disposed). This is in spite of the fact that data is expected to be received.

private void ReceiveCallback(IAsyncResult ar)<br />{<br />  SocketError sErr = SocketError.Success;<br />  int bytesRead = 0;<br />  lock (thisLock)<br />  {<br />    try<br />    {<br />      /* Retrieve the client socket from the asynchronous state object.*/<br />      StateObject state = (StateObject)ar.AsyncState;<br /><br />      sErr = new SocketError();<br /><br />      /* Read data from the remote device.*/<br />      /* however this line frequently throws an exception*/<br />      bytesRead = socket.EndReceive(ar, out sErr);<br />      ...<br />

And the essentials of the exception are:

ReceiveCallback threw an error. System.ObjectDisposedException: Cannot access a disposed object.<br />Object name: 'System.Net.Sockets.Socket'.<br />   at System.Net.Sockets.Socket.EndReceive(IAsyncResult asyncResult, SocketError& errorCode)<br />

The associated socket error code is 10038 - which when you read its description isn't very helpful either.

Just to add to this the previous version of this client is still running and still connecting to the same server without issue.

My request is if anyone can point me in the right direction as to what I'm missing or doing wrong. You can reasonably assume that I've googled every permutation of the above in my quest.

Here's some possibilities:
* There's some subtle distinction in how v2.0 and v3.5 sockets connect (e.g. defaults for various socket options) that the server I'm connecting doesn't like / understand.
* It's a speed issue. The v2.0 code has got a whole heap of throttling tricks, that the v3.5 based version does not - I don't think this one's likely (already been playing around in this area).
* It's a threading and/or locks problem on the socket itself.
* I'm missing something important in using sockets - not likely, but this excuse is here for completeness, just in case you have some "traps for young players" type of insight.
* Or something else.

Posted 19-Jul-09 20:38pm

Lee Humphries

Updated 6-Dec-09 18:46pm

v2

Add a Solution

2 solutions

Solution 2

Look closer to the socket error code! The number 10038 means: No socket discriptor. That means the Object you are using is possibly no socket and when you look to your code you see:

Socket socket = (Socket)ar.AsyncState;

But the AsyncState is no Socket but a SocketStateObject. So you hardcast a socketstateobject to a socket and wonder what's happend :confused:

Try this:

SocketStateObject sso = (SocketStateObject)ar.AsyncState;
Socket s = sso.WorkSocket;

Posted 4-Dec-09 5:03am

AndyP1965

Updated 4-Dec-09 5:06am

v2

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Nicholas Butler · Accepted Answer · 2009-07-19T22:13:00

It sounds like your Socket object is being disposed! I would expect that putting a reference to it in your AsyncState would stop the GC collecting it, so are you disposing of it somewhere else?

I don't have a simple answer, but you could try this: Derive from Socket and override Dispose. Put a breakpoint in there to find out when it is being disposed and by whom.

Also, the code you posted has a couple of no-no's:

1) Locking on this is considered bad practice - use a private object to lock on.

2) You don't need to initialise sErr as it is passed as an out parameter.

Nick