By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,422 Members | 1,455 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,422 IT Pros & Developers. It's quick & easy.

System.Net.Socket issues and bugs (any of these fixed?)

P: n/a
Gurus

I didn't personally encounter these problems but some friends of mine
who are doing some deep heavy-metal C#/Networking application have run
into these problems. Does anybody have any idea if these are
addressed for a future release?

thanks
--Dilip

Problem report:
================
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.
Nov 15 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
rd*****@lycos.com (Dilip) wrote in news:8bc3089c.0402111239.7e5ec89
@posting.google.com:
I didn't personally encounter these problems but some friends of mine
who are doing some deep heavy-metal C#/Networking application have run
into these problems. Does anybody have any idea if these are
addressed for a future release?


Have you considered using other socket sets? Or maybe just calling Winsock2
directly?
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

Nov 15 '05 #2

P: n/a
"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message >
Have you considered using other socket sets? Or maybe just calling Winsock2
directly?


Actually I don't know what workarounds were used in each of those
cases I listed. I didn't encounter these myself. But since we are
embarking on a networking project where we might use sockets heavily I
just thought I'd post it here and see if someone from MSFT responds on
whether they know about these issues and if they would be fixed in the
future.
Nov 15 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.