How to check client shutdown?

[Chris Angelico]

On Wed, Aug 28, 2013 at 6:22 AM, Irmen de Jong <irmen.NOSPAM at 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