[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.
[checksum]
> 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
necessary.
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.
Bye,
Axel.
Other related posts:
