Boost logo

Boost :

From: Hamish Mackenzie (hamish_at_[hidden])
Date: 2002-11-25 17:53:22

On Mon, 2002-11-25 at 20:57, Boris Schäling wrote:
> > Looks good but am I correct in thinking it uses blocking writes to the
> > socket? (no on_write). This is ok for some applications but would not
> > work for sending large files or streaming live content.
> The library uses non-blocking write. If a write returns EWOULDBLOCK the
> library waits for the socket descriptor to be writable and then writes
> again. The application developer does not need to take any action.

>From your example

    void on_connect(communicator *c, int sock) {
      s = new stream(&mpx, this, sock, 0); // params: multiplexor, stream observer, socket descriptor, timeout value
      s->writen("GET / HTTP/1.0\r\n\r\n");

This looks like a blocking write to me. What if there was not enough
room in the buffer for this writen (say I wanted to do an HTTP post
including a 5GB file as the post data). You need an on_write member to
let you know when it is ok to do another write to the socket.

My suggestion is that you could create an streambuf/istream

class ihttp_post_buf : public std::streambuf
    ihttp_post_buf( headers_type & headers, std::istream & post_data );

class ihttp_post_stream : std::istream
        headers_type & headers, std::istream & post_data )
        : std::istream( new ihttp_post_buf( headers, post_data ) ) {}

Instead of the write call in on_connect you would have

    ihttp_post_stream write_stream_;
    std::istream & write_stream() { return write_stream_; }

And instead of calling on_write the library would call
write_stream().read() to get more data to write to the socket.

You could wrap post_data with a chunk encoding filter or a zip filter or
a base 64 encoding filter....

> > It seems a bit odd at first (read_stream is an ostream). But the idea
> > is that read_stream and write_stream would return non blocking streams
> > (or at least streams less likely to block than the socket)
> Maybe it is possible to wrap the stream in a std::istream/std::ostream-like
> class. Then everyone can choose what he likes?

I don't mind if there is a lower level that has on_read/on_write events
but it needs both, not just on_read. Keep in mind its not the socket I
want to wrap in iostreams.

Hamish Mackenzie <hamish_at_[hidden]>

Boost list run by bdawes at, gregod at, cpdaniel at, john at