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
