Re: [boost] asio networking proposal

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2005-08-18 16:46:58

"Thorsten Ottosen" <nesotto_at_[hidden]> writes:

> "Jeremy Maitin-Shepard" <jbms_at_[hidden]> wrote in message
> news:87iry3c9cn.fsf_at_jbms.ath.cx...
[snip]
>> std::vector<char> (even with additional offset and length parameters)
>> introduces significant overhead for users that do not otherwise have any
>> reason to use std::vector.  I do not think the additional safety
>> provided is worth the cost of this overhead.

> doesn't the overhead depend on the amount of data sent?

I suppose that is true.  If a vector must be passed to the receive
function, then programs using this library will either have to use an
std::vector for any buffers used for receive, which is annoying for
users that would prefer to use a different data structure for a buffer,
and has the additional overhead of a dynamically allocated buffer and
the additional storage std::vector requires for the size, capacity, etc.
Alternatively, the user could create an std::vector just for each
receive call, then copy the data out after it completes.  In either
case, though, although the additional cost may be rather small compared
to the cost of network I/O, it is an additional cost which provides only
some additional safety, while introducing a more complex and less
generic interface.  The ideal interface would be an output iterator and
a size, but this cannot be used efficiently; an arbitrary memory range
seems like the next most generic interface, and this is also precisely
the interface supported by operating systems.

[snip]

>> Requiring that the size be known at compile-time, and that an actual
>> static-sized array be used in order to call the receive function, is
>> definitely not a good idea.

> Then why do all the examples work on statically sized arrays?

Well, there aren't many examples, and I didn't write them in any case ;)
I'll admit it is a common network I/O paradigm to read into (large)
fixed-size buffers, but there are certainly other usage patterns (such
as reading a fixed-size ``packet'' length specification, and then after
ensuring that the buffer is large enough, reading the entire ``packet''
of the specified length with a single read/recv call.  Furthermore, even
a fixed-size buffer that is used might have its size specified at
runtime.

> If we're not working on statically sized arrays, then why not use
> vector?

There are many possible reasons, but the point is, there is no reason to
force the user to use vector, when doing so provides no real benefit.

> I'm not convinced about any overhead noticable associated wirh vector.

> Besides, both versions could be provided.

Well, I think the critical version to provide would be the memory range
version (which already exists).  The other two versions could be
provided, but the std::vector version, which would be implemented as a
very simple wrapper around the memory range version, would only be
slightly more convenient than using the memory range version directly,
and the static array version would probably not be used much at all,
because it is often useful to read into only a portion of an array,
rather than always reading into the entire array.

As a side note, perhaps the names read and write should be used rather
than send and receive/recv if the library will at some point support I/O
on non-sockets, such as pipes and fifos.

-- 
Jeremy Maitin-Shepard