0

I am using Winsock, and I have a need to issue a TCP connect repeatedly to a third-party server. These applications will stay up potentially for days at a time. I am the only client connecting to the server. The time between connects is on the order of seconds, and the connection stays up only long enough to send a single message of a few bytes. I am currently seeing that the connects start to fail (WSAECONNREFUSED) after a few hours. Is there anything I must do (e.g. socket options, etc.) to ensure these frequent repeated connects will succeed for an indefinite amount of time? Thanks!

Dave
  • 1,519
  • 2
  • 18
  • 39
  • What you are describing is typically considered "bad behavior" on the part of the client. The "connection refused" errors may be the server running out of resources (or throttling your client) because it is connecting too often. What is your use case? Can you change your design so that less connections are required? – mpontillo Mar 05 '12 at 20:59
  • As far as using up resources, I didn't mention that the connection stays up only long enough to send a few bytes. I have edited the original post to this effect. I am polling the server for availability of services. This availability changes frequently, and the server does not allow me to register for notification of availability changes. To give an accurate system state representation to my human user, I poll frequently. I agree it is not ideal, and it very well could be that I am being throttled (I have no documentation on the server that describes what connection frequency is acceptable). – Dave Mar 05 '12 at 21:17
  • I'll expand my previous comment by noting that netstat -an on the server shows around 13 or so connections in the TIME_WAIT state. While this doesn't sound good, I don't think the problem it's indicative of is that all available resources have been consumed since 13 is a smallish number in this context. – Dave Mar 05 '12 at 21:36
  • Sounds right. You need more information. What windows tells you in the error event log please? – yves Baumes Mar 05 '12 at 21:46
  • Nothing related to my problem appears in the event log. – Dave Mar 05 '12 at 22:19
  • It's also possible that your ISP (or some ISP between you and your third-party server) may be forging TCP RST packets to stop you from connecting. Your client may be interpreted by the ISP as a denial-of-service attack, or some other activity they consider "suspicious". – mpontillo Mar 06 '12 at 00:02
  • *"WSAECONNREFUSED 10061 Connection refused. No connection could be made because the target computer actively refused it. This usually results from trying to connect to a service that is inactive on the foreign host—that is, one with no server application running."* When the error occurs in your application, try to launch telnet IP PORT to see if the server is still active. By the way do you have log file on the server side? – yves Baumes Mar 06 '12 at 08:17

1 Answers1

2

When doing a lot of transaction based connections and having issues with TCP's TIME_WAIT state duration (which last 2MSL = 120 seconds) leading to no more connections available for a client host toward a special server host, you should consider UDP and managing yourself the re-sending of lost requests.

I know that sounds odd. But standard services like DNS are required to use UDP to handle a ton of transactions (request then a single answer in one UDP segment) in order to avoid issues you are experimenting yourself. Web browsers send a request using UDP to the DNS. Re-request is done using UDP after a short time, no longer than a few milliseconds I guess. Sometimes the resolved name is too long and does not fit in the UDP paquet. As a consequence the DNS server send a UDP reply with a dedicated flag raised, in order to ask the client to use TCP this time.

Moreover you may consider also the T/TCP extension (Transactional TCP) of TCP, if available on your Windows platform. It provides TCP reliability with shorter TIME_WAIT state, as nearly no costs in the modifications of your client code. As far as I know it may work even though the server does not handle that extension. As a side note it is currently not used on the internet as it is know to have some flaw...

yves Baumes
  • 8,836
  • 7
  • 45
  • 74
  • Your suggestion don't sound odd at all, and I appreciate you taking the time to offer them. Unfortunately though, I do not have access to the server code, so I am unable to modify the way in which it communicates. – Dave Mar 05 '12 at 21:20
  • Regarding the new information you are providing in your comment, my answer won't help you. Sorry about that. What you may try to do is to modify the configuration on the client host to shorten the MSL or the TIME_WAIT state duration, freeing connections with the server host sooner. As I am not an expert, I can't tell if it is possible... – yves Baumes Mar 05 '12 at 21:29
  • Regarding the link to the active close discussion. I do indeed close the socket as soon as I am through with it. – Dave Mar 05 '12 at 21:36