I've run into some strange behavior on an application I'm developing in C using the windows API.

Im trying to implement a closed connection server-client interface. However, for whatever reason connect() is failing consistently after between 1-50 successful iterations of the below pseudocode: (WSA initialization is omitted, reasoning explained later, all that is important to know is TCP connection is used)

while(1) {
    if(socket failed) continue;
    connect(); //This fails repeatedly after several successful iterations
    if(connect failed) {

At this point, I'm likely going to just use an open connection as my program works when the connection is left open, and as often as data will be transferred, this is likely the better option anyways.

However, for soon to be obvious reasons, I would like to know why the above doesnt work. The code that initializes WSA and the above code are called by a thread that my int WINAPI WinMain() function creates. When the same code is executed within the normal int main() function in a previous developmental version (i.e. it is not being executed as a thread and not alongside WINAPI WinMain), it indefinitely connects and disconnects successfully to the same exact server (i.e. IT WORKS!).

Is a proper way to implement a closed connection? Why would the same code work in one instance and not another: Is it due to being executed within a thread? Is it due to being executed alongside WINAPI functions? I wouldn't think it is firewall related since it works in one instance.

  • Your pseudo code does makes it hard to see what you actually do. Connect should throw an exception when it fails. Or if your API is a wrapper it may return some error code. The first thing you do is analyse and present that feedback. Now we can only speculate. Like, I don't see any Disconnect or Shutdown statements which is suspicious. Do you create a new socket in each iteration? You may be depleting all the listeners at the other end before any of them times out. Anyway, this should be on stackoverflow instead. Feb 20, 2022 at 8:37

1 Answer 1


I figured it out on my own, though I would like to clarify that based off of Microsoft documentation, my unrevised code should have worked in both circumstances (or not worked in both circumstances).

I revised my code such that WSA cleanup is called after closesocket, and WSA initialization code was added to the beginning of the loop (i.e. WSA is initialized/created and destroyed with each iteration). This allowed the program to run for 4 hours today with no issues observed.

I don't know if microsoft intended this behavior, but in my opinion something as logic-oriented as programming should never behave differently (all relevant variables held constant) in two different circumstances. Threads/other non-socket winapi functions shouldn't interfere with the operation of a socket, or at the very least such interactions should be explicitly documented. And if there are standards to abide by, under no circumstance should code that fails to adhere to such standards execute successfully.

  • 1
    And why were you doing WSAStartup/WSACleanup multiple times? It is supposed to be used once.
    – user289860
    Feb 1, 2020 at 23:19
  • 1
    @StaceyGirl Because, as I've already stated, thats how my code was set up to begin with. The call to connect() failed consistently after a few iterations of socket() , connect(), and closesocket() calls. Documentation suggests this should work, but it wasn't. After WSAStartup was added to the beginning of my loop and WSACleanup was added to the end, it began to work as intended. This is for a closed connection. I am, however, considering switching to an open connection, which would require a single WSAStartup / WSACleanup. But for a closed connection it must be called with each iteration
    – KeatonB
    Feb 2, 2020 at 1:48
  • "should never behave differently (all relevant variables held constant) in two different circumstances" - What????? This makes no sense at all!
    – user253751
    Jun 30, 2021 at 12:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.