En Mon, 30 Apr 2007 11:22:23 -0300, <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
