[haiku-appserver] Re: communication

  • From: "DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Sat, 04 Jun 2005 13:02:14 -0400 EDT

> Yes, I noticed that, too, but no one seemed to care yet :-/
> The app_server *must* be the most robust server running on Haiku.


> It has already been rewritten several times, annoyingly. AFAICT 
> robustness was never aimed for yet.
> Anyway, I don't think we need to rewrite it completely. Since there 
> is 
> a StartMessage() we can calculate the size of the message which we 
> should just send to the server, too. Then, it would be able to skip 
> messages, and never run out of sync. Furthermore, the message code 
> alone need to carry infos like "needs reply".
> Also, we should replace the almost useless SERVER_TRUE and 
> with real error codes, a standard status_t will do here.
I agree with all that each of you have said. I would like to fill all 
of you in on the whole mess so you can at least understand why things 
are the way they are, seeing how I'm responsible for this one. *sigh*

PortLink was the first code that I wrote for Haiku, and not long after 
then entire project was founded. At that point I only had had about 1.5 
years of experience writing code. Being I'm self-taught, I didn't have 
any training in good program design. I originally had intended to use 
BMessages for all communications, but when Erik said that we needed a 
messaging class which was as lightweight as possible, I wrote PortLink. 
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. It's only been 
since probably last summer that the server has been at a point where 
stability in the BPortLink class has really been an issue - everything 
else was so unstable that it was hard to notice. ;D In short, chalk it 
up to inexperience. It probably sounds like a lame excuse, but it's 
what happened. :(

The API, by and large, works. I've found that using templates for 
attaching arbitrary data is easier than doing the same thing with 
BMessage, for example. At the same time, SERVER_TRUE and SERVER_FALSE 
are more cruft than anything else, left over from the prototype days. 
They got the job done adequately enough, so they never went away, and I 
know that there are other things just like that.

AFAICT, the message format is really what is at issue and the reason 
for all the instability. There are a few determining factors for the 

1) Messages need to be able to be sent on a one-at-a-time basis
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
4) Synchronous replies need to be possible

This is what I can think of off the top of my head and should be at 
least a start for figuring out what to do with it from here.


Other related posts: