> 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.
You can always send the message back if communication is being performed on the
known service (in your example: type 226, instance 2). If you send a message
back using new service (type 226, instance addr) which is not known yet by the
sender, of course TIPC will drop this message.
> We have a workaround right now by querying the topologyserver before each
> send, but that slows down everthing by several orders of magnitude.
This is the right thing to do.
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
