[haiku-appserver] Re: communication

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

Adi Oanca <adioanca@xxxxxxxxxxxxxx> wrote:
> Axel D=F6rfler wrote:
> >>>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();
> > =3F
>       link.StartMessage(x);
>       link.Attach(&z, 200.000);
>       link.Flush();
>       What about these messages=3F BSession would not had a problem.

I'm afraid I don't understand what you're aiming at here.
If it's just the size of the message, we can deal with that in the 
cases where it may happen.

>       If I send a pachet with a good checksum and malformed data
> they we're sure for a server crash.

Those messages would be accepted by the app=5Fserver, yes, but that's not 
a problem, as only malicious code would do that :-)
Also, the app=5Fserver should *never* crash, no matter what kind of junk 
is in such a message. It's really not hard to achieve this, and it's a 
necessity as well.
The checksum is just a simple means to be able to drop messages that 
were not supposed for that port.

We don't have to deal with malicious code for now, I think, as the 
whole BeOS/Zeta is a security nightmare, and Haiku R1 will simply share 
that property.

> > 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)
>       Where=3F

I was wrong there, although the code is still problematic: if a message 
could not be put into the buffer (ie. fWriteError is set), Flush() is 
ignored until a new message is started, ie. older messages are not sent 
as well.

> > b) if the app=5Fserver 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
>       And that's OK IMO. The client code assumes there's always a
> valid connection. The client knows eactly what to expect. If 
> something
> wrong happend it's time to crash.

It would be okay for now, yes, but a hanging application is certainly 
not an option in this case - it should at least crash.

> > 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)
>       IIRC, you got this the wrong way. Messages are gathered in a 
> buffer.
> Suppose we have 10 bytes left and we have a 20 bytes message to add. 
> BPortLink
> does not know we have 20 bytes. Add a int, a char, another int and 
> then a
> 3rd int. At this point it doesn't have anymore space. What it does, 
> is flush
> the buffer until the start of our message, then moves what we wrote 
> for this
> message to the start of buffer and then resume attaching data. It 
> resizes the
> buffer only if a message is greater than buffer's size.

You may not have understood me correctly. The buffer move currently 
always happens every "buffer size" bytes. And that's certainly not 
When there is a watermark, ie. at byte 2020, StartMessage()/
EndMessage() would flush the buffer at that point in order to save the 
moving. It may still have to do this at some point, but very rarely. 
Also, a big buffer size is ignored for this, too, and thus solving the 
problem you mentioned.

> > d) the response of the server (SERVER=5FTRUE/SERVER=5FFALSE) is not 
> > significant enough.
>       It's not a big deal. The response can be found in message's body.
>       But... do whatever you want.

SERVER=5FTRUE/FALSE just doesn't make much sense. If you're not annoyed 
by it, fine, but I  certainly am :-)

> > 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=5Fserver a lot more robust.
>       Well... if you think so, do it. I, for one, beside the problem
> with regions I exposed find BPortLink to be quite simple and 
> reliable.
> Remember, R5 has an even more simpler version and yet I heard nobody
> complaining about it's stability.

Don't worry, it won't be a big change.

> >>5) should we group mouse=5Fmoved messages that come from 
> > > input=5Fserver=3F
> >>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.
>       Yet it is, because Read<>() is a blocking call.

And=3F Who says it needs to do that=3F It even has a timeout, and we would 
just need to use it.

> > But the one evaluating 
> > mouse messages shouldn't do any window moving anyway.
>       But they do. Mouse messages arrive in a RootLayer's port which is
> responsible for moving windows also.

I know that they do now, it's just wrong to do so. Moving a window (ie. 
update it on screen) can take a long time, and there is no way to stop 
all other message processing during that time.


Other related posts: