|
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
{
public:
ihttp_post_buf( headers_type & headers, std::istream & post_data );
...
};
class ihttp_post_stream : std::istream
{
public:
ihttp_post_stream(
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk