I can easily make it happen with known service addresses too. We have shortlived processes that does a query:
Open 226 1 Send query to 226 2. 226 2 sends response back to 226 1. - Message gets dropped. And again, from kernels 2.6.32 (Tipc 1.7.4) to Kernel 4.15, this never failed. Now I can make it fail every 2-5 queries. Adding a call to the topology server to query to see if a socket you _know_ is open (because you just got a message from it) to send a message back is adding a lot of unnecessary overhead. From: Tung Quang Nguyen <tung.q.ngu...@dektech.com.au> Sent: Thursday, June 22, 2023 4:39 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. > 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. No, receiving of user data messages does not update the naming table. It is done via the protocol's internal published messages. > 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. The same thing for TIPC if you send back your messages using known service. _______________________________________________ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
