It's becoming clear that the document needs a section on EventIds.
EventIds aren't opaque to the server. They are comparable objects and are used by the cache to prevent replay of older (operation eventId < recorded eventId) operations on the cache and on subscription queues. They are also used to prevent sending operations originating from a client back to that client in its subscription queue.
A thread's sequenceId should be incremented for each operation sent to the server.
In my opinion EventIds are optional for clients and only need to be implemented if clients are going to retry operations. If a client doesn't send an EventId to the server one will be generated on the server for the operation.
Le 5/4/2017 à 8:46 AM, Jacob Barrett a écrit :
The eventId is really just a once token right? Meaning that its rather opaque to the server and intended to keep the server from replaying a request that the client may have retried that was actually successful. If it is opaque to the server then why encode all these specific identifiers? Seems to me it could be optional for one and could simply be a variant int or byte[]. The server just needs to stash the once tokens and make sure it doesn't get a duplicate on this client stream.
