You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ID in SubscribeMessageResponse is generated on the server side to ensure that each subscription has a unique identifier. This approach prevents clients from spoofing or forging IDs, enhancing security by reducing the potential for unauthorized access or manipulation. By associating the Topic with this unique ID in the response, clients can reliably match a SubscribeMessageRequest to its corresponding SubscribeMessageResponse.
Topic is indeed redundant and might not be included in a response. We're still discussing it
My concern is that associating subscribe requests to responses on the basis of Topic alone can be ambiguous if a client sends multiple consequetive SubscribeMessageRequest messages to the server with the same Topic.
Presumably this is a potential scenario when a user wants to subscribe to the same topic multiple times, but with different parameters.
It seems to me that either:
Some sort of identifier must be sent from the client to associate SubscribeMessageRequest and SubscribeMessageResponse messages.
Sorry for initially stating that this should correspond to the same ID as SubscribeMessageResponse was maybe a mistake on my part - this can be a totally different identifier.
OR The server must guarantee in-order delivery of SubscribeMessageResponse messages. In this case, I can just add pending subscriptions to a queue on the client-side & associate them with incoming responses in-order.
Maybe 2. is already a guarantee, and in this case this would not be an issue to worry about. But I just wanted to bring it up in the case that it isn't.
Should be discussed with FCL team due to comment: #6630 (comment)
The text was updated successfully, but these errors were encountered: