[haiku-appserver] Re: communication

Marc Flerackers <mflerackers@xxxxxxxxxx> wrote:
[...]
> 2. BSession flushing
> 
> BSession is flushed at several occasions. The first one is obvious, 
> when 
> the buffer is full it is flushed. Flushing means the data is sent 
> through the port, and the buffer position is reset. A second occasion 
> for flushing is when we send a command which expects a reply, like 
> querying a view state. The third occasion is periodically, from the 
> app 
> loop.

How periodically is it done?

[...]
> 4. BSession works with incomplete messages
> 
> As I said, when the buffer is full, it is flushed. This could mean 
> that 
> we are in the middle of a message. However, this poses no problem. At 
> the app_server side, we read from the session and start retrieving 
> the 
> data for the command. Since the command identifier is first, we can 
> already jump in the switch statement. We can already read and convert 
> the data which we manage to read from the session. Look at it as a 
> webbrowser, a browser doesn't wait until it has the complete webpage 
> with all the data before it starts rendering the page. It's a 
> streaming 
> protocol.

That's different from what we do - our buffer need to be big enough to 
hold the complete message. I don't see this as a big problem, though, 
as it makes the message evaluation more robust - you can at least be 
sure that when you get a message, it is complete (ie. even if the app 
dies before we can reply, the message is complete).
Also, when you send large messages, BSession will get very slow. A 
different solution should be used in that case.

> 5. BSession doesn't know the size of fixed size commands
> 
> Also this is no problem, as the protocol is defined, like a standard. 
> If 
> a message has the wrong size, this is an indication that there is a 
> bug. 
> While it is convenient to have a method to detect this during 
> debugging, 
> it is not needed in a release.

Granted, as long as both protocols (client/server) are exactly the 
same, this should not be a problem. However, with remote messaging in 
mind, the protocol itself should be a bit more robust than that. The 
cost are currently 4 bytes per message, but that could be reduced to 2 
bytes - although we would then have a fixed maximum buffer size of 64 
kB which is fine by me, because it doesn't make much sense to send more 
data over a port when there is another mechanism.

> 6. BSession is not secure
> 
> About security. BSession is not used by application developers, it's 
> purely a communication mechanism between libbe and app_server. 
> Protecting it from malicious port messages is something which needs 
> to 
> be done at a port level, not at protocol level, as it is needed 
> everywhere not just in this instance.

Definitely. And I even dropped the checksum idea for now :-)

> I hope this shows at least a bit that BSession does make sense. It is 
> one of the most lightweight possibilities, and some of its appearant 
> weaknesses are in fact strengths which we lost by solving inexistent 
> or 
> weakly defined problems.

I don't agree here; our solution is even faster with bigger messages 
and more robust, too.
Allocating a bigger buffer and sending that over the port should be 
faster than doing several separate port writes.
However, with dual CPUs, that disadvantage might even be an advantage - 
at the price of a higher CPU usage and eventually more context 
switches. IOW I'm pretty satisfied with what we have now. I would just 
enlarge the initial buffer size a bit, so that it only has to be 
enlarged for special cases.

Bye,
   Axel.

Other related posts: