[haiku-appserver] Re: communication

Adi Oanca <adioanca@xxxxxxxxxxxxxx> wrote:
> > A while after Adi came on, he found that we needed to have some 
> > message 
> > caching on the client side, so the whole PortLink vs Session thing 
> > came 
> > about. Pahtz eventually resolved it by integrating both classes 
> > into 
> > something which at least in concept would work well.
>       Yup, in concept. I wonder what happens if I want to transfer a
> 10K region? That region will be transfered to app_server, but the 
> buffer
> will remain at 10K ! That's a _bad_ thing as the buffer is too big 
> for
> caching drawing commands and the GUI will be less responsive. It's
> enough that the initial buffer has 2K (R5's one is 1K), but 10K is 
> already
> too much!

Right, that's also a problem.

[...]
> > 1) Messages need to be able to be sent on a one-at-a-time basis

What's wrong with:
        link.StartMessage(x);
        link.Flush();
?

> > 2) Message caching needs to be possible to help with speed in 
> > handling 
> > BView drawing messages by grouping calls to write_port()
> > 3) It shouldn't be possible to just write a random message to any 
> > of 
> > the server's ports and crash or hang the server
>       That's not easy doable with current format.

We can at least easily make it a lot safer. What I am thinking of is 
the following and costs 4 bytes with each port write:
- have a special port code; right now, there is AS_SERVER_SESSION and 
AS_SERVER_PORTLINK that are used in a non-predictable way
- calculate a checksum over the first message header and place it as 
first uint32 in each buffer sent

Checksum calculation would be as easy as a+b+c (as a message header 
currently consists out of 3 bytes).

> > 4) Synchronous replies need to be possible
>       As long as there are 2 ports there is no problem.

And I think that's the way to go, anyway. The app_server usually knows 
the reply port.

Anyway, I've looked over the messaging, and this is what I think is 
problematic:
a) Attach() may fail and cause a partial message to be sent (since we 
don't do proper error checking)
b) if the app_server gets a message that needs a reply, but doesn't 
know that message (client has a different version, or whatever), the 
client will hang instead of receiving an error
c) messages tend to be moved in the buffer when you're close to the end 
- it would be simpler to just flush the buffer beyond a certain 
watermark; that would greatly reduce the need to move messages around 
(and also solves the problem with enlarged buffers)
d) the response of the server (SERVER_TRUE/SERVER_FALSE) is not 
significant enough.

If you don't mind I can go over the code and do what I just proposed 
over the next few days.
That should make the app_server a lot more robust.

> 5) should we group mouse_moved messages that come from input_server?
> If yes, then we need to be able to read all messages present in 
> port's
> queue. Current implementation does not allow this.

It wouldn't be too hard to change, I think. But the one evaluating 
mouse messages shouldn't do any window moving anyway. Right now, the 
mouse is unusable in VESA modes (when you move a window).

Bye,
   Axel.

Other related posts: