The other option is to call BeginConnect then Thread.Sleep your timeout value and then check if the callback was successful if not throw an exception, and the call back should swallow the connection if eventually successful or swallow an exception if it can't connect.
> -----Original Message----- > From: J. Merrill [mailto:[EMAIL PROTECTED] > Sent: Friday, 7 May 2004 7:56 AM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Reduce .NET socket connect timeout? > > 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(r) 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 > > =================================== 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
