FD_ACCEPT event very slow (sometimes)
-
Hi Guys, Some background info: OS - Windows XP Home SP2 IDE - Visual Studio 2002 .NET I am writing a small client/server application to send/receive data over a network based on WSASocket. Everything is working as the client connects to the server and data is passed successfully between them, except for one issues... At this stage I am running both the server and client on my development PC and am connecting to 127.0.0.1 or the network ip of 192.168.1.1 Sometimes (about 1 in 10) the establishment of the connection takes a long time, up to 30 seconds. I have now traced the server and client programs to death and now came to the conclusion that the actual firing/receiving of the FD_ACCEPT event sometimes takes very long, for now apparant reason, although usually the FD_ACCEPT is fired within 100ms. I've traced out the applications to the point where I can show the actual timestamps of the connect function call and the corresponding reception of the FD_ACCEPT event. To further confuse things it seems that this problem never occurs when I disconnect the network cable. Without the cable I've done about 50 connection tests and they all work fine. When I plug the network cable into the nic every now and then the connection takes an age to establish. Does anybody have any idea what is going on here ? Is it a nic driver problem ? Is it a winsock problem ? Is it a Windows problem ? Any other ideas ? Thanks OD
What method are you using to obtain the FD_ACCEPT notification? Window message? Event? Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
-
What method are you using to obtain the FD_ACCEPT notification? Window message? Event? Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
Hi Mark, Here is the code : TRACE("\nCheckEvents 1 - %s", CDateTimeTools::TimeString()); if (WSAWaitForMultipleEvents(1, &m_hEvents, FALSE, 60000, TRUE) >= WSA_WAIT_EVENT_0) { TRACE("\nCheckEvents 2 - %s", CDateTimeTools::TimeString()); WSAResetEvent(m_hEvents); WSANETWORKEVENTS sEvents = {0}; if (!WSAEnumNetworkEvents(m_hSocket, m_hEvents, &sEvents)) etc, etc, etc ... With the time difference between TRACE 1 and 2 being in the region of 30 seconds when things go wrong ! Cheers
-
Hi Mark, Here is the code : TRACE("\nCheckEvents 1 - %s", CDateTimeTools::TimeString()); if (WSAWaitForMultipleEvents(1, &m_hEvents, FALSE, 60000, TRUE) >= WSA_WAIT_EVENT_0) { TRACE("\nCheckEvents 2 - %s", CDateTimeTools::TimeString()); WSAResetEvent(m_hEvents); WSANETWORKEVENTS sEvents = {0}; if (!WSAEnumNetworkEvents(m_hSocket, m_hEvents, &sEvents)) etc, etc, etc ... With the time difference between TRACE 1 and 2 being in the region of 30 seconds when things go wrong ! Cheers
IS that code used after the connect call()? Also, you can remove the WSAResetEvent(m_hEvents); call. WSAEnumNetworkEvents() will do the reset for you. Regardless, 30 seconds is typically the default timeout for sockets searching for a remote address. In the client, make sure the address struct for the server address is initialized correctly. If connect() was finding the remote address - even if a server wasn't listening on the connect port - it would fail in a few seconds max, not 30 seconds. Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
-
IS that code used after the connect call()? Also, you can remove the WSAResetEvent(m_hEvents); call. WSAEnumNetworkEvents() will do the reset for you. Regardless, 30 seconds is typically the default timeout for sockets searching for a remote address. In the client, make sure the address struct for the server address is initialized correctly. If connect() was finding the remote address - even if a server wasn't listening on the connect port - it would fail in a few seconds max, not 30 seconds. Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
Jip, that is the code that waits for events on the server side. The point is still that every once in a while only the problem occurs that the FD_ACCEPT event is fired after about 30 seconds and though even though it is slow, the connection is then accepted and functions fine onwards. Cheers
-
Jip, that is the code that waits for events on the server side. The point is still that every once in a while only the problem occurs that the FD_ACCEPT event is fired after about 30 seconds and though even though it is slow, the connection is then accepted and functions fine onwards. Cheers
Hmmm not likely related to the code I've seen so far...
od@ananzi.co.za wrote:
and am connecting to 127.0.0.1 or the network ip of 192.168.1.1
If you use "ipconfig" from a command prompt, what's the IP address of your machine? Is it 192.168.1.1? That's always been my LAN router address. Can you post the code that builds the sockaddr for both the connect() call on the client and the bind() call on the server? I'm not sure why it would be slow only sometimes...the 30 seconds time still says network/addressing to me... Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
-
Hi Guys, Some background info: OS - Windows XP Home SP2 IDE - Visual Studio 2002 .NET I am writing a small client/server application to send/receive data over a network based on WSASocket. Everything is working as the client connects to the server and data is passed successfully between them, except for one issues... At this stage I am running both the server and client on my development PC and am connecting to 127.0.0.1 or the network ip of 192.168.1.1 Sometimes (about 1 in 10) the establishment of the connection takes a long time, up to 30 seconds. I have now traced the server and client programs to death and now came to the conclusion that the actual firing/receiving of the FD_ACCEPT event sometimes takes very long, for now apparant reason, although usually the FD_ACCEPT is fired within 100ms. I've traced out the applications to the point where I can show the actual timestamps of the connect function call and the corresponding reception of the FD_ACCEPT event. To further confuse things it seems that this problem never occurs when I disconnect the network cable. Without the cable I've done about 50 connection tests and they all work fine. When I plug the network cable into the nic every now and then the connection takes an age to establish. Does anybody have any idea what is going on here ? Is it a nic driver problem ? Is it a winsock problem ? Is it a Windows problem ? Any other ideas ? Thanks OD
Haven't seen this problem in my networking applications. Additionally to Mark's comments: The only things I can guess is that your event handling may has a problem -or- your connect call is not IP based and the DNS-resolution for a hostname blocks a while. The server socket should get the FD_ACCEPT practically immediately inside the LAN (<50ms).
-
Haven't seen this problem in my networking applications. Additionally to Mark's comments: The only things I can guess is that your event handling may has a problem -or- your connect call is not IP based and the DNS-resolution for a hostname blocks a while. The server socket should get the FD_ACCEPT practically immediately inside the LAN (<50ms).
I haven't been able to make any headway as to what the problem/cause is, but some other thoughts ... Although the application is running on my PC locally, my PC is connected on a nationwide VPN over ADSL. At this stage I am thinking that maybe somehow the routing tables in my tcp/ip stack gets screwed/reset/cleared and that the connection attempt then first "goes out" onto the VPN, before being handled by my application anyway. I am going to try and snoop the network packets at some stage to try and verify my guess. Cheers
-
I haven't been able to make any headway as to what the problem/cause is, but some other thoughts ... Although the application is running on my PC locally, my PC is connected on a nationwide VPN over ADSL. At this stage I am thinking that maybe somehow the routing tables in my tcp/ip stack gets screwed/reset/cleared and that the connection attempt then first "goes out" onto the VPN, before being handled by my application anyway. I am going to try and snoop the network packets at some stage to try and verify my guess. Cheers
-
I have tried both in my connect call, ip and hostname, and both does the slow connect thing without any discernable difference in the frequency of the problem appearing.
-
I have tried both in my connect call, ip and hostname, and both does the slow connect thing without any discernable difference in the frequency of the problem appearing.
Sorry out of generic ideas, this must not happen! Have a good look at your networking core and try to stress test it isolated from application logic. If it is not a private/research project your are working one I would even consider using an existing network class (CAsyncSocket, IpWorks, etc).
-
Sorry out of generic ideas, this must not happen! Have a good look at your networking core and try to stress test it isolated from application logic. If it is not a private/research project your are working one I would even consider using an existing network class (CAsyncSocket, IpWorks, etc).
Hi Moak. I'm out of ideas as well, except that I can now confirm that this problem does not occur when the application are running on a "pure" lan, i.e. no gateways/breakouts/links/etc to our VPN. It is only when I run the applications on PC's that are connected to the VPN that this problem occurs. But my most technical response to the problem no is: Go Figure !
-
Hi Moak. I'm out of ideas as well, except that I can now confirm that this problem does not occur when the application are running on a "pure" lan, i.e. no gateways/breakouts/links/etc to our VPN. It is only when I run the applications on PC's that are connected to the VPN that this problem occurs. But my most technical response to the problem no is: Go Figure !
Hmmm, sounds like trouble! How about using a different networking library? If you search this forum you will find some suggestions (CAsyncNetwork, IpWorks, etc). /M PS: In case you are not sure which to use... feel free to try mine, follow link from my user page and download the SDK
-
Hmmm, sounds like trouble! How about using a different networking library? If you search this forum you will find some suggestions (CAsyncNetwork, IpWorks, etc). /M PS: In case you are not sure which to use... feel free to try mine, follow link from my user page and download the SDK
Err, which link would that be ?
-
Err, which link would that be ?
od@ananzi.co.za wrote:
Err, which link would that be ?
sorry for not answering, I was on a holiday. You get a user's page with the "person" icon next to a nickname (here a direct link to mine). :)