Hi Martin: Comments inline; unless otherwise noted your changes/observations are correct. Let me know if you have any more questions.
Thanks for your continued work in this area! -- Al > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Martin Peylo > Sent: Wednesday, October 10, 2007 8:30 AM > To: [email protected] > Subject: Re: [tipc-discussion] Subdissectors for Wireshark Plug-in > > Hi Al, > > thank you for the traces. > > I tried to identify the canges between 1.6 (as it is in the > Wireshark dissector right now or/and in the "TIPC 1.5/1.6 Protocol > Specification") and 1.7 (as it is in the "TIPC Message Format > Reference" or/and in the traces). I have to admit, that I > didn't check the TIPC source for that. Could you please give > me some comments when there is a questionmark, when it's > incomplete or just wrong? It could be, that there are things > mentioned that didn't change when I got them wrong before. > > In case fields were added, I'm going to dissect them in the future. > I'm not going to remove fields, if they had a meaning *and* > were evaluated before. > > DATA MESSAGE > - "Options Position" was removed, this also means that there > are no options added anymore > > BCAST_PROTOCOL > - "originating node" and "destination node" are now set > - "network id" is introduced > > MSG_BUNDLER > - "message type" is now set > - "broadcast ack no", "link level ack no" and "link level seq > no" are now set > - "originating node" and "destination node" are now set > > LINK_PROTOCOL > - "originating node" and "destination node" are now set > - "timestamp" is introduced although not used right now > > CONN_MANAGER > - sequence number is obsolete and can be disabled since it > was never really used > - there is a 9th word added to the header, which holds "msg count". > This field was only in the internal msg header for > MSG_BUNDLER and CHANGEOVER_PROTOCOL before. What's the use of > this field in here? Minor clarification: the "msg count" field is actually at offset 9, making it the 10th word in the header. When used in a CONN_MANAGER message, a non-zero value indicates how many additional messages have been received by a connection endpoint since the last acknowledgement. (i.e. In the normal case where sockets are being used, this means how many additional messages have been received from the receiving socket's receive queue as a result of a recv() or recvmsg() call.) The sending socket/port uses this info to implement TIPC's port congestion mechanism, which provides back-pressure on the sender if it is sending messages faster than the receiver can consume them. > ROUTE_DISTRIBUTOR > - this changed heavily > - now words 5, 6 and 7 are set and "item size" was added. > - does the "standard route item" replace the old "Figure 32: > External Routing Table message format" for the message types > 0,1 and 2? Yes. Also note, since this isn't specified in the reference guide, that: "scope" is the normal TIPC scope indicator: - 1 (TIPC_ZONE_SCOPE) - 2 (TIPC_CLUSTER_SCOPE) - 3 (TIPC_NODE_SCOPE) "dist" is a bit mask indicating to whom the receiver should re-distribute the message info to: - 0x01 (TIPC_DIST_TO_CLUSTER): distribute over all intra-cluster links - 0x02 (TIPC_DIST_TO_ZONE): distribute over all inter-cluster links - 0x04 (TIPC_DIST_TO_NETWORK): distribute over all inter-zone links In some cases, more than one bit can be set; it is also valid for no bits to be set. > Did msg types 3 and 4 stay as they were (just the > added/removed "Node Address" > in word 10)? No. There are now only 3 message types for route distribution: - 0 (DIST_PUBLISH): the associated route(s) are being published - 1 (DIST_WITHDRAW): the associated route(s) are being withdrawn normally - 2 (DIST_PURGE): the associate route is being withdrawn abnormally > - same question about "item size" as in NAME_DISTRIBUTOR. > > CHANGEOVER_PROTOCOL > - "redundant link" is not used anymore Yes. This field is only used in LINK_PROTOCOL messages. > - "originating node" and "destination node" are now set > NAME_DISTRIBUTOR > - "transport level sequence number" is not used any more > - "item size" came up to determine the size of the publication. > If this would e.g. be set to 2 there would only be "name > type" and "name instance" in the publication - or is this > always 7 now and might be different in future versions? Currently, the only valid values of "item size" are: - 7: this indicates that 7 word TIPC 1.7 name items are specified - 5: this indicates that 5 word pre-TIPC 1.7 name items are specified (see comment on "port id node" below) - 0: this also indicates that 5 word pre-TIPC 1.7 name items are specified (only pre-TIPC 1.7 nodes use this value) All other values less than 7 (i.e. 1, 2, 3, 4, and 6) are invalid. Values larger than 7 are OK, but TIPC 1.7 will simply ignore the extra information in each item; this was done so that additional optional info could be added to TIPC's name info in the future without causing major interoperability issues. > - what is the exact meaning of "port id node", "scope" and > "dist", which were added? "Port id node", together with "port id reference", indicate the port id (i.e. the <Z.C.N:ref> value) of the TIPC port that published the specified name. Prior to TIPC 1.7, there was no need to explicitly specify the <Z.C.N> part of the port id since it was always the same as the "originating node" field in the message header; however, since TIPC now supports multi-cluster networks, name publication messages may be relayed to the receiver by one or more intermediate nodes, so the original publisher can no longer be inferred this way. The "scope" and "dist" fields are described in the ROUTE_DISTRIBUTOR section above. > MSG_FRAGMENTER > - "originating node" and "destination node" are now set > > LINK_CONFIGURATION > - "media id" was added in word 5 and "media address area" is > a 4 word version of "bearer level originating address" Yes. However, this new format results in exactly the same info being present in w5 through w9 as was present in pre-TIPC 1.7 versions of this message. The redefinition of the fields will hopefully simplify things if and when Linux TIPC supports other media types than Ethernet; VxWorks TIPC already takes advantage of this with its shared memory media support. > Hope I overlooked only few things, > Martin ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
