Skip to content

Commit fe0f544

Browse files
[3.11] gh-111112: Avoid potential confusion in TCP server example. (GH-111113) (#114832)
gh-111112: Avoid potential confusion in TCP server example. (GH-111113) Improve misleading TCP server docs and example. socket.recv(), as documented by the Python reference documentation, returns at most `bufsize` bytes, and the underlying TCP protocol means there is no guaranteed correspondence between what is sent by the client and what is received by the server. This conflation could mislead readers into thinking that TCP is datagram-based or has similar semantics, which will likely appear to work for simple cases, but introduce difficult to reproduce bugs. (cherry picked from commit a79a272) Co-authored-by: Aidan Holm <[email protected]>
1 parent e66ad91 commit fe0f544

File tree

1 file changed

+4
-3
lines changed

1 file changed

+4
-3
lines changed

Doc/library/socketserver.rst

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -488,7 +488,7 @@ This is the server side::
488488
def handle(self):
489489
# self.request is the TCP socket connected to the client
490490
self.data = self.request.recv(1024).strip()
491-
print("{} wrote:".format(self.client_address[0]))
491+
print("Received from {}:".format(self.client_address[0]))
492492
print(self.data)
493493
# just send back the same data, but upper-cased
494494
self.request.sendall(self.data.upper())
@@ -519,8 +519,9 @@ objects that simplify communication by providing the standard file interface)::
519519

520520
The difference is that the ``readline()`` call in the second handler will call
521521
``recv()`` multiple times until it encounters a newline character, while the
522-
single ``recv()`` call in the first handler will just return what has been sent
523-
from the client in one ``sendall()`` call.
522+
single ``recv()`` call in the first handler will just return what has been
523+
received so far from the client's ``sendall()`` call (typically all of it, but
524+
this is not guaranteed by the TCP protocol).
524525

525526

526527
This is the client side::

0 commit comments

Comments
 (0)