-
Notifications
You must be signed in to change notification settings - Fork 8
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
[Documentation] Please elaborate on optional reliability and order #9
Comments
Hello @pachanga. Yes, reliable packets can be received out of order. Library controls ordering only for fragments of messages (messages that are too big to be sent in one datagram). Fragments reassembled in the correct order. Some basic ordering implemented via ReceivedSmartPacket structure. There are boolean InOrder flag. But it is meaningful only for non-fragmented messages. |
Thanks for clarifications!
Please correct if I'm wrong, does it mean - if the packet was: a) was sent reliably b) but fragmented c) and was received out of order - InOrder flag wouldn't reflect this? |
Order is a tricky question if packet was truncated, there are a lot of cases when we can't say it for sure. For example we send fragmented packet 1 (datagrams 1 and 2) and packet 2 (datagram 3 and 4), but received them in that order: (1-3-2-4). Was that in-order or not? |
Yep, that's tricky. I guess it doesn't make sense to analyze InOrder flag because it's kinda too low level information. I'll just rather introduce my own logical sequence numbers for snapshots which would allow me to understand where the received packet should be placed. |
Hi!
In the Features section of the README the library is said to have "Optional reliable" and "Optional ordered" features. Could you please elaborate a bit more on these features?
Looking at the API it seems that the Send method has only "reliable" flag. Does it mean that "reliable" packets still can be received out of order?
The text was updated successfully, but these errors were encountered: