Trying to send large bulk of data in MS Windows via non-blocking SSLSocket raises an exception but part of the data is delivered.

E.g.

ssl_socket.write(b"a" * 200000)

raises

ssl.SSLError: [Errno 3] _ssl.c:1126: The operation did not complete (write)

There is no way to get the sent bytes count which is essential in non-blocking communication.

ssl_socket.send() returns 0. This should be unified with posix behavior.

Which version of Python are you testing on? It works fine using 3.2 and 3.3 here, under Windows 7 64-bit.

Anyway, I would suggest to batch your write in smaller chunks (say, 2048 bytes each). Also, you may try sendall() instead.

Sorry, I attached wrong example version. It uses repeated sslsock.write() of the same buffer after catching SSL_ERROR_WANT_WRITE. It delivers the full block but this is a blocking operation.

I'm troubled with non-blocking writes. But as I dig deeper into the problem it looks like an inconsistency in OpenSSL (Linux vs. MSW). In Linux sslsock.write() always (as far as I can tell) sends some or all of the data and returns the amount. Like the plain socket.send(). In Windows it raises an exception if the data is larger then some uncertain size (mostly 16kB).

I'm working on snakeMQ asynchronous messaging library where the "packeter" layer relies on the sock.send() returning actual amount of sent bytes. This is not working in Windows if the link uses SSL.

Tested on WinXP, py2.6, py3.2.

> Sorry, I attached wrong example version. It uses repeated
> sslsock.write() of the same buffer after catching
> SSL_ERROR_WANT_WRITE. It delivers the full block but this is a
> blocking operation.

In "normal" non-blocking code you would use select() (or an equivalent)
until the socket is ready for writing, and then send() some chunk of
data on it. Can't you use that approach?

I didn't meant blocking as setblocking(True). I use select/poll but I can't use returned value from send() immediately since in Windows there are often needed more send rounds to actually know how much data was sent.

E.g. in Linux I know it after the first call:

  sslsock.write("abcd") -> returns 2
  poll(sslsock)
  sslsock.write("cd")

in Windows I must do:

  sslsock.write("abcd") -> raises SSLError
  poll(sslsock)
  sslsock.write("abcd") -> returns 4

As I wrote it might be inconsistency in OpenSSL and not in Python's wrapper.

I don't see any discrepancy here (with Python 3.3). Under both Linux and Windows, the client thread prints:

ERR [Errno 3] _ssl.c:1126: The operation did not complete (write)
done

The only difference is that the server thread receives 128KB under Linux, and 48KB under Windows.

I think the main variation comes not from OpenSSL, but from the OS's thread scheduling algorithms. If you do a large write, you have to be prepared to get an error, because the buffers may be too small.

I agree it might seem strange that OpenSSL returns an error rather than the number of sent bytes, and this behaviour could actually be changed at the OpenSSL level (see http://www.openssl.org/docs/ssl/SSL_write.html) by allowing people to use the SSL_MODE_ENABLE_PARTIAL_WRITE option. However, doing so by default could break existing code which assumes that writes either fail or succeed completely.

issue8240 talks about a slightly related request.