Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request for Message Status Information #44

Open
aykutalparslan opened this issue Mar 1, 2022 · 0 comments
Open

Request for Message Status Information #44

aykutalparslan opened this issue Mar 1, 2022 · 0 comments

Comments

@aykutalparslan
Copy link
Owner

aykutalparslan commented Mar 1, 2022

If either party has not received information on the status of its outgoing messages for a while, it may explicitly request it from the other party:

msgs_state_req#da69fb52 msg_ids:Vector long = MsgsStateReq;

Max 8192 IDs are allowed per constructor.

The response to the query contains the following information:

Informational Message regarding Status of Messages

msgs_state_info#04deb57d req_msg_id:long info:string = MsgsStateInfo;

Here, info is a string that contains exactly one byte of message status for each message from the incoming msg_ids list:

  • 1 = nothing is known about the message (msg_id too low, the other party may have forgotten it)
  • 2 = message not received (msg_id falls within the range of stored identifiers; however, the other party has certainly not received a message like that)
  • 3 = message not received (msg_id too high; however, the other party has certainly not received it yet)
  • 4 = message received (note that this response is also at the same time a receipt acknowledgment)
  • +8 = message already acknowledged
  • +16 = message not requiring acknowledgment
  • +32 = RPC query contained in message being processed or processing already complete
  • +64 = content-related response to message already generated
  • +128 = other party knows for a fact that message is already received

This response does not require an acknowledgment. It is an acknowledgment of the relevant msgs_state_req, in and of itself.

Note that if it turns out suddenly that the other party is missing a message that appears to have been sent to it, the message must not be re-sent on its own with the same msg_id. Instead, it can be either wrapped in a container, or the status of the message can be checked using msgs_state_req and if the message wasn't received, then it must be re-sent with a new msg_id.

@aykutalparslan aykutalparslan added this to the 6. Service Messages and Low Level API milestone Mar 1, 2022
@aykutalparslan aykutalparslan removed this from the 06. Service Messages and Low Level API milestone Oct 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant