I have a working code sample that sends data between a server and client app using a SecureStreamSocket. I am using NetSSL_WIN (schannel), and sending small (1024 bytes) and large chunks (>1MB) of data between server and client. When using blocking sockets (which is default), all works fine.

However when using non-blocking mode (setBlocking(false)) and sending a large chunk of data, I can see how the receiving end using receiveBytes() receives 4 chunks of 16384 bytes each (which is normal when using SecureStreamSocket) and the next call to receiveBytes() returns 0 – meaning the other side closed down gracefully.

Which is actually not the case, because the sending side still tries to call sendBytes(), but returns WSAEWOULDBLOCK.

This is very unusual behaviour, and only occurs in non-blocking mode.

One peculiar thing I noticed when stepping through the Poco source-code is that a call to sendRawBytes() – which calls SocketImpl::sendBytes() – also has the _blocking member, and to my surprise that is true, but it should be false. It’s almost as if in the depths of SecureStreamSocket an instance of Socket is used, that had the call to setBlocking(false) not propagated all the way through.

Short question is: anyone got SecureStreamSocket to work with NetSSL_WIN non-blocking sockets when sending large chunks of data?

Long question: any idea what I could possibly do wrong? Is there any send/receive buffer size I need to set, and adhere to?