Martin Peylo wrote: 

> Since - anyone please correct me if I'm wrong - there could 
> be "Direct Addressed Messages" which have *no* port name set, 
  [snip!]
> Could anyone clarify for what reason "Directed Addressed Messages"
> could occure, I acctually never traced them.

TIPC's data messages (user values 0 through 3, representing "low
priority" through "critical priority" application data) come in four
flavours.

The "named" and "mcast" message types have info in the TIPC header to
specify the message's destination (a port name and port name sequence,
respectively); these message types typically occur when an application
sends connectionless traffic.  The "conn" type is used to carry
connection-oriented traffic over an already established connection;
since the sending socket/port already knows the port ID of the other end
of the connection, there is no need for any port name information to be
present in the TIPC header.

The "direct" type is used to carry connectionless traffic to a
destination that was specified using a port ID, rather than a port name;
again, no port name info is present in the TIPC header because it is not
required.  Situations where this sort of message might be generated
include: a) an application obtains a port ID as part of a subscription
event generated by TIPC's topology server and then sends a message to
that port ID (using sendto() or sendmsg()), and b) a server obtains a
client's port ID when it receives a message from the client (using
recvfrom() or recvmsg()) and then sends a reply back to that client port
ID (using sendto() or sendmsg()).

***

More information on the various fields of the TIPC header can be found
in the TIPC Message Format Reference document (see
http://tipc.sourceforge.net/documentation.html).

A number of changes were made to the header formats were made during the
development of TIPC 1.7, and I'm not sure if the current Wireshark
dissector for TIPC has been updated to reflect this.  Most of the
changes were relatively minor, so the existing dissector should still be
OK for most purposes, but it would be nice to get things brought
completely up to date.  Martin, can you comment on the current state of
things?

Regards,
Al

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
tipc-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tipc-discussion

Reply via email to