-
Notifications
You must be signed in to change notification settings - Fork 276
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
Stable sort for HashSet #256
Comments
@streetycat I conducted a data comparison test after encoding and decoding the Vec/HashMap/HashSet/BTreeMap/BTreeSet data structure in NameObject desc/body, and found the following problems.
test source code Details Logs
|
I reviewed your test case, there are some errors:
or
and decode them as follow:
The traversal order of HashMap/HashSet is unstable, it's the feature of HashMap and HashSet. This feature will result in different binary results encoded each time, so the Therefore, we need to sort it in a fixed order. It will only affect binary results, the usage and features of the object will be same as itself. For example:
|
@streetycat This problem is because I use protobuf to implement NameObject, but what you optimize is caused by the codec sorting problem in raw form. CYFS official recommendation for DEC APP development is to implement Object in the form of protobuf. This form does not seem to be well compatible with data in HashSet/HashMap format. Developers can be forced to use BTreeMap/BTreeSet data in official documents. |
Protobuf is recommended for its good scalability. But it is independent of the specific field type, and the type of each field is immutable. Actually, for In
But the As I mentioned earlier, we can add or remove field in the
So how to encode each fields is not important. Therefore, we can also encode each fields as a buffer, and combine all fields into
And, we can encode the container field to a binary buffer:
|
Discussed in #253
Originally posted by streetycat May 6, 2023
I am reviewing the encoding format for types. But I find that our encoding process only explicitly sorts the HashMap. Other types(as HashSet/BTreeMap/BTreeSet) depends on the iter in
Rust
. I have read the documents for those types, The iters for BTreeMap and BTreeSet return elements in ascending order. but I have not found how it is sorted in HashSet.I am reading the code in raw_types.rs.
I think we have to explicitly define the encoding order of the fields/elements of the composite type, otherwise different results may be encoded.
The text was updated successfully, but these errors were encountered: