Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=75436 --- shadow/75436 2005-08-31 20:14:31.000000000 -0400 +++ shadow/75436.tmp.25267 2005-09-04 14:58:52.000000000 -0400 @@ -95,6 +95,29 @@ ------- Additional Comments From [EMAIL PROTECTED] 2005-08-31 20:14 ------- Sorry... blocking=false, of course. I get this error: Error: System.Net.Sockets.SocketException: Socket is already connected in <0x002f8> System.Net.Sockets.Socket:Connect (System.Net.EndPoint remote_end) in <0x00044> System.Net.Sockets.Socket+Worker:Connect () + +------- Additional Comments From [EMAIL PROTECTED] 2005-09-04 14:58 ------- +While Joe has found that the function will enter the AsyncResult +method (ExecuteConnect) if blocking is set to false, the correct +behaviour for this scenario is for the code to enter the AsyncResult +method blocking or not. This example (blocking=true) compiled using +mcs and run directly under windows works OK. However run under +windows or linux as mono <my.exe> and the call never makes it into +AsyncResult method. + +Looking at the code in System.Net.Sockets.Socket.cs, I'm wondering +if the implementors have the logic backwards. In .NET the +connection is performed by the EndConnect() method. This method +method blocks until a connection is obtained or an error is +returned. Correspondingly, BeginConnect() does not block because it +does little but initiate a thread for the delegate. + +In the Mono implementation, BeginConnect() is responsible for a lot +while EndConnect() is nothing but a few error checks. I'm probably +wrong but it may worth someone who knows spending a few minutes +comparing the behaviour of the asynchronous features of the .NET +socket implementation with those in Mono. Let me know if I can help. + _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
