From: Simon Richter (Simon.Richter_at_[hidden])
Date: 2005-06-09 13:27:46
Caleb Epstein wrote:
> Please do! Does either of the implementations offer an interface to
> the sockets at a lower level than iostreams though?
Mine doesn't, so far, as I haven't seen a need for it.
> I personally prefer to use lower-level read/write semantics with
> sockets and handle would-block conditions etc in my own code.
This is the main reason why the manager code is not implemented yet: I
am still trying to think of a portable way to reset the read position if
an extractor fails due to no more data being available presently.
> Alternatively I would be happy with a mechanism whereby I could pass a
> block of bytes to be written-from (or read-to) and a callback that
> will be notified when the operation is complete. Perhaps this is one
> of the functions of the "manager" class you mention.
The manager's task is to check sockets that have pending write data for
writability and sockets which have buffer space available for
readability, and move data around in this case; the application can
register callbacks or ask for iterators over sockets that have data
available. A special "write stalled" callback is invoked when a socket
does not accept any more data, the application is then supposed to take
countermeasures before the streambuf is also full, or the socket will go
Reading binary blocks with read() and write() on the streams should be
possible, provided you use narrow streams and a do-nothing codecvt<>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk