Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Return-Path: <rosuav@gmail.com>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
X-Spam-Status: OK 0.073
X-Spam-Evidence: '*H*': 0.86; '*S*': 0.00; 'argument': 0.05; 'anticipate': 0.09; 'subject:How': 0.10; 'boundaries,': 0.16; 'byte,': 0.16; 'downside': 0.16; 'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16; 'marker': 0.16; 'partly': 0.16; 'receive.': 0.16; 'requested.': 0.16; 'suggested,': 0.16; 'tcp': 0.16; 'wrote:': 0.18; 'wed,': 0.18; 'example': 0.22; 'aug': 0.22; 'putting': 0.22; "haven't": 0.24; '(or': 0.24; 'right.': 0.26; 'header:In-Reply-To:1': 0.27; 'rest': 0.29; 'chris': 0.29; 'leave': 0.29; 'am,': 0.29; 'reaches': 0.30; 'message- id:@mail.gmail.com': 0.30; 'usually': 0.31; 'actual': 0.34; 'noticed': 0.34; 'could': 0.34; 'but': 0.35; 'received:google.com': 0.35; 'collecting': 0.36; 'done': 0.36; 'subject:?': 0.36; 'two': 0.37; 'performance': 0.37; 'server': 0.38; 'depends': 0.38; 'to:addr:python-list': 0.38; 'issue': 0.38; 'short': 0.38; 'anything': 0.39; 'does': 0.39; 'to:addr:python.org': 0.39; 'length': 0.61; 'full': 0.61; "you're": 0.61; "you'll": 0.62; 'such': 0.63; 'more': 0.64; 'between': 0.67; 'anything.': 0.68; 'upper': 0.74; 'special': 0.74; 'guaranteed': 0.75; 'detecting': 0.84; 'guaranteed.': 0.84; 'receiver': 0.84; 'subject:check': 0.84; 'reliable,': 0.93; '2013': 0.98
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=E19TtxspUD1E8EGBDGYoY5PAZrpRM+viUJ6r+lf0GRU=; b=OgPESoIOcrHq3tORvZtB5dUbh7C7JBCPXYVhyfAU3yuoDSjN5oW2JGGW7QOKrFcndb kR+/bgv8Ce64w4d69XMytEkWtZKUyY5NVz5U9dPp/9Q6Gg/Rc4HBuY61w4SICgZ1YVqe EwpHK8R6RXKH9e+6ZgFlezr4kqv2O1iocZx2MFcDlkwL1Xh3BXSMzEycq2ZUehJgUtc6 4b55HkU6p8v5ehQfVITCD9dKlnc7c+a0p1MXV4c6DbRZZt+bk+SM63qGdShhgdL0H9Si Klc8zYdtABa+k/WGbwd2vPGhQUNWcUAeogqvwmsy8L5m1HdhMfTGxvdAcvp8w7EDIyjw 7OBA==
MIME-Version: 1.0
X-Received: by 10.220.181.136 with SMTP id by8mr22411370vcb.11.1377636007120; Tue, 27 Aug 2013 13:40:07 -0700 (PDT)
In-Reply-To: <521d0a99$0$15900$e4fe514c@news.xs4all.nl>
References: <f543172d-85e6-467d-9fc8-f59d41381edd@googlegroups.com> <mailman.245.1377547782.19984.python-list@python.org> <2f3e7c96-45a7-485c-bfc7-18bf9841114b@googlegroups.com> <521d0a99$0$15900$e4fe514c@news.xs4all.nl>
Date: Wed, 28 Aug 2013 06:40:07 +1000
Subject: Re: How to check client shutdown?
From: Chris Angelico <rosuav@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=ISO-8859-1
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-list/>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <http://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups: comp.lang.python
Message-ID: <mailman.284.1377636010.19984.python-list@python.org>
Lines: 23
NNTP-Posting-Host: 2001:888:2000:d::a6
X-Trace: 1377636010 news.xs4all.nl 15872 [2001:888:2000:d::a6]:37951
X-Complaints-To: abuse@xs4all.nl
Xref: csiph.com comp.lang.python:53093

On Wed, Aug 28, 2013 at 6:22 AM, Irmen de Jong <irmen.NOSPAM@xs4all.nl> wrote:
> ? What is the actual downside of having
>> the server set to anticipate a message length which is known to be more than will be
>> sent (or be allowed to be sent?), for example connection.recv(10000). Does not the
>> receiver know the size after the fact? Is it impacting performance somehow (I haven't
>> noticed anything in my tests)
>
> The issue is that recv() is not guaranteed to return you the full amount of data that is
> requested. It may very well just return a single byte, and leave the rest for later. The
> argument is an upper bound on the amount of data you receive. So to make your recv
> reliable, you need to have a means of deciding when the 'full' amount of data has been
> collected. As Chris already suggested, this is usually done by putting the recv() in a
> loop and collecting data until it reaches a length that you precisely know beforehand,
> or by detecting a special end-of-message marker in the data stream, such as a newline.

Right. When you use TCP sockets, there's no  boundaries, so you could
get two pickles in one recv, or you could get one and a half, or
anything. It depends partly on your buffer sizes and things; if you're
sending very short messages (less than a kilobyte), and have long
delays between them, chances are you'll get one write in one read; but
it's not guaranteed.

ChrisA