Usage of NormObjectId transport_id in NormObjects

[protohuf]

I'm writing an application where I have one sender and multiple receivers. In this scenario the server nodeId for a session is always set to 1 on application startup.

I found that if the sender sends X items (NormDataEnqueue in this case) and is restarted (application exits and restarts), the receivers won't pick up the senders first new X items sent. Only after X items has been sent by the sender (and ignored by the receivers) will the receivers start generating NORM_RX_OBJECT_* events again. I did some light digging and found that for each enqueued item by the sender, a transport_id is incremented.

Is it true that receivers will keep track of the last sent transport_id associated with an object and ignore any transport_id which is less than what has already been received from a senders' nodeId? If so, how do you propose to handle situations in which the sender application is restarted and thus transport_id is reset?

[bebopagogo]

The sender Norm instance id (aka session id in some of the documentation) can be used to discriminate when a sender has restarted so the receiver will treat the sender as “new”. In the examples I use a random instance/session id for this, but one could implement a more deterministic approach (using non volatile storage) to guarantee session is uniqueness. That’s the preferred approach. I have thought about providing a means for senders to cache their entire state to nonvolatile storage and reconstitute it upon restart for long-lived applications that require that sort of fault tolerance or persistence, but some considerable work required to implement that

…

Sent from my iPhone

On Apr 30, 2021, at 9:54 AM, protohuf ***@***.***> wrote:  I'm writing an application where I have one sender and multiple receivers. In this scenario the server nodeId for a session is always set to 1 on application startup. I found that if the sender sends X items (NormDataEnqueue in this case) and is restarted (application exits and restarts), the receivers won't pick up the senders first new X items sent. Only after X items has been sent by the sender (and ignored by the receivers) will the receivers start generating NORM_RX_OBJECT_* events again. I did some light digging and found that for each enqueued item by the sender, a transport_id is incremented. Is it true that receivers will keep track of the last sent transport_id associated with and object and ignore any transport_id which is less than what has already been received from a senders' nodeId? If so, how do you propose to handle situations in which the sender application is restarted? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[protohuf]

Just to clarify, when you write "instance/session id" you are really referring to the NormNodeId (last parameter in the NormCreateSession function call)?

[bebopagogo]

No - it’s a parameter of NormStartSender()

…

Sent from my iPhone

On Apr 30, 2021, at 10:26 AM, protohuf ***@***.***> wrote:  Just to clarify, when you write "instance/session id" you are really referring to the NormNodeId (last parameter in the NormCreateSession function call)? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[protohuf]

Ah, right now I get it. This seems to work. Thanks