On Mon, Apr 25, 2005 at 11:45:06PM +0300, Boris wrote:
Rob Stewart wrote:
From: "Boris" <boris@gtemail.net>
Rob Stewart wrote:
From: "Boris" <boris@gtemail.net>
How would the user level code know which insertion or extraction to repeat in an expression like this:
s << a << b << c << d;
Socket streams supporting non-blocking I/O would require the user to check the result of I/O operations. However this should already be done with today's std::iostreams. If s is eg. of type std::ofstream and a call to << fails you have the same problem, don't you?
Yes and no. When writing to a file, you can inspect its contents and determine what's missing. You can also delete it and rewrite it from the beginning. With sockets, you can't seek back to determine where you left off. Instead, clients must establish a protocol that permits resending a block of data, even if the receiver has had no problems reading data to that point.
IOW, if a given message required more than one TCP block, the receiver will have read some number of blocks and will expect more to complete the current message. The protocol will have to recognize that the sender restarted the current message, throw away the currently read data (from the successful blocks), all because the sender couldn't figure out which insertion (<<) failed. Do you intend to impose that requirement on clients?
I was under the false assumption that "s << a" either completes successfully or fails completely. But you are right: If a part of object a is sent we don't know. Thanks for jumping in! I agree now that socket streams can only support blocking I/O.
Why do people think that just because you are using an iostream interface you can break the basic rules of TCP programming!!! Using iostreams there must be a buffer ( usually a streambuf ). The buffer size *must* be equal tp the MSS / path MTU. As the application protocol writter you have to know how much you have written to the buffer *at all times* and you must know when an overflow / flush will happen. Errors can *only* happen when the buffer writes to the socket ( overflow/flush ) therefore if a programmer does his/her job correctly there will not be multiple operator << traversing and overflow boundary. This is irrespective of sync/async. Braek the rules in network programming and you are up the proverbial creek without a paddle. And C++ can not protect you against all kinds of errors. We can only make it saffer, not safe. /ikh>