-
Notifications
You must be signed in to change notification settings - Fork 8
Description
Throughout the codebase, there are various places where, regrettably, timeouts are required for normal operation. For instance, re-sending a retrieval request when the desired Memo has not arrived, or deciding to give up and report failure on some operation.
Such delays look something like this:
Delay::new(Duration::from_millis(1000)).await;
This delay mechanism is sufficient for normal operational conditions, but it's a problem for the Simulator. Such timeouts induce nondeterminism, and will become highly distorted in a simulated environment where virtual time may be running significantly faster or slower than physical time – whatever the heck that is ;)
As such, it will be necessary to implement a delay mechanism which is able to operate as-is under real-world conditions, and under virtual time when using the Simulator.
I propose that we proceed as follows:
- Update the
Networkstruct to keep track of whether it's in simulated mode or not (and probably to forbid all other transports when operating in Simulated mode) - implement something like
network.delay(u64)in order to perform the switching between simulated delays and real delays, as appropriate. - rename/change
struct MemoPayloadto something likeenum NetworkSimEvent{ Delay, MemoPayload }such that MemoPayloads and Delays are "delivered" by the simulator on equal terms, with each clock unit of the simulator translating to 1 millisecond.
NOTE: At the time of this writing, there exist other nondeterminism problems which are currently being patched with similar delay statements, but they are typically commented with // HACK. This case does not refer to such usages. With that said, it may be interesting to think about the possibility of replacing those with deterministic virtual Delays as well, as that could help to work around #18