On Wed, Aug 28, 2013 at 6:22 AM, Irmen de Jong <irmen.nos...@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 -- http://mail.python.org/mailman/listinfo/python-list