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!
Stjepan