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.