Also, since the publish and unicast is not guaranteed in order, should not
reception of a unicast data message before a publish update the publish table
on the receiving end so you can expect to reply back immediately.
Take UDP as the other datagram protocol. You are expected to be able to send
back a reply to the sending socket immediately upon reception of a message, as
by receiving it you know the farend is up.
-----Original Message-----
From: Rune Torgersen <ru...@innovsys.com>
Sent: Wednesday, June 21, 2023 8:18 AM
To: Tung Quang Nguyen <tung.q.ngu...@dektech.com.au>;
tipc-discussion@lists.sourceforge.net
Subject: Re: [tipc-discussion] TIPC out-of-order publish message
This email originated from outside Innovative Systems. Do not click links or
open attachments unless you recognize the sender and know the content is safe.
Example is a extremely paired down version of the problem.
What it means in reality for us, is that if we send a message from a newly
opened tipc socket to a different node, we cannot send back a reply
immediately, as the tipc stack will silently throw away the message because the
publish has not yet been received.
Problem is, this is in use in applications we've been selling for years
(originally released under ubuntu 16, and has always worked correctly until
now. We've used TIPC back to 2.6 kernels, and never had this issue before.
It is basically not feasible to rewire it all. We have a workaround right now
by querying the topologyserver before each send, but that slows down everthing
by several orders of magnitude.
From: Tung Quang Nguyen <tung.q.ngu...@dektech.com.au>
Sent: Wednesday, June 21, 2023 1:41 AM
To: Rune Torgersen <ru...@innovsys.com>; tipc-discussion@lists.sourceforge.net
Subject: Re: TIPC out-of-order publish message
This email originated from outside Innovative Systems. Do not click links or
open attachments unless you recognize the sender and know the content is safe.
> if (-1 == bind(sock, (struct sockaddr*)&listen_addr, sizeof(struct
> sockaddr_tipc)))
> perror("Error opening TIPC socket");
> *(int*)buf = addr;
> int rc = sendto(sock, buf, sendsize, 0, (struct sockaddr*)&to_addr,
> sizeof(to_addr));
You are not recommended to design your application this way.
Published messages are TIPC internal messages. There is no guarantee that they
and user data messages are sent/received in correct order. Especially, since
kernel 5.10, Published messages are sent on Broadcast link whereas user data
messages are sent on Unicast link.
These links have different send queues, sequence numbering engines etc. So,
what you showed in TCP dump is an expected behavior.
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
