On 2023-06-22 09:30, Rune Torgersen wrote:
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.
It is obviously a timing issue, - an unintended side effect of moving
the name table updates over to using the multicast channel.
Is there any reason why you don't use the received messages original
socket address instead of its service address?
If you do that, at least for the first response message, you should be good.
I think there was also added a command to force the name table updates
back to the unicast channel, but I don't remember
from the top of my head how it was done. Maybe Tung can fill in here?
///jon
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
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
