Imported from previous forum
[ original email was from Michael Whealy - michael.whealy@asx.com.au ]
If a client sends a snapshot + updates, followed by a disable snapshot + updates before the snapshot is received, does the disable only disable updates or both the snapshot plus updates (ie should the client receive a snapshot)?
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> If a client sends a snapshot + updates, followed by a disable snapshot + updates before the snapshot is received, does the disable only disable updates or both the snapshot plus updates (ie should the client receive a snapshot)?
This hasn’t ever been defined.
If a client disables a snapshot + updates before receiving data from the original request, I don’t believe the client should have any expectations as to whether no data, part of the snapshot, the full snapshot, or the full snapshot + some updates would be sent back.
This situation is, at its core, a race condition. You cannot guarantee when the server will receive and process the event; as such I don’t believe the client can make expectations about the outcome.
[ original email was from Michael Whealy - michael.whealy@asx.com.au ]
> > If a client sends a snapshot + updates, followed by a disable snapshot + updates before the snapshot is received, does the disable only disable updates or both the snapshot plus updates (ie should the client receive a snapshot)?
>
> This hasn’t ever been defined.
>
> If a client disables a snapshot + updates before receiving data from the original request, I don’t believe the client should have any expectations as to whether no data, part of the snapshot, the full snapshot, or the full snapshot + some updates would be sent back.
>
> This situation is, at its core, a race condition. You cannot guarantee when the server will receive and process the event; as such I don’t believe the client can make expectations about the outcome.
>
>
That is one of two interpretations that I can see (which is the one I am leaning towards). The other interpretation would be that a snapshot + updates is a request for a snapshot, plus a subscription for updates. Therefore a snapshot should always be sent, regardless of when the disable is processed. I am just wondering which interpretation is correct.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> That is one of two interpretations that I can see (which is the one I am leaning towards). The other interpretation would be that a snapshot + updates is a request for a snapshot, plus a subscription for updates. Therefore a snapshot should always be sent, regardless of when the disable is processed. I am just wondering which interpretation is correct.
I believe that both implementations should be allowable.
If a server receives a cancel while processing a Snapshot + Updates, that server, in my opinion, should be within its rights either to stop sending immediately, or to conclude the snapshot and then stop sending. I do not think it prudent for a client to rapid-fire a request for Snapshot + Updates, then cancel the request, and be able to make any assumptions about data completeness. If the client wants a complete Snapshot, the client should ask for a complete Snapshot, not a Snapshot + Updates.