[haiku-appserver] Re: communication
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Tue, 07 Jun 2005 19:01:43 +0200 CEST
Adi Oanca <adioanca@xxxxxxxxxxxxx> wrote:
> Axel D=F6rfler wrote:
> > [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=3D5Fserver, yes, but
> > that's not
> > a problem, as only malicious code would do that :-)
> Aren't you targeting malicious code with the checksum field=3F
Not really, rather wrong or bad code :-)
It's probably not really needed later on (with real security services),
and easily circumvented by current code, so maybe I should just drop it
for now.
> > Also, the app=3D5Fserver 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.
> I agree. But checking every parameter for validity would impose a
> huge
> performance penalty.
Not at all. Sending the stuff over the port is where the penalty is. A
"if (a < 0)" is certainly completely negligible in this context.
> >> 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.
> RootLayer will have a big message queue. I was thinking around 500
> or
> more, so I think we won't be having a port full problem especially
> because this will be a high priority thread.
It's not about a full port problem. It's about responsiveness. The
current design is just not taking that into account at all.
Bye,
Axel.
- Follow-Ups:
- [haiku-appserver] Re: communication
- From: Marc Flerackers
- References:
- [haiku-appserver] Re: communication
- From: Adi Oanca
Other related posts:
- » [haiku-appserver] communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- » [haiku-appserver] Re: communication
- [haiku-appserver] Re: communication
- From: Marc Flerackers
- [haiku-appserver] Re: communication
- From: Adi Oanca