This feature ensures that any pair of pet dæmons will only be connected by a single CapTP connection to ensure that identical remoteable objects round-trip between them. In this framework it is necessary to partially solve the problem of “crossed hellos”, such that two nodes that simultaneous start up and suddenly wish to be connected to each other will race to create the first connection. One of these daemons must drop an established connection and invalidate incarnations that depend upon it. We settle this question by biasing the behavior based on the relative values of their node identifiers.
This does not fully solve the experience of crossed hellos. If hellos get crossed, the loser of the race will get cancelled and may not gracefully recover. Evidence suggests this can manifest as data-lock where it would ideally result in an explicit cancellation exception. More work is necessary.
This does not solve the more general problem that three-party-hand-off would solve: a remoteable that takes a trip through a third party will not return as an identical object. This is necessary toward that end, but there will need to be shared state among all open CapTP sessions.
This also raises another problem not solved in this change: when the loser of the race to cross hellos abandons an incarnation, it should not merely delete the incarnation but should immediately reïncarnate the formula subgraph that depends upon it.
This feature ensures that any pair of pet dæmons will only be connected by a single CapTP connection to ensure that identical remoteable objects round-trip between them. In this framework it is necessary to partially solve the problem of “crossed hellos”, such that two nodes that simultaneous start up and suddenly wish to be connected to each other will race to create the first connection. One of these daemons must drop an established connection and invalidate incarnations that depend upon it. We settle this question by biasing the behavior based on the relative values of their node identifiers.
This does not fully solve the experience of crossed hellos. If hellos get crossed, the loser of the race will get cancelled and may not gracefully recover. Evidence suggests this can manifest as data-lock where it would ideally result in an explicit cancellation exception. More work is necessary.
This does not solve the more general problem that three-party-hand-off would solve: a remoteable that takes a trip through a third party will not return as an identical object. This is necessary toward that end, but there will need to be shared state among all open CapTP sessions.
This also raises another problem not solved in this change: when the loser of the race to cross hellos abandons an incarnation, it should not merely delete the incarnation but should immediately reïncarnate the formula subgraph that depends upon it.