[haiku-appserver] Re: communication

  • From: Marc Flerackers <mflerackers@xxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Wed, 08 Jun 2005 16:13:59 +0200

Axel Dörfler wrote:
> Marc Flerackers <mflerackers@xxxxxxxxxx> wrote:
> [...]
>>2. BSession flushing
>>BSession is flushed at several occasions. The first one is obvious, 
>>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 
> How periodically is it done?

An example of this would be after a pulse message is handled in 
BWindow's DispatchMessage. If you create an app with a view with the 
style B_PULSE_NEEDED, and in the Pulse method you call StrokeLine with 
some randomness, you'll see that the lines are drawn periodically, 
however, you just call strokeline, so the command would sit there in the 
queue. So after BWindow calls Pulse recursivelly for all needed views, 
it flushes the session.

> Also, when you send large messages, BSession will get very slow. A 
> different solution should be used in that case.

Some app_server commands in R5 do indeed use the shared area instead of 
the port for transfering the data. However some commands differ in size. 
Sometimes you call drawlines with a few lines, sometimes with a lot of 
them. bitmaps can be small or big, pictures can be simple or complex. In 
case of bitmaps for example, R5 uses several ways depending on the 

>>5. BSession doesn't know the size of fixed size commands
>>Also this is no problem, as the protocol is defined, like a standard. 
>>a message has the wrong size, this is an indication that there is a 
>>While it is convenient to have a method to detect this during 
>>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.

Would you use the exact same messaging for a remote protocol? Area 
transfers for example would already be out of the question, and maybe a 
protocol like BPicture, where the bitmap and other data is included with 
the instruction, would be a better option. The BPicture protocol looks a 
lot like the app_server protocol with a size header of 4 bytes.

Marc Flerackers

Other related posts: