Home Original page

select.select and socket.setblocking

Saju Pillai saju.pillai at gmail.com
Wed Dec 31 09:55:59 EST 2008 
On Dec 31, 7:48 pm, Francesco Bochicchio <bock... at virgilio.it> wrote:
> < ... >
>
> >> Uhm. In my experience, with TCP protocol recv only returned less than
> >> the required bytes if the remote end disconnects. I always check the
>
> > What if the sending end actually sent less than you asked for ?
>
> > -srp
>
> In blocking mode and with TCP protocol, the recv waits until more bytes
> are received -  mixing up the next message with the previous one and

Is this correct ? IIRC even in blocking mode recv() can return with
less bytes than requested, unless the MSG_WAITALL flag is supplied.
Blocking mode only guarantees that recv() will wait for a message if
none is available - but not that it *will* return the number of bytes
requested.

-srp

> then loosing the 'sync' and being unable to interpretate the received
> data -  or the remote end disconnects.
>
> Yes this is bad,  and is a good reason why socket receive should be
> handled   in non-blocking mode if you receive data from untrusted
> sources. But luckily for me, as I said in the other post, I used socket
> mostly to communicate between specific applications on a private LAN or
> WAN, so I could afford to ignore the problem.
>
> Ciao
> ----
> FB
More information about the Python-list mailing list