Re: [boost] Marshalling library

From: Scott Woods (scottw_at_[hidden])
Date: 2007-04-23 23:56:44

Hi Stjepan,

Gave your code a quick look.

Think I follow the flow. There are gaps in my understanding because I don't 
know
Boost as well as you do.

----- Original Message ----- 
From: "Stjepan Rajko" <stipe_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, April 23, 2007 6:03 PM
Subject: Re: [boost] Marshalling library

>
> My main questions are:
>
> * right now, the entire server-side code is running in only one
> thread.  Should there be one thread per client?  One thread per
> function call?  Is there a "best" solution or should there be options
> on this?

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?

>
> * the above schemes separates the call into
>  - the id
>  - the parameters
>  - the options (what to marshal back, sync vs. async, (exception
> reporting to come))
> It is possible that the implementation of a sync call will be
> substantially different then an async call (for example, an async call
> might use futures to return the result). Should the sync/async choice
> be placed with the marshal::call class (i.e., make a
> marshal::async_call and marshal::sync_call).  I can see both
> advantages and disadvantages to this.

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.
>
> * right now, the network protocol is rather clumsy - there's one or
> two header packets and a marshal packet in each direction (and some
> acknowledgement packets that I threw in to try to fix things but it
> didn't seem to help much)...  The advantage of this approach is that
> the header can say how big the marshal packet is (which can vary
> widely, so any preallocated buffer might be too small), but changing
> things so that there is only one packet would probably simplify things
> a whole lot.  I'm still getting familiar with Boost.Asio... if anyone
> has any thoughts on what to do I'd appreciate it.

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.
>
> OK, that's all for now... when I grab some time I'll try to document
> this thing a little better and hopefully fix it in the process.
>
> Please let me know what you think...

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.
>
> Thanks,
>

Good luck.