Boost logo

Boost :

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-04-24 02:29:23

Hi Scott!

On 4/23/07, Scott Woods <scottw_at_[hidden]> wrote:
> The threading architecture of the server will be specific to each server. I
> don't think you can arbitrate on that one without coming unstuck. A
> minimal server will have at least one thread dedicated to the socket
> activity
> and at least one application thread.
> Maybe some worked examples involving typical arrangements?

OK - I'll shoot for providing one thread for the socket activity and
one application thread as a minimum, plus (eventually) additional
application / function threads on request (i.e., a client could
request from the server a separate application thread, and/or a
separate thread for a function call).

> If you are adhering to the RPC model I think there should be
> no async options (even though the underlying network
> activity is async). The OK packet returned for an invocation
> that has no return type is a synchronization, i.e. the caller knows
> that the function has indeed completed.
> While this may seem unnecessarily limiting its cleaner and
> more consistent (with RPC). If the user wants concurrency
> of server activity then they should be using an async model for
> their application code as well as using an async messaging lib.
> Bending RPC just makes it ugly and you weaken/lose the metaphor.

I agree that an async call is bound to be messy with what's available
now - but a good futures implementation might provide an elegant
mechanism on providing the call results when they come back. I'll
focus on the sync functionality for now.

> >
> > * right now, the network protocol is rather clumsy - there's one or
> > <snip>>
> Sorry, this area is a mine field. I have my own solutions to framing
> of messages in the presence of fragmentation and nagling. Don't
> know that asio or serialization really tackles these and others directly.

I fixed the protocol I was using to have a fixed size header, so I
know exactly what to expect when and in what size... this made all the
difference. I needed a good nights's sleep to figure out what I
needed to do :-)

> I think you are focused on RPC (with an async twist), which was your
> stated intention. This means that the re-usability of the resulting
> socket code is at best a secondary goal. My intentions are almost
> perfectly inverted but I'll continue to eavesdrop and offer feedback
> when I can.

As far as re-usability of the socket code, the server and client
components take a template parameter that specifies the underlying
connection/authentication mechanism. I implemented a very primitive
pair of classes (simple_connector and simple_acceptor) which are
trivial mappings onto the asio functionality - the connector asks
acceptor for a socket and the acceptor sets it up, then the socket
connection is used between the client and a dedicated registry_server.

Making this a template parameter is meant to allow easy inclusion of
other authentication schemes - I will try to add something that's a
little more involved as an example (for example, an acceptor that only
grants sockets to clients with certain IP addresses, or a very simple
password mechanism). Anything more along these lines is probably
beyond me though :( However, any socket code that was developed here
could be reused for other purposes, as long as the required interface
was the same.

Your feedback is much appreciated!


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