Path: csiph.com!usenet.pasdenom.info!news.redatomik.org!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <mka456$iek$1@reader1.panix.com>
References: <CAO2fJ-+UjZNqo2yQRRkuSsEJwFAGOnbB9JPCCWX7zX7jt_5POg@mail.gmail.com> <CAGGBd_pEf0E6skDgzVuWLsPEX73OvpTkQ=CwgjKF6Yz+fC6bsw@mail.gmail.com> <mailman.181.1432910260.5151.python-list@python.org> <mka456$iek$1@reader1.panix.com>
Date: Sat, 30 May 2015 02:40:06 +1000
Subject: Re: Accessing DataSocket Server with Python
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.196.1432917609.5151.python-list@python.org>
Lines: 28
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:91475

On Sat, May 30, 2015 at 2:29 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> If you assume TCP read/write operations are atomic and "message"
> boundaries are preserved, your code is wrong.  It will eventually
> fail.  Period.

Indeed. That said, though, if your writes are all smaller than one
packet, and you perfectly alternate a write and a read, a write and a
read, at both ends, then you can go a very long way without ever
running into this. In that case, you could have proper parsing and
buffering as a failure case, with the normal case expecting a
termination mark at the end of the socket-read - something like this:

write(query)
data = read(as_much_as_possible)
if data[-1] != "\n":
    # Huh, stuff got split.
    while True:
        more_data = read(as_much_as_possible)
        data += moredata
        if data[-1] == "\n": break
        cope_with_possibility_of(socket_disconnection)
handle_response(data)

Alternating writes and reads ensures that two messages can't be
combined, and if a single message fits inside a packet, it'll usually
be sent that way. But you still can't guarantee that.

ChrisA