C# implementation issues?

[vukicevic]

Marc mentioned the following in another thread and suggested starting a new thread:

There are several issues with some C# libraries being very buggy, such as the network library. For details, you must wait until Michi is back, he is on travel and will be back at the end of next week.

I'm interested in finding out what problems you're running into, especially so that I can check if the same problems are present in mono -- I'm assuming you're working with the Microsoft CLR.

Thanks!

[rdilipk]

I'm interested in finding out what problems you're running into

+1. If the ZeroC gang has a record of all issues that you ran into while implementing Icicle (is that the name?) it'd be invaluable for upstart projects like ours.

Apologies since this thread has nothing to do with ICE per se.

[michi]

I ran into a few problems in the .NET socket implementation:

1) If you put a socket into non-blocking mode, you cannot retrieve the local and the remote endpoint. (The LocalEndpoint and RemoteEndpoint attributes are null when you read them.) To fix, you have to use platform invoke for getsockname() and getpeername(), which is messy.

2) Poll() blocks indefinitely if you pass a negative timeout (as it should). On the other hand, Select() silently treats a negative timeout the same as a zero timeout. The closest thing to a blocking Select() you can do is to pass IntMax. However, that gives you only about 5 and a half minutes, then the call times out. The work-around (restarting the select if it times out) is surprisingly complicated.

3) To set the receive or send timeout, you have to pass the timeout in milliseconds. However, Select() expects the timeout in microseconds. Not nice.

4) Reading from a non-blocking socket when no data is available doesn't return zero bytes but throws an exception instead. That's a royal pain: the exception that is thrown is SocketException, so there is no way to specifically handle timeouts. Instead, you have to get the underlying Win32 exception, read the error code, and see whether it is WSAEWOULDBLOCK. To boot, there are no definitions for the various error codes in the .NET framework, so you end up grepping through the Windows header files and have to put manifest constants into the code. And, of course, the whole design is broken because having to handle an exception for something that isn't an error condition makes a mess of the code.

5) I had some issues with non-blocking sockets and select -- on occasion, select would return a socket in the error set even though it shouldn't. I didn't follow up on exactly what caused this because it was easier to just reorganize my code, so I can't provide more detail.

Cheers,

Michi.

[Ctaesis]

I'm curious about which way you choose to solve the problems, write a custom wrapper around the underlying unmanaged Winsock functions and use that for the Ice implementation, or build the Ice implementation with the workarounds for the System.Net.Sockets bugs?

I suppose I could just wait for the source code release, and check myself, but um, call me impatient?

[michi]

For the getpeername() and getsockname() problem, I ended up calling into the Windows DLLs using platform invoke. (Not easy, BTW -- the documenation for platform invoke is, well, let's say "obtuse.")

For the other issues, I wrote a wrapper to get the behavior I wanted.

Cheers,

Michi.

[rdilipk]

the documenation for platform invoke is, well, let's say "obtuse."

Actually you are being charitable. Obtuse is an understatement for P/Invoke related stuff. If you are interested you can check this out:
http://msdn.microsoft.com/msdnmag/is...T/default.aspx

Of course, since I have succesfully OT'ed this whole thread pls let me know if I should take it elsewhere.