socket module - recv() method

[Gabriel Genellina]

En Mon, 30 Apr 2007 11:22:23 -0300, <mirandacascade at yahoo.com> escribió:

> All of the client apps on which this technique is employed are very
> predictable in the sense that  the client apps always know in advance
> the value of endOfMessageText.
>
> Questions:
> 1) is it theoretically possible that a client app will want to send a
> request and receive a response where the response message does not
> have something that unambigusously marks its end?

Theoretically, yes, but such protocol would be hard to implement and  
unreliable.
The message should contain enough information to determine when it's  
complete: apart from your example of known terminator, you could have a  
header stating the message size; or the number of elements of known size;  
or the number of elements, each one stating its size; or several elements,  
each one telling its size, ending with an empty element; or all messages  
being of fixed size; or all messages having a "type" field, where the  
message size is known for each type.
All of them have been used and have drawbacks and advantages. The best  
choice depends on how data is better described, the desired  
robustness/expansibility/reliability/simplicity, and how much logic can  
you put on the sender side or the receiver side.

If the message itself does *not* allow to determine when it's complete  
(not a good thing), you have to rely on external signals (connection  
closing, by example) but that's not very reliable.

> 2) if so, are there any best-practices techniques for constructing the
> code such that the client app knows that there is nothing else in the
> response message?

If you are free to design the protocol, choose from the above suggestions  
or other suitable ways. A fixed terminator is easy to implement (but you  
have to guarantee that it cannot happen inside the message, or replace it  
someway)

-- 
Gabriel Genellina