Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Sim2h WireMessage Receipts #2120
This intends to make the channel between nodes and the Sim2h server resilient against data/connection loss on the level of Lib3hMessages. (in the direction: Sim2hWorker -> Sim2h server)
This resilience is actually an assumption that code in core holds, but that wasn't met by the Sim2h/Sim2hWorker implementation yet. A connection dropped just after a message was sent would leave the disconnected node without track of that lost message. It would continue to function after a reconnect, but the message sent before would be lost, if it wasn't received by the server before the disconnect.
With this PR we add a receipt message type
( if any manual testing or benchmarking was/should be done, add notes and/or screenshots here )
- summary of change [PR#1234](https://github.com/holochain/holochain-rust/pull/1234)
See for getting u8 to work: https://github.com/holochain/holochain-rust/compare/low-level-receipts
Similarly - if you want the hashing to be consistent, I believe the problem lies in the level at which you are hashing.
On the worker side, if you hash the already serialized binary data (optimally changing the outgoing queue to have already serialized data and respective hashes), then on the server side, do the hashing before deserializing the data, then obviously they should match.
As we just found out, the serialization of WireMessages is not deterministic because of a hidden HashMap. The code fixed here assumed `message.into::<String/Opaque>()` to always return the same result since it's doing it once for the payload sent, and once for the calculation of the signature. The result would be (and almost certainly was) wrong signatures which make Sim2h server ignore the message.
zippy left a comment
This seems to break the sim2h-client command from the cli: