Re: [boost] Re: State of giallo, (sockets and demultiplexing)

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-09-16 11:03:57

On Thu, 16 Sep 2004 07:49:20 -0400, Hugo Duncan wrote
>
> > Are you talking about the ACE Message Block / ACE Message Queue stuff?
> 
> The Message Block stuff, yes, but not wholesale. Trying to make it easier
> to use.

Ok, at the end of the game it's main use in ACE seems to be for implementing
queues for active objects and sending data across threads.  Of course it's
ugly because it's not typesafe (at least without alot of effort).  In a fairly
recent project a co-developer wrote his own using a condition variable and
std::queue -- he did this instead of using the ACE queues b/c it was cleaner. 
 
> Isn't this just one use case?  

Well, I suppose there are others but this is the one I run into all the time..

> Is a streambuf all you need to be able to support this?  

No, I actually need the stream on top of the streambuf so I can do formatted
writes/reads to the buffer.  Then I need to be able to use the buffer contents
to send via the socket -- ideally without copying.  BTW, I've done this using
std::stringstream before.  It was 'horribly inefficient' since I had to bulk
copy the streambuf contents to the socket after I was done serializing on
write and had to bulk copy to the buffer on read (although I'm not 100% sure I
had to copy on read now that I think about it).  Anyway, the code was simple
and clean and the peformance hit for this app was minimal.

>How would you implement a protocol stack?

I'd probably build up a series of serializeable objects that contain other
serializeable objects.  Or I might have a specialized archiver that knows how
to build protocol headers since often times the protocol wrappers need to know
nasty little details like the length of the message.
 
> > So if I'm writing some network code, I'm thinkin I just want to use
> > boost.serialize to do the serialization and it needs a stream to do  
> > that.  And
> > actually, I'm curious if the file descriptor wrapper in the IOStream  
> > library
> > wouldn't pretty much take care of it?
> 
> using boost.serialize and spirit are two examples that I would like 
> to build.  I have started an http_server that uses spirit to parse 
> the header, but early days yet...

HTTP server sounds like an ambitious example :-)  But sure serialize and
spirit a huge pieces of the puzzle here.
 
> What I was trying to say was that I have been unable to implement a  
> streambuf that uses asynchronous IO without having the implementation 
> of the  streambuf degenerate to thread per connection.  The only way 
> I could think of getting asynchronous IO notification to work is to 
> have the streambuf block on a condition variable after read/write 
> and have that condition variable notified in the io completion 
> routine. ie, as far as I can see, the streambuf concept is broken 
> if you do not want a thread for each connection.

Yeah, I see.  No doubt we are going to need to enhance the streambuf concept
to deal with async i/o.  I'll have to ponder this a bit if I can ever get my
head above water on the email chain, etc...

Jeff