Re: [tipc-discussion] Reg: Need information about TIPC_MCAST subscriber socket

[prakash b. <ps1...@gm...>]

Thank you Jon for your response. In some cases, we might be hitting a
race-condition during the small window that you have mentioned.

To give you more context about our use case which is little different than
you have mentioned in your solution. We have one publisher and many
subscribers.
Typically the publisher is created first and the subscribers may come later
at any time.
The subscriber application needs to pull already published data from the
publisher application.

Currently the subscriber application is doing the pull just after the
bind() system call through a different channel( not pub/sub).
But if some data is published after the pull and before the subscriber
socket becomes ready, then that data will never reach the subscriber
application.

Is there any way to know if the subscriber socket is fully ready inside the
subscriber application ?
Or
If the subscriber application waits for a few milliseconds ( e.g.100ms )
after bind() system call() and  before the pull, would it be a
practical approach to avoid this race condition ?

Kindly note that we are using tipc pub/sub sockets with scope as
"TIPC_NODE_SCOPE" so the window we are talking about here should be
relatively very small.

Thanks and Regards,
Prakash


On Tue, Sep 17, 2024 at 1:01 AM Jon Maloy <jm...@re...> wrote:

>
>
> On 2024-09-16 07:58, prakash bisht wrote:
> > Hi Hi Tung,Xin,John,
> >
> > We are using tipc multicast sockets for publisher/subscriber type of
> > application.
> > Below are the socket details
> > socket type     :  SOCK_RDM
> > tipc addr type  :  TIPC_MCAST
> >
> > We would like to know if the successful bind() call on the subscriber
> > socket guarantees that the subscriber is ready and no publication
> > would be missed ? Or shall we wait for some time before assuming the
> > subscriber socket is ready ?
> There may be (very) a small lag between the return of the bind() call
> until the bind is registered on all the other nodes.
> The proper way to get around this is to let your "publishers" use the
> TIPC subscription mechanism to keep track of your
> "subscriber", i.e., they don´t start publishing until they have received
> a notification that the subscriber is bound
> to the service address/range.
> ///jon
> >
> >
> > Thanks and Regards,
> > Prakash
>
>