Juce sockets behave differently in Windows 2000 and XP


I am using JUCE sockets for interacting with the modem. While using socket.read() , function, all the response is read in first attemp in XP. But when I run it on 2000, it behaves inconsistently. Sometimes, two reads are required and other times one read is sufficient. Any input on this problem.

Also, if there is nothing to read, then it hangs when socket.read() is called for the second time. Is there any function to check if there are any bytes that need to be read from the socket?

Any input would be helpful.


You have to use select() on the socket to know if any pending data is present.

You can also turns your socket to non blocking sockets (setsockopt), and then you’ll have to select() before any access (write or read).
BTW, you have to check the return of the read() part, because it gives you the size of the data actually received (so if it’s less than expected, you can more safely call read to append the new data).


Can you please explain in detail how to make non blocking socket? I am not getting any function as “setsockopt” or select().

Also, can you please tell if there is any difference for socket usage in win2000 and winXP?


You have 2 choices here. Either you call isReady before any read() operation.
If isReady() returns true, then there is something to read.
But, there isn’t anything like that for write (isReady doesn’t check if the socket is ready to write more data), so beware.

Either, you’ll have to create a new class (let’s call it NonBlockingSocket).
Copy and paste the Socket class, and rename Socket by NonBlockingSocket
Then search of “ioctlsocket” in google for a method to put the socket in non blocking mode.
basically it’s like :
int mode = isBlocking ? 1 : 0;
ioctlsocket(handle, FIONBIO, &mode);

Socket class in Juce is very young, and a lot of the methods in there are blocking calls (like read, write, connect, waitForNextConnection).
Worse, the connect method is blocking, and the socket is, by default, put i n blocking mode, so the connect() method will block, whatever the timeout you pass in.

Juce, if you read this, please add a setBlockingMode() to the Socket class, and add a parameter to isReady() to permit select’ing on the write state too. That way, we will be able to “setBlockingMode(false)”, then “connect()”, and then wait with “isReady(true)” until the socket is writeable , meaning it’s connected.
Every read and write could be checked first with isReady(read ? false : true) to know if it’s going to block…