From: Tuong Lien <tuong.t.l...@dektech.com.au>
Date: Thu, 21 Nov 2019 15:34:58 +0700
> It is observed that TIPC service binding order will not be kept in the
> publication event report to user if the service is subscribed after the
> bindings.
>
> For example, services are bound by application in the following order:
>
> Server: bound port A to {18888,66,66} scope 2
> Server: bound port A to {18888,33,33} scope 2
>
> Now, if a client subscribes to the service range (e.g. {18888, 0-100}),
> it will get the 'TIPC_PUBLISHED' events in that binding order only when
> the subscription is started before the bindings.
> Otherwise, if started after the bindings, the events will arrive in the
> opposite order:
>
> Client: received event for published {18888,33,33}
> Client: received event for published {18888,66,66}
>
> For the latter case, it is clear that the bindings have existed in the
> name table already, so when reported, the events' order will follow the
> order of the rbtree binding nodes (- a node with lesser 'lower'/'upper'
> range value will be first).
>
> This is correct as we provide the tracking on a specific service status
> (available or not), not the relationship between multiple services.
> However, some users expect to see the same order of arriving events
> irrespective of when the subscription is issued. This turns out to be
> easy to fix. We now add functionality to ensure that publication events
> always are issued in the same temporal order as the corresponding
> bindings were performed.
>
> v2: replace the unnecessary macro - 'publication_after()' with inline
> function.
> v3: reuse 'time_after32()' instead of reinventing the same exact code.
>
> Acked-by: Jon Maloy <jon.ma...@ericsson.com>
> Signed-off-by: Tuong Lien <tuong.t.l...@dektech.com.au>
Applied, thanks.
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
