[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
loop.
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
protocol.
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
- Follow-Ups:
- [haiku-appserver] Re: communication
- From: Axel Dörfler
- References:
- [haiku-appserver] Re: communication
- From: Axel Dörfler
Other related posts:
- » [haiku-appserver] communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- [haiku-appserver] Re: communication
- From: Axel Dörfler
- [haiku-appserver] Re: communication
- From: Axel Dörfler