[haiku-appserver] Re: communication

  • From: "DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Tue, 07 Jun 2005 09:14:12 -0400 EDT

> 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();
Nothing. I was just listing constraints for BPortLink. This one's 
already covered. :^)

> 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).
AS_SERVER_SESSION should never be used. It is cruft left over from the 
BSession vs PortLink debates. There is one unified format, so the only 
thing we should see is AS_SERVER_PORTLINK.

> > > 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.
I'm totally in agreement of the recent discussions of utilizing one 
port for replies. My thought is to have a lock-protected port which 
belongs to the BPortLink class - a private port_id declared static and 
protected by a BLocker. Comments?

> 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.
I've been mulling over how to fix PortLink properly, and there is 
another issue with PortLink as it is. There are occasions where a 
message protocol has been changed on one side and not the other, and 
the client or the server crashes, hangs, or starts using weird data. 
There needs to be some way to reduce the problems with attachments. 
Here's what I propose: scrap PortLink for something else which we know 
works: BMessage, Dano-style. It's a massive changeover, but I think it 
would also be very much worth it.

The original reason for PortLink was a low-overhead messaging class. 
The reason? All the Flatten() and Unflatten() calls had serious 
overhead. Be even acknowledged this and changed the format in Dano 
which used a flattened format to start at the expense of some extra 
space. If this were the case, we could use a format code just like we 
do now and the buffer would contain the message. A queueing class could 
be put together relatively quickly to group write_port calls for BView. 
Thoughts?

> > 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.
I don't think that would be a very good idea at this point- there may 
be effects on responsiveness which are currently unforseen. However, 
once the messaging subsystem and the app_server are more stable, I 
wouldn't have a problem with someone at least looking into it.

--DW


Other related posts: