[haiku-appserver] Re: communication
- From: "Stephan Assmus" <superstippi@xxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Tue, 07 Jun 2005 17:27:36 +0200 CEST
Hi,
Adi Oanca wrote on Tue, 07 Jun 2005 16:49:07 +0300:
> > 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?
Right where for example a NULL string was passed to AddString(). The
string was never added (the error was not checked), and the message was
only partial. On the server side, wrong data was read, because the
correct data was at a different offset.
DarkWyrm wrote on Tue, 07 Jun 2005 09:14:12 -0400 EDT:
> I've been mulling over how to fix PortLink properly, and there is
> another issue with PortLink as it is. There are occasions where a
> message protocol has been changed on one side and not the other, and
> the client or the server crashes, hangs, or starts using weird data.
I think BPortLink as a low overhead design is fine. Just think of all
the additional type info and field names going over the port. No, sub-
optimal.
We have fixed size messages and variable size messages. One way to
solve "client/server code out of sync problem" would be to have a file
similar to ServerProtocol.h with defined structs for most or even all
messages. A struct can be added to the port link in one operation, and
therefor error checking is much easier. It would be more efficient too,
since we would not have to check if we need more buffer size for each
and every single uint8 that is Attach()ed. Client and Server code don't
get out of sync because the struct is defined and usage is checked by
the compiler. Dynamically sized messages will probably fit into this
picture too.
Best regards,
-Stephan
- Follow-Ups:
- [haiku-appserver] Re: communication
- From: Adi Oanca
- 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: Adi Oanca
- [haiku-appserver] Re: communication
- From: Adi Oanca