[haiku-appserver] Re: communication

  • From: Marc Flerackers <mflerackers@xxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Wed, 08 Jun 2005 10:46:41 +0200

It seems there are lots of ideas of how to improve the app_server 
communication. Since we seem to be deviating more and more from 
BSession, I would like to explain a bit how BSession in R5 works, and 
what its strengths are.

1. BSession has pre-allocated buffers

For reading as well as writing, the session has a buffer which is 
created at app startup. This means that when data like an int32 is 
added, it's just copied into the buffer and the buffer position is 
increased. There is no overhead from allocation/re-allocation. So what 
if the buffer is full? Well we flush it.

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 

3. BSession reading

When we read from a BSession, just like writing, we actually read from 
the buffer. When we read at the end, the buffer position is resetted, 
and new data from the port is copied into the buffer.

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 

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.

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.

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.

Marc Flerackers

Other related posts: