Socket Exception: A non blocking socket operation could not be completed immediately.

[Rollasoc]

Hi,

We have a range of four products that can talk to our software (Written
in C# & managed C++) via ethernet. Using standard socket class.

This has all been working fine for a long time now, under DotNet 1.1.

We have now converted the project to DotNet 2.0

Unfortunetely, the code no longer works for one of the products. The
other three are fine.

Now, when we try and communicate, we get the following error

"A non blocking socket operation could not be completed immediately".

I'd be open to suggestions on how to fix this, having spent several
days googling for an answer, I have yet to find one that works.

The other question is "What else has MS changed in functionality whilst
keeping the interface the same, that I may software may trip up on with
the ported code?"

Chris
http://www.hairthieves.com

[Goran Sliskovic]

"Rollasoc" <ro******@hotmail.comwrote in message
news:11**********************@i3g2000cwc.googlegro ups.com...

Hi,

We have a range of four products that can talk to our software (Written
in C# & managed C++) via ethernet. Using standard socket class.

This has all been working fine for a long time now, under DotNet 1.1.

We have now converted the project to DotNet 2.0

Unfortunetely, the code no longer works for one of the products. The
other three are fine.

Now, when we try and communicate, we get the following error

"A non blocking socket operation could not be completed immediately".

....

This is actually not an error. You are using non-blocking socket (is this
your intention?) and this "error" is normal flow of processing in such case
(WSAEWOULDBLOCK in win32 api) and you have to handle it gracefully. You'll
have to be more specific about the problem.

Regards,
Goran

[Rollasoc]

Goran Sliskovic wrote:

This is actually not an error. You are using non-blocking socket (is this
your intention?) and this "error" is normal flow of processing in such case
(WSAEWOULDBLOCK in win32 api) and you have to handle it gracefully. You'll
have to be more specific about the problem.

Regards,
Goran

I think the main problem is I didn't get the error on Dotnet 1.1 and
now do on Dotnet 2.0.
The code at our end hasn't changed and is essentially the same code
for all 4 products. Why it is fine on three of them and not the other
one is a mystery.

I'll do some more research on WSAEWOULDBLOCK and how to gracefully
handle it however and get back with any findings.

Rollasoc
http://www.hairthieves.com

[Goran Sliskovic]

"Rollasoc" <ro******@hotmail.comwrote in message
news:11**********************@h48g2000cwc.googlegr oups.com...
....

>
I think the main problem is I didn't get the error on Dotnet 1.1 and
now do on Dotnet 2.0.
The code at our end hasn't changed and is essentially the same code
for all 4 products. Why it is fine on three of them and not the other
one is a mystery.

I'll do some more research on WSAEWOULDBLOCK and how to gracefully
handle it however and get back with any findings.

....
I don't know whether something changed between 1.1 and 2.0, but:
WSAEWOULDBLOCK you would get with non blocking socket in case of:
connect call
read call when no data is buffered
send call when send buffer is full
probbaly shutdown with SO_LINGER on...

This is rather common. You have to wait a bit and issue request again (or
poll socket for for read/write). This is usually done with select call in
API.

If you don't handle it, I'm really surprised how it worked in 1.1. In some
cases you may get lucky because of timings and implementation and very
rarelly get this error.

Regards,
Goran

[Rollasoc]

Goran Sliskovic wrote:

...
I don't know whether something changed between 1.1 and 2.0, but:
WSAEWOULDBLOCK you would get with non blocking socket in case of:
connect call
read call when no data is buffered
send call when send buffer is full
probbaly shutdown with SO_LINGER on...

This is rather common. You have to wait a bit and issue request again (or
poll socket for for read/write). This is usually done with select call in
API.

If you don't handle it, I'm really surprised how it worked in 1.1. In some
cases you may get lucky because of timings and implementation and very
rarelly get this error.

Regards,
Goran

Goran,

Thank you for the reply. I can only assume it is some sort of timing
thing, maybe MS made the code more efficient or something. It is a
bit of a worry that it seem to be ok when talking to our other
products.

I will investigate further next week and try some sort of retry
mechanism. (not sure why it comes back with this error and not a
timeout error?). It is happening on a receive function call by the
way.

Thanks again.

Rollasoc
http://www.hairthieves.com