Enrolment behind a seam, with both transports
The last of the host's link that still named a transport. `Asking` is one enrolment conversation — a connection made with the token, a question asked, and an answer waited for — and it is its own seam rather than part of `Link` because almost nothing about it is the same: the credential is a one-time secret, there is no declaration to hear, and a node that fails here is not in the mesh at all, where a node that fails in `Link` has merely lost touch with one it belongs to. `Enrol`'s thirteen arguments became an `Approach` — where, which certificate, which bus — and the request it already had. The token says nothing about which bus, and does not need to: every token names the one the mesh runs on today until the rollout. **The reply address is the whole of what changes on the new bus**, and it is forced rather than preferred. Verified against a running server, both halves: the answer reaches the node at the address its request carried in the payload, and the transport's own reply field held something else entirely by the time the consumer saw it — the consumer's ack address, exactly as design 25 §2 says. The test asserts the field is *not* the node's inbox, so a future server that stopped claiming it would fail this rather than let the reason quietly become folklore. The inbox is under `_INBOX.enrol.<node>.`, which is exactly what the enrolling user may subscribe and no wider, with a random tail per attempt: a reply left over from an attempt that timed out is not the answer to this question, which is what the correlation id does on the other transport. Subscribed before anything is published, because a node that published first could miss an answer to a question nobody was listening for.
This commit is contained in:
@@ -28,6 +28,11 @@ import (
|
||||
// answer to novox/hq issue 107. What the drain in run.go still answers is the live case: three
|
||||
// pushes to a *connected* node are three deliveries whatever the stream later retains.
|
||||
|
||||
// EnrolSubject is where a joining machine asks. One subject for every node, because a machine
|
||||
// enrolling has no name the mesh has agreed to yet — which is why its authority to publish here is
|
||||
// the whole of what its enrolment user may do.
|
||||
const EnrolSubject = "mesh.control.enrol"
|
||||
|
||||
// DeclareSubject is where this node's declaration lands. Its own, and no other node's: a host's
|
||||
// account subscribes exactly this and the subject is the authority on which node a declaration is
|
||||
// for.
|
||||
|
||||
Reference in New Issue
Block a user