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.