-
Notifications
You must be signed in to change notification settings - Fork 2
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
Mixnet: Packet delay in mix node #49
Conversation
787d63c
to
6a849c4
Compare
def start( | ||
self, | ||
delay_rate_per_min: int, | ||
inbound_socket: PacketQueue, | ||
outbound_socket: PacketPayloadQueue, | ||
) -> MixNodeRunner: | ||
thread = MixNodeRunner( | ||
self.encryption_private_key, | ||
delay_rate_per_min, | ||
inbound_socket, | ||
outbound_socket, | ||
) | ||
thread.daemon = True | ||
thread.start() | ||
return thread |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick: could this be async instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we can use async, but I'm thinking if it would be not readable for someone who is not familar with async programming.
Also in previous PRs I remember to see some async code, we should choose one style
I haven't used async code in this repo. But, let me translate this into async. If it doesn't look complicated, we can go with async because it's much easier to approximate M/M/∞ queue using async rather than sync.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't used async code in this repo. But, hm, let me translate this into async. If it doesn't look complicated, we can go with async because it's much easier to approximate M/M/∞ queue using async rather than sync.
It is not necessary!, we can go ahead with this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think in general is ok. I would change the use of threads by async code instead. Also in previous PRs I remember to see some async code, we should choose one style. But it is up to you.
This PR covers the specification of packet delay in mix nodes: https://www.notion.so/Mixnet-Specification-807b624444a54a4b88afa1cc80e100c2?pvs=4#15ccbb03a44f42658ea67a33527ecea2.
In summary,$\lambda$ , the mix node should be implementation to approximate a M/M/∞ queue with packet delays that follow an exponential distribution $\mu$ . With this setup, the packet emission rate of a mix node must be $\lambda$ , and the mean number of packets being processed by a mix node at any time must be $\lambda/\mu$ .
assuming that the packet receiving rate of a mix node follows a Poisson distribution
A unit test checks these properties.