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. Boris