CODEWITHSUNDEEP
pythonsocketsdoublemessage
SuperDisk
SuperDisk

Reputation: 2840

TCP Sockets: Double messages

I'm having a problem with sockets in python.

I have a a TCP server and client that send each other data in a while 1 loop.

It packages up 2 shorts in the struct module (struct.pack("hh", mousex, mousey)). But sometimes when recving the data on the other computer, it seems like 2 messages have been glued together. Is this nagle's algorithm?

enter image description here

What exactly is going on here? Thanks in advance.

Upvotes: 1

Views: 1837

Answers (3)

user1277476
user1277476

Reputation: 2909

I agree with other posters, that "TCP just does that". TCP guarantees that your bytes arrive in the right order, but makes no guarantees about the sizes of the chunks they arrive in. I would add that TCP is also allowed to split a single send into multiple recv's, or even for example to split aabb, ccdd into aab, bcc, dd.

I put together this module for dealing with the relevant issues in python: http://stromberg.dnsalias.org/~strombrg/bufsock.html It's under an opensource license and is owned by UCI. It's been tested on CPython 2.x, CPython 3.x, Pypy and Jython.

HTH

Upvotes: 1

torek
torek

Reputation: 487755

To be sure I'd have to see actual code, but it sounds like you are expecting a send of n bytes to show up on the receiver as exactly n bytes all the time, every time.

TCP streams don't work that way. It's a "streaming" protocol, as opposed to a "datagram" (record-oriented) one like UDP or STCP or RDS.

For fixed-data-size protocols (or any where the next chunk size is predictable in advance), you can build your own "datagram-like receiver" on a stream socket by simply recv()ing in a loop until you get exactly n bytes:

def recv_n_bytes(socket, n):
    "attempt to receive exactly n bytes; return what we got"
    data = []
    while True:
        have = sum(len(x) for x in data)
        if have >= n:
            break
        want = n - have
        got = socket.recv(want)
        if got == '':
            break
    return ''.join(data)

(untested; python 2.x code; not necessarily efficient; etc).

Upvotes: 1

Chris Stratton
Chris Stratton

Reputation: 40337

You may not assume that data will become available for reading from the local socket in the same size pieces it was provided for sending at the other source end. As you have seen, this might sometimes be usually true, but by no means reliably so. Rather, what TCP guarantees is that what goes in one end will eventually come out the other, in order without anything missing or if that cannot be achieved by means built into the protocol such as retries, then whole thing will break with an error.

Nagle is one possible cause, but not the only one.

Upvotes: 0

Related Questions