[tipc-discussion] Should we obsolete the short message header in TIPC 2.0?

[Stephens, A. <all...@wi...>]

Hi Jon:

In my continuing efforts to simplify things in TIPC 2.0 I was wondering if it would make sense to obsolete the use of the 24 byte message header for connection-based payload messages, and have TIPC 2.0 always use the 32 byte header form (as it does for connectionless payload messages that don't use naming).

My main objection to the status quo is that it's inconsistent for TIPC to use two different header formats for the connection-based and unnamed connectionless payload messages. Why should the connectionless payload message always have to specify an originating and destination node while the connection-based message only does so for inter-cluster connections? It seems more logical to insist that either: a) those fields be supplied in all cases, or b) those fields should only be supplied for inter-cluster traffic. Since approach a) would probably cause fewer backwards compatibility issues, and would likely simplify coding a bit, that's probably the way we should go.

I should also point out that TIPC is currently also inconsistent in its use of the short header form since there are a few places in which intra-cluster connection-based payload messages get sent out with the 32 byte header, such as when a short form message is rejected because it is undeliverable and when TIPC sends out a FIN message to abort an established connection. Once again, standardizing TIPC 2.0 to use the 32 byte header seems like the right way to address this inconsistency.

Of course, obsoleting the 24 byte message header in TIPC 2.0 doesn't mean that TIPC 2.0 wouldn't be able to handle incoming messages using this form - just that it wouldn't send any. We'll obviously need to continue supporting the short header form so that TIPC 2.0 can interoperate with existing

Your thoughts?

Regards,
Al