Re: [cpp-netlib-devel] Insights to the Message Class and Network Routines

[Peter S. <si...@cr...>]

Hi guys!

 > [The idea for a message class is that it can be used like so:]
 >
 > class my_handler  {
 >   void handle(boost::network::message & msg) {
 >     // manipulate the message however i want to
 >   };
 > };

I wonder at what times during the HTTP transmission this handler
function would be invoked? From the server's perspective, the
relevant state changes occur here:

 1) Complete HTTP header was received. Callback has a chance to
    say "error response" without waiting for the body to be
    transmitted. (Errors generally have "Connection: close" and
    can be written early in the HTTP dialogue.)

 2) Body data is received.

    a) Body still incomplete? Then the handler has the chance to
       do something with the data we already have. If possible,
       the handler should take ownership of the memory because
       bodies may be very large ("upload") and the HTTP doesn't
       want to buffer all that in its entirety.

    b) Body complete? Invoke the handler so that it has the
       chance to put a response into the output buffer.

 3) Output buffer is empty.

    a) Does the handler have more data that needs to be written?
       Then go back to (3).

    b) The transaction is complete.

Does that make any sense?

What is the situation regarding protocols other than HTTP? SMTP,
for instance, has no real use for the boost::network::message
class because the payload is opaque for the server. There even is
an ESMTP extension CHUNKING (a.k.a "Binary MIME") that treats the
payload as an 8-bit octet stream without further structure. An
e-mail can be represented as a boost::network::message, but an
SMTP server doesn't really it.

Applications that do need 'message', however, would be mail
readers, news readers, and all kinds of mail-to-something-else
converters. That is a fairly large market, given what kind of
devices can deal with e-mail these days.

 >   http::server<my_handler> handler_instance;
 >   boost::thread http_thread(handler_instance);
 >   http_thread.join();

How would the http::server<T> class mentioned here be used in a
single-threaded environment? Not every device that knows how to
speak IP also knows how to do multi-threading. In my humble
opinion, multi-threading should be an option, but no requirement.

How do others feel about this subject?


 >> An asynchronous DNS resolver is badly missed. Implementing
 >> the DNS protocol from scratch is, however, a significant
 >> effort. It might be wise to base our efforts on one of the
 >> existing libraries, e.g.:
 >>
 >> http://www.chiark.greenend.org.uk/~ian/adns/
 >> http://daniel.haxx.se/projects/c-ares/
 >
 > Chris Kohlhoff has proposed a way of using future<> and promise<>
 > objects to implement asynchronous DNS lookups using a Singleton Active
 > Object DNS resolver.

Exactly, a DNS server invokes the proper handler function every
time a response is received, and because of the stateless nature
of the DNS protocol, there is no need for having more than one
resolver per process. What I don't understand is how these
insights get anyone any closer to implementing the DNS protocol.

Neither Adns nor C-Ares care what I/O main loop drives them; both
libraries are concerned with interpreting DNS datagrams. My
personal opinion is that it would be an incredible waste of time
to re-invent that wheel. I noticed, though, that Chris has a
knack for re-inventing perfectly good wheels every know and then.
I guess it's actually quite likely that he'll end up
re-implementing DNS. I'll let myself be surprised.


 >   try {
 >     timeout_read(socket_ptr, buffer, boost::posix_time::seconds(30));
 >   } catch (boost::network::read::timeout & e) {
 >     // the read has timed out.
 >   };

I don't think that function can exist in a non-blocking I/O
model. Unless, of course, setjmp() / longjmp() counts as a
solution. ;-)


 > msg["SOME_HEADER"] = "SOME_CONTENT" might work if the internal
 > representation of a message is a std::map<...>, I'm not
 > entirely sure this makes sense for a multimap (like what we're
 > currently using).

It's difficult to say whether a map or a multi-map is the best
choice. The problem is that some protocols require a multi-map
and some protocols don't. An e-mail may have any number of
"Received:" lines. In HTTP, however, headers are generally
unique.

Anyway, this is a stimulating conversation. It's fun to think and
talk about these topics.

Best regards,
Peter