tcp_forwarder: make sendall() blocking

[irdkwmnsb]

Consider side A to be the client (program ran on a host machine), B to be the server (ios device) and P to be python process.

When we have B streaming the data to A over P and A doesn't want to read the packets from it's socket - the kernel will keep them in a buffer. And when it fills up, next time P receives a packet from B it will block on line 122 because the buffer of socket P->A is full. And pymobiledevice3 hangs altogether and doesn't receive new connections.

While this change breaks some use cases I think it is generally better to not block io operations if the kernel buffer is full.

[doronz88]

Doesn't this just pass the blocking part into the sender endpoint instead of the receiver?

[doronz88]

Also, this is from python's documentation:

Send data to the socket. The socket must be connected to a remote socket. The optional flags argument has the same meaning as for recv() above. Unlike send(), this method continues to send data from bytes until either all data has been sent or an error occurs. None is returned on success. On error, an exception is raised, and there is no way to determine how much data, if any, was successfully sent.

As I understand this, the sendall() is already blocking. How does this make any difference?

[irdkwmnsb]

Also, this is from python's documentation:

Send data to the socket. The socket must be connected to a remote socket. The optional flags argument has the same meaning as for recv() above. Unlike send(), this method continues to send data from bytes until either all data has been sent or an error occurs. None is returned on success. On error, an exception is raised, and there is no way to determine how much data, if any, was successfully sent.

As I understand this, the sendall() is already blocking. How does this make any difference?

As per the documentation many details are system-dependent.
On linux and Darwin the use case I described definitely blocks the operation and no more sockets are being opened or data is being sent until the client socket is being read from.

[irdkwmnsb]

Also, this is from python's documentation:

Send data to the socket. The socket must be connected to a remote socket. The optional flags argument has the same meaning as for recv() above. Unlike send(), this method continues to send data from bytes until either all data has been sent or an error occurs. None is returned on success. On error, an exception is raised, and there is no way to determine how much data, if any, was successfully sent.

As I understand this, the sendall() is already blocking. How does this make any difference?

There is no behavioural difference in send and sendall when it comes to blocking and waiting for kernel response.
The only difference is that sendall will try to send data until all data is sent. Since POSIX's write gives no guarantee to how many bytes will be definitely sent to the socket, sendall will repeatedly send data until all is written.
See https://stackoverflow.com/a/34252690

[irdkwmnsb]

Doesn't this just pass the blocking part into the sender endpoint instead of the receiver?

And no, the connection will be closed upon a read/write error which will occur if the buffer is full and no data is being read.

[doronz88]

Sorry for the misunderstanding. Just to clarify and understand correctly, you say that adding the sorrounding .setblocking(True) makes sure if that if the other endpoint doesn't trigger recv(), it will raise an error instead of waiting indifinetly?

[irdkwmnsb]

Sorry for the misunderstanding. Just to clarify and understand correctly, you say that adding the sorrounding .setblocking(True) makes sure if that if the other endpoint doesn't trigger recv(), it will raise an error instead of waiting indifinetly?

If you try to send while blocking option is set for a specific file descriptor - the program will not return into user space if the other end is not reading data. In other words - if you add setBlocking(false) before sendAll and the other end is not reading data - it will trigger EWOULDBLOCK oserror, since the sockets are being switched into non-blocking mode right after their initialization in _handle_server_connection

[doronz88]

Okay I see. Thanks for clarifying the matter