-
Notifications
You must be signed in to change notification settings - Fork 34
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
send error:crowded to all sides when first discovered #19
Comments
This was referenced Mar 20, 2021
Open
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I observed a transter fail in the following way:
wormhole rx
, claimed nameplate N (by typingN <TAB> <TAB>
), then realized his mistake, and hit control-c to quitwormhole rx
andN-<TAB>
as usualThe server keeps track of how many sides are participating in a given mailbox. Alice's initial connection adds
sideA
. Bob's interruption addssideB
. Carol's connection addssideC
, at which point there are more than 2 sides, and the server throws a CrowdedError, which is returned to Carol (because it happened in response to herclaim
call, as she attempted to claim nameplate N).The problem is that Bob chose to disconnect before he sent any messages, and Carol was disconnected (with an error) before she had a chance to send any messages, so Alice is still waiting. Alice holds on to the nameplate until she sees evidence that her one expected counterparty has claimed the mailbox, and that evidence must be in the form of a message received from a side other than her own. Since neither Bob nor Carol sent any messges, Alice hangs on to the nameplate (and her client sits waiting) forever.
Note that it's legitmate for Alice to wait until Carol shows up. When Bob connected and then immediately disconnected, that doesn't rule out Bob as the real counterparty. His server-visible behavior is identical to what would happen if Bob's client had connected, started the protocol, and then the network dropped (maybe he's on a train, and his laptop was connected to the station WiFi, and the train pulled out of the station and he lost network access. Remember when we got to ride trains?). If he reconnects again later, still with the same
wormhole rx
client running (and thus using the samesideB
), then he could proceed with the protocol as planned. There would be no error in that case.It's not until Carol shows up that we know we're in trouble. Once we see three sides in the conversation, we cannot proceed correctly: PAKE is a two-party protocol.
The primary bug here is that Alice waits forever. I think the fix would be: if the server ever sends an
error:crowded
to one side, it should send it to all sides. That would cause Alice (whoseBoss
state machine ought to be in theLonely
state) to exit with the error.In addition, technically we might be able to tolerate this case. Bob claimed the nameplate and opened the mailbox, but didn't actually send any messages. We might defer adding
sideB
to the mailbox list until Bob actually did anadd
to add a message. Awormhole rx
client who<TAB>
s their way into a nameplate but doesn't hit<RETURN>
to finish entering the PAKE code will not send aphase:pake
message, so they haven't really interfered with the two-party conversation yet.So the tasks are:
broadcast_error
method toMailbox
Mailbox.open
to perform the three-sides check internally, and callself.broadcast_error(CrowdedError)
in that caseAppNamespace.open_mailbox
to remove the three-sides error check, in favor ofmailbox.open
doing itAppNamespace.claim_mailbox
tooMailbox.open
success flag far enough back out to letserver_websocket.py
'shandle_claim
to not returnclaimed
message if in fact the attempt caused an errorhandle_open
(looking more closely at the code, I see we track both
nameplate_sides
andmailbox_sides
, so maybe that plan isn't complete)And the bonus task is:
nameplate_sides
ormailbox_sides
tables, look at the messages in the mailbox, and only signal an error if there are actual messages from three or more sidesThe text was updated successfully, but these errors were encountered: