[haiku-appserver] Re: communication

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Tue, 07 Jun 2005 16:11:34 +0200 CEST

"DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx> wrote:
> 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.

I agree.

> > 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?

That shouldn't be needed, although it would keep the messaging alive 
while waiting for an answer. Currently, the BPortLink assumes to be 
synchronized - the BAppServerLink does this on its own, while other 
links usually use the synchronization from their parent. IOW, only the 
BAppServerLink would be able to gain from such a change.

> > 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.

Sure, that would solve lots of the problems. OTOH it's a lot more 
expansive, too. BMessages would need to be changed a lot, too, since 
they currently can't be merged together for a simple port write.
Stephan proposed to use structs, just like the debug server does. This 
would lighten the problem as well, but wouldn't solve it as good as 
BMessages would.

> 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?

A BMessage would still be substantially more expansive than BPortLink. 
I have no idea if the system is fast enough to make this difference 
But I don't think we should do this now - as Adi said, Be used even 
something simpler than BPortLink. It really only gets to be problematic 
when we start sending messages over the network, where two clients can 
have different versions of libbe.so. IOW we would need to never change 
the size of any "code", but instead using new ones (or make the new 
fields optional).
We own the code, so (apart from bugs), we only really need to care 
about backwards compatibility.


Other related posts: