[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.
<snip>
> 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
> SERVER_FALSE
> 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
class:
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.
--DW
Other related posts:
