[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.

Other related posts: