socket module - recv() method

[mirandacascade]

Currently using the following technique in serveral client
applications to send a request message and receive a response:

import socket
bufferSize = 500000
connectionHandle = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
connectionHandle.connect(sa)
connectionHandle.sendall(requestMessage)
fullResponse = ''
# use while loop in case the entire response not sent in one chunk
while (1):
response = connectionHandle.recv(bufferSize)
fullResponse = fullResponse + response
if fullResponse.find(endOfMessageText) != -1:
break

where:
sa = 2-element tuple; 1st elem is string denoting ip address; 2nd elem
is int denoting port
requestMessage = string containing request message
endOfMessageText = string that unambiguously denotes the end of
response message

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?
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?

Thank you.

[Gabriel Genellina]

En Mon, 30 Apr 2007 11:22:23 -0300, <mi************@yahoo.comescribió:

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