I fixed it and checked in. But I am not entirely happy with the "symmetric"
tipc-config -p printout. I think it is useful information to know who is
originating and who is accepting a connection. The alternative is to set
a flag for this, or have separate fields => more memory usage. We can
probably live with this for a while.
Stephens, Allan wrote:
> Hi Jon:
> I've just picked up the latest changes you made to the unstable
> branch, and I noticed a couple of issues relating to the capturing of
> the destination name used to establish a connection in socket.c.
> 1) Modifying connect() so that the connection originator captures the
> destination name is fine by me, however it needs to be made
> conditional upon the use of a TIPC name as the destination address.
> In the event that the originator requests the connection using a TIPC
> port id (perhaps obtained via a subscription result) instead of a TIPC
> name, the port's conn_type and conn_instance fields must be left as zero.
> 2) The code you removed in accept() needs to be restored so that the
> non-originating side of the connection keeps a record of the
> destination name used to establish the connection, otherwise there is
> no way for a server to get this information via the TIPC_DESTNAME
> ancillary data mechanism.
> Unless you object, I'll clean up these oversights with my next
> submission to the unstable branch.
> I presume that one side-effect of having both sides of a connection
> record the destination name used during connection establishment is
> that it becomes more difficult to use the "tipc-config -p" command to
> identify which port originated the connection, since both ends will
> display the destination name. However, I'm not sure if this is really
> a significant issue since I don't see that there is any real
> difference between the two ends of the connection once it has been