Daemon

Tag 1: the server announces a daemon connection a program in the container opened, under a connection id it minted; the client answers with everything the daemon says on it, one server frame per channel response, and its channel response finish closes the connection.

The server opens this channel when a program in the container dials the proxy’s /daemon. It is the server’s half of the connection; the client’s half is a daemon channel the client opens, quoting the same id.

• The request. The tag byte 1 followed by a connection id, four bytes, that the server minted. Request states its form.
• The response. What the daemon says, as channel responses, each one server frame, and the channel response finish, which closes the program’s socket. Response states the sequence.
• The id. The server chooses the id and keeps it unique among the daemon connections it has announced and the client has not finished. The proxy does not reuse an id while either half of its connection is open. Daemon connections and database connections number independently: an id of one never names the other.
• Before the other half. The server reads nothing from the program until the client has opened its half. The daemon protocol is client-first, so nothing is expected on this channel before then; what arrives all the same is held, and written to the program first, in order.
• The account. The daemon serves the connection for the account the container was created under. No credential passes on either half.
• The conduit. The server writes each channel response to the program’s socket as one message, in order, and does not read it; the channel response finish closes the socket.