[haiku-appserver] Re: communication
- From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Tue, 07 Jun 2005 19:36:31 +0300
Hi,
Stephan Assmus wrote:
> 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.
I don't think so. Make it as light as possible and the overhead is
negligible.
> We have fixed size messages and variable size messages.
<below>
> 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.
Sorry for the why I say this, but: NO!!
Backwards compatibility is _VERY_ hard to achieve! VERY hard.
Interoperability between 2 different versions involves a whole emulation
layer, duplicated structures... blah!
Believe me when I say this. Please! For almost a year and a half I had
this problem over and over. I'm tired of it!
Don't forget, we need this comm layer in a network with different Haiku
releases.
> 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.
I know it sounds nice, but in the end it's a total mess.
I wish you luck in your projects using this method, and I tell you:
don't forget about __attribute__((__packed__)) ! ;-)
bye,
Adi.
- References:
- [haiku-appserver] Re: communication
- From: Stephan Assmus
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: Stephan Assmus