On Thu, 23 Apr 2015 09:21:11 +0200 Andrea Griffini <agriff@tin.it> wrote:

It's not the first time someone is confused by the server example of

https://docs.python.org/3/library/socketserver.html

where the receiving side is not making a loop over recv.

This is a trivial example indeed. If you think something more realistic yet simple is desirable, we welcome contributions :-) You can take a look at https://docs.python.org/devguide/ to get started.

Moreover the documentation contains a misleading description of what really happens:

"The difference is that the readline() call in the second handler will call recv() multiple times until it encounters a newline character, while the single recv() call in the first handler will just return what has been sent from the client in one sendall() call."

Unless I'm missing something there's no way to know client side when all data sent by "sendall" has been received (TCP stream protocol doesn't have message boundaries) and the `recv` based code doesn't handle neither fragmentation nor clients that send more than 1024 bytes.

Indeed, the quoted paragraph is wrong.

Am I missing something or that is indeed an example of how NOT to write a socket-based server?

The problem is coming up with an example that reflects better practices while being simple enough :-) Regards Antoine.

On Thu, 23 Apr 2015 09:21:11 +0200 Andrea Griffini <agriff@tin.it> wrote:

It's not the first time someone is confused by the server example of

https://docs.python.org/3/library/socketserver.html

where the receiving side is not making a loop over recv.

This is a trivial example indeed. If you think something more realistic yet simple is desirable, we welcome contributions :-) You can take a look at https://docs.python.org/devguide/ to get started.

Moreover the documentation contains a misleading description of what really happens:

"The difference is that the readline() call in the second handler will call recv() multiple times until it encounters a newline character, while the single recv() call in the first handler will just return what has been sent from the client in one sendall() call."

Unless I'm missing something there's no way to know client side when all data sent by "sendall" has been received (TCP stream protocol doesn't have message boundaries) and the `recv` based code doesn't handle neither fragmentation nor clients that send more than 1024 bytes.

Indeed, the quoted paragraph is wrong.

Am I missing something or that is indeed an example of how NOT to write a socket-based server?

The problem is coming up with an example that reflects better practices while being simple enough :-) Regards Antoine.