I use InterprocessorConnection for bidirectional data transfer between client and server - both using the InterprocessorConnection class over a WAN/internet connection (using a socket, not a pipe). I set callbacksOnMessageThread=false. This has been working well for a long time. When the connection is terminated with disconnect() on the client side, it has always caused the server to call connectionLost(). This stoppped occurring recently on windows only (mac is fine). The server will just stop receiving data with no connectionLost indication. I dug down into the depths of the InterprocessorConnection functions as far as I could go and confirmed it never gets a socket read that returns -1, as far as I can tell. If the server tries to send in this state, it will error appropriately and I can manually call disconnect() on the server in response to that, but that seems like a hack/workaround. I had updated Windows 10 and JUCE recently so I suspected one of those changes was the problem. If I downgrade JUCE from 5.4.5 back to 5.4.4, the problem goes away and connectionLost gets called correctly. I do get this in my build:
Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. For example:
1>- add -D_WIN32_WINNT=0x0501 to the compiler command line; or
1>- add _WIN32_WINNT=0x0501 to your project’s Preprocessor Definitions.
1>Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target).
That has always been there, but maybe now it matters?
Settings->System->About says:
Edition: Windows 10 Pro
Version: 1803
Installed on: 5/20/2018
OS build: 17134.950
I also use boost, and had to define WIN32_LEAN_AND_MEAN to eliminate a “winsock.h has already been included” message. I removed that define and came up with a way to #include <WinSock2.h> at the top of my files to get around the above error message in a different way. The original disconnect problem persisted though…so I think all of this is unreleated, but included here for completeness.
Also tried defining _WIN32_WINNT=_WIN32_WINNT_WIN10, but that led to a run time error on a mutex lock.
Thanks for reporting. This should now be fixed on the develop branch in commit 570323d.
The issue was introduced in commit b857f96 which replaced some (unsafe) calls to select() with poll() in response to this thread. However, as @samuel helpfully pointed out here, WSAPoll is buggy and fails to report failed connections causing an issue with the JUCE socket classes that are used under the hood in InterprocessConnection and causing the bug you mentioned. Unfortunately Windows have marked the WSAPoll bug as “won’t fix” so we can’t use it and need to revert back to select() instead.
I believe the FD_SET implementation on Windows is safe so sticking with select() for that platform should be fine. The unix-style implementation indexes into an array using the file handle as an index. On Windows file handles don’t start from 0 so this wouldn’t have ever worked so the implementation is much safer; it will iterate through the array searching for the file handle.
