I've developed an app that uses sockets over windows. It works perfectly but after some time, the internet connection begin to fail and finally I get this error (10055), which means that my app run out of buffer space.
Actually I think I am only using 2 sockets with the code i did by myself, but it's true that I'm using a 3rd party library that I have no idea how it's implemented.
I've read that there are lot of literature about this trouble, so I am not the only that suffers from it, but I cannot realise how to solve it, or at least, by-pass it, because when it fails, it makes my computer to lose internet connection. I've tried it by catching this error and when it occurs, doing a WSACleanup(), WSAStartup() even when it's not the best practise... but my app still get stacked in this error.
Any advice will be pretty much appreciated.
Usually this happens when you dnt close your socket properly. Make sure you have both shutdown and closesocket when you want to close the socket (http://msdn.microsoft.com/en-us/library/windows/desktop/ms741394(v=vs.85).aspx) From MSDN - "Note To assure that all data is sent and received on a connection, an application should call shutdown before calling closesocket"
Before you bind the socket, you can use SO_REUSEADDR for setsocketopt which will "Allows the socket to be bound to an address that is already in use" (http://msdn.microsoft.com/en-us/library/windows/desktop/ms740476(v=vs.85).aspx)
Finally, look at this blog - http://blogs.technet.com/b/yongrhee/archive/2011/12/19/how-to-troubleshoot-a-handle-leak.aspx
You have one or more resource leaks in your application.
Without the code I can only give general recommendations.
I recommend that you run Valgrind or similar tools to help you find the resource leak.
Another way is by reviewing the code.
If the leak started recently you can probably find it by reviewing just recent changes.
MSDN has an article on how to locate memory leaks using Visual Studio. (Remember to choose your version of Visual Studio on the linked page).
One cause of this error in Windows is the exhaustion of the ephemeral TCP ports pool.
It's easy to reproduce this error: just create a program that loops in binding port 0.
Very soon this error will happen.
When we pass a 0 to the bind socket function, Windows chooses an ephemeral port to use.
Related
Once in a while my server accept functions just stop working properly anymore.
There is a much deeper story behind this, I'm being flooded with SYN and SYN/ACK packets, my network router goes disco and accept keeps returning ECONNABORTED.... I already tried to debug and fix this specific attack, but without success. By now I gave up and rather look for a more generic server recover solution.
Anyway I figured out that simpy "restarting" the server socket by closing and calling socket again is helping. Theoretically very simple, but practically I'm facing here a huge challenge because (a) the server is quite complex by now and (b) when should I exactly restart the server socket.
My setup is one accept-thread that calls accept and feeds epoll, one listener-thread that listens for epoll read/write etc. events and feeds a queue of a thread pool.
I have not found any literature that guides one through restarting the server socket.
Particularly:
When do I actually restart the server socket? I mean I do not really know if a ECONNABORTED return value from accept is just a aborted connection or the accept/filedescriptor is going banana.
How does closing the server socket affect epoll and connected clients? Should I close the server socket immediately or rather have a buffer time such that all clients have finished first?
Or is it even best to have two alternating server sockets such that if one goes banana I just try the other one.
I am making some assumptions about the things you say in your question all being true and accurate even though some of them seems like they may be misdiagnosed. Unfortunately, you didn't really explain how you reached the conclusions presented, so I really can't do much other than assume they're true.
For example, you don't explain how or why you figured that closing and calling socket again will help. From just the information you gave, I would strongly suspect the opposite is true. But again, without knowing the evidence and rationale that lead you to figure that, all I can do is assume it's true despite my instinct and experience saying it's wrong.
When do I actually restart the server socket? I mean I do not really know if a ECONNABORTED return value from accept is just a aborted connection or the accept/filedescriptor is going banana.
If it really is the case that accepting connections will recover faster from a restart than without one and you really can't get any connections through, keep track of the last successful connection and the number of failures since the last successful connection. If, for example, you've gone 120 seconds or more without a successful connection and had at least four failed connections since the last successful one, then close and re-open. You may need to tune those parameters.
How does closing the server socket affect epoll and connected clients?
It has no effect on them unless you're using epoll on the server socket itself. In that case, make sure to remove it from the set before closing it.
Should I close the server socket immediately or rather have a buffer time such that all clients have finished first?
I would suggest "draining" the socket by calling accept without blocking until it returns EWOULDBLOCK. Then you can close it. If you get any legitimate connections in that process, don't close it since it's obviously still working.
A client that tries to get in between your close and getting around to calling listen on a new socket might get an error. But if they're getting errors anyway, that should be acceptable.
Or is it even best to have two alternating server sockets such that if one goes banana I just try the other one.
A long time ago, port DoS attacks were common because built-in defenses to things like SYN-bombs weren't as good as they are now. In those days, it was common for a server to support several different ports and for clients to try the ports in rotation. This is why IRC servers often accepted connections on ranges of ports such as 6660-6669. That meant an attacker had to do ten times as much work to make all the ports unusable. These days, it's pretty rare for an attack to take out a specific inbound port so the practice has largely gone away. But if you are facing an attack that can take out specific listening ports, it might make sense to open more listening ports.
Or you could work harder to understand the attack and figure out why you are having a problem that virtually nobody else is having.
I know this should be obvious, but I have found far too many DIFFERENT answers and the ones I've tried all fail (sometimes or all the time), so...
We are working on a service and some applications that run at startup on a Windows 10 computer that performs an automatic login. The service and applications require Windows sockets for TCP, UDP and Multicast. Most of the time, our programs fail because they get errors about the network not being ready and such. Currently, we work around this by just adding a dumb, fixed length delay time before attempting to start, but we would prefer to start as soon at the network is ready to be used.
Our most recent attempt was to wait on the LanmanWorkstation (Workstation) service, but that generally reports it is running/ready before the sockets functions will succeed. I have also seen suggestions to use LanmanServer (Server) or Netman (Network Connections) or maybe even Tcpip (TCP/IP Protocol Driver), but I cannot find anything definitive. One would think this is a common requirement, so why would Microsoft make the info so difficult to find?
Ahem. Does any know a definitive method for a service or application to wait until winsock functions will succeed before using them? Short of a spin wait on a failing winsock function, of course!
We recently developed an application which will run a query in DB2 and send a mail to the corresponding recipient. It works well in our local system and QA region. But in production, few queries failed (even if it's rare, like once in week). It throws the exception below.
Exception InnerDetails:
ERROR [40003] [IBM][CLI Driver] SQL30081N A communication error has
been detected. Communication protocol being used: "TCP/IP".
Communication API being used: "SOCKETS". Location where the error was
detected: "111.111.111.111". Communication function detecting the
error: "recv". Protocol specific error code(s): "10004", "", "".
SQLSTATE=08001
Since error occurs only in production and not very often, we are not sure whether it is the code or a setting issue. Do you have any idea?
We recently discussed this issue with our IBM rep. After looking in their internal knowledge base, he suggested we add "Interrupt=0" to our connection string, based on recommendations given to other customers that had the same problem.
The default value for Interrupt was 1 before v10.5 FP2 and still is for most connections. They changed the default value to 2 for connections to z/OS (mainframe) in FP2.
We're using C# and the connection string properties for the IBM Data Server Driver for .Net can be found here. I'm sure there is a similar property for their drivers for other languages.
This page from the IBM docs goes into a bit more detail about the setting.
We haven't seen the issue since we recently added the property, but it was always intermittent so I can't yet confidently say that the problem is fixed. Time will tell...
That particular error (SQL30081N) is just a generic message that indicates a network issue between your DB2 client and the server. In this case, you want to look at the Protocol specific error code(s). Here, it looks like you're on Windows, and that particular code (10004) isn't given in the IBM documentation.
So, if you google "windows network error codes", you'll find this page, which says:
WSAEINTR
10004
Interrupted function call.
A blocking operation was interrupted by a call to WSACancelBlockingCall.
Which links to this page with more information on that specific function (emphasis mine):
The WSACancelBlockingCall function has been removed in compliance
with the Windows Sockets 2 specification, revision 2.2.0.
The function is not exported directly by WS2_32.DLL and Windows
Sockets 2 applications should not use this function. Windows Sockets
1.1 applications that call this function are still supported through the WINSOCK.DLL and WSOCK32.DLL.
Blocking hooks are generally used to keep a single-threaded GUI
application responsive during calls to blocking functions. Instead of
using blocking hooks, an applications should use a separate thread
(separate from the main GUI thread) for network activity.
I'm guessing that your application may be blocking for a longer time in your production application than your other environments, and something along the way is causing the interrupt.
Hopefully this leads you down the right path...
I spent hours to solve the same problem and fixed it. I use a Windows exe (developed with C#.NET) to run a SELECT query from a DB2 database and I sometimes got this error. Finally I realized that my problem is a time out error. Error with protocol code "10004" message, sometimes occurs if query execution is longer than 30 seconds which is default timeout value. Maybe the interruption call on the "Windows Socket Error Codes" page occurs for time out mechanism. I add aline to set an acceptable timeout value and got rid off this annoying error. I hope it helps other.
Here is my code fix :
...
connDb.Open();
DB2Command cmdDb = new DB2Command(QueryText,connDb);
cmdDb.CommandTimeout = 300; //I added this line.
using (DB2DataReader readerDb = cmdDb.ExecuteReader())
{
...
I am experimenting with sockets and WP7.5. Currently, I am looking into the SetNetworkRequirement property of a socket. I am following this how-to, however, the OS seems to ignore the network requirement.
When I set the requirement to cellular, nothing happens when I do ConnectAsync, even when I am only connected to 3G. However, if I am connected to Wifi and use NonCellular, I can see in my tcpdump that a connection is made.
What is strange is that the SDK behavior is not as documented. When I set the requirement to cellular, I still get SocketError.Success, even though I can see that not connection is made. I am also able to send data using this socket, and SendAsync also receives SocketError.Success.
My question is, has anyone seen similar behavior or had any luck setting the network requirement to cellular? Another strange observation is that if I ask the phone to connect to a non-existent IP/port, I see a connection attempt on both interfaces. Based on this, I suspect there is some undocumentet caching going on.
Edit: I did some more debugging on this. The described behavior seems to be linked to be port. If I use any other port than 80, the phone connects with both Cellular and NonCellular.
Thanks in advance.
If anyone experiences the same behavior, everything points to this being an OS bug. There seems to be a problem related to servers running on port 80, as setNetworkRequirement is respected for every other port (that I have tried).
I am writing a udp chat application in c. I need to test if messages are received in an incorrect order. CAn anyone please tell me of a tool I can use to delay certain messages? also please tell me how to use it? thank you very much in advance! also I am using ubuntu x86_64 and OSX 10.6.4. A tool in either OS will work
When I created a syslog server I needed to see if it was catching the messages.
I used Wireshark from http://www.wireshark.org/ . This is a free tool that shows you all traffic passing your network cable. Even packages not intended for your computer.
Have fun...
If you need to verify this, you probably also don't want messages to disappear (or at least know if they do). UDP doesn't sound like what you want. Have a look at implementing this using TCP instead, you get this behaviour with the protocol.