From: Iain K. Hanson (iain.hanson_at_[hidden])
Date: 2005-04-27 08:33:52
On Tue, 2005-04-26 at 12:52 -0400, Rob Stewart wrote:
> From: "Iain K. Hanson" <ikh_at_[hidden]>
> > On Tue, Apr 26, 2005 at 02:31:43AM +0300, Boris wrote:
> > >
> Async is an issue because you have to deal with the EWOULDBLOCK
> condition. However, you are raising a new issue regarding the
> possibility that an internal buffer of the data to be written on
> the socket can't be written. That can mean that a portion of an
> object written with << will be in the buffer, but there's no way
> to know which portion. Have I got your point right?
O.k. The buffer is absolutely necessary otherwise, as I have posted
previously, you will invoke Nagle, delayed ack, and slow start.
The buffer size must be specified by the user and is ideally some
multiple of MSS.
There are a few application layer protocols that just ship bytes over
the wire such as the data channel of FTP. Most applications have a
protocol or message structure.
The prudent network programmer works out the size of the largest message
and makes their buffer at least that large. They can then stream the
data to the stream which can marshal the data into the buffer. You would
the do an explicit flush ( std::endl ) and it is this operation and only
this that can create socket errors.
You will want mechanisms similar to those in std::iostream for dealing
with errors i.e. both exceptions and failbit but adapted for network
Of course, it is the responsibility prudent network programmer to check
for the stream status if they have disabled exceptions and to always
explicitly flush the stream and not allow overflow to do it for them.
If perchance you were to stream out a uint32_t and overflow the buffer
then if your program was not keeping track of the number of bytes
written then obviously the streambuf knows how many bytes it contains.
But doing this, is, as I have said before, an error IMHO.
This email has been scanned for all known viruses by the MessageLabs Email
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk