What you've described seems like two bugs to me. First, there shouldn't be an
exception when the result of the API call is WSAEWOULDBLOCK because that's what you
expect when you use a non-blocking socket -- it's not in any way an exceptional
situation. Second, the code should (as you've noticed) set Connected to True. Are
you using 1.1 framework? Clearly non-blocking sockets didn't get enough testing. (Is
there a list of known bugs somewhere?)
If you used a thread-pool thread to do the work, you wouldn't care if it took too
long, would you? The app would be able to continue doing whatever it wanted to do
while waiting. If the thread doesn't finish connecting in (say) a short time (5-10
seconds maybe?) you could do whatever you wanted (including trying another connection
to the same or a different server).
You haven't given any indication of why you want the timeout to be short. If you're
trying to connect to a bunch of different servers, why not use multiple threads?
At 04:50 PM 5/6/2004, Phil Parker wrote
>Hi, does anyone know of a good way of reducing the timeout used for making
>TCP connections through the .NET System.Net.Socket class?
>
>I have tried the documented method from MSDN whereby you set a socket's
>blocking property to false prior to making a connect attempt and then trap
>the generated SocketException which has an error code of 'WSAEWOULDBLOCK'
>and then poll the socket to check for the ability to write using Poll.
>Using Poll then allows me to specify the time I want to wait for
>completion of the connect.
>
>However, there seems to be a bug in the Socket class in that the socket's
>Connected property is only set to true in the Socket.Connect method after
>the code where it throws the SocketException.
>
>Therefore if you go through this rigmarole you end up with a socket which
>*is* connected but has a Connected property which returns false. There
>appears to be no way of setting the Connected property to true - there
>aren't even any protected member which would allow derivation of this
>class in order to fix the problem.
>
>So, I'm wondering what alternative methods there are. Any help would be
>greatly appreciated.
>
>Thanks
>Phil Parker
>
>
>Here is an example of the code:
>
>public static Socket Connect(IPEndPoint endPoint, int port, int timeoutMs)
>{
> Socket socket = new Socket(AddressFamily.InterNetwork,
>SocketType.Stream, ProtocolType.Tcp);
>
> try
> {
> // do not block - do not want to be forced to wait on (too-
>long) timeout
> socket.Blocking = false;
>
> // initiate connection - will cause exception because
>we're not blocking
> socket.Connect(endPoint);
> }
> catch(SocketException socketException)
> {
> // check if this exception is for the expected 'Would
>Block' error
> if(socketException.ErrorCode != WsaeWouldBlock)
> {
> socket.Close();
>
> // the error is not 'Would Block', so propogate
>the exception
> throw;
> }
>
> // if we get here, the error is 'Would Block' so just
>continue execution
> }
>
> // wait until connected or we timeout
> int timeoutMicroseconds = timeoutMs * 1000;
> if(socket.Poll(timeoutMicroseconds, SelectMode.SelectWrite) ==
>false)
> {
> // timed out
> socket.Close();
>
> throw new Exception("The host failed to connect");
> }
>
> // *** AT THIS POINT socket.Connected SHOULD EQUAL TRUE BUT IS
>FALSE! ARGH!
>
> // set socket back to blocking
> socket.Blocking = true;
>
> return socket;
>}
J. Merrill / Analytical Software Corp
===================================
This list is hosted by DevelopMentor� http://www.develop.com
Some .NET courses you may be interested in:
NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnetls
View archives and manage your subscription(s) at http://discuss.develop.com
