GRMrGecko/midi-harbor
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
midi-harbor/specs/018-remembered-machines/tasks.md
James Coleman be2e93bcda feat(network): follow a machine's session and forget removed ones 
- A network port kept a machine it had connected to after the connection was removed, listed it as on the network whenever its host advertised any session, and could not connect to it again: Connect resolved identifiers only among advertised sessions and failed with "no peer named". A machine remembered only for a connection is now dropped once no network port uses it, an untrusted machine is marked present only by a session at its exact address, and Connect resolves remembered machines by identifier or name.
- A network port invited the one address it had connected to until it answered, so a session that came back on another port was never reached. The session name advertised at a machine's address is now stored as advertised_as in the configuration, and while the link is down the port connects where that session is advertised and stores the new address. A machine carrying MIDI is never moved.
- Each daemon now holds an Ed25519 key in identity.key beside the configuration and publishes mhkey and mhport in every session's TXT record. Two packets on the control port, a challenge and a signed proof, let a network port prove which port of which daemon it is. A machine stored with a proved key and port_id is followed under any name and to another host, with its trust, and a port deleted and made again is not followed. The challenge is sent only to a session that advertises a key, so no other RTP-MIDI implementation receives it.
- A machine with no key is followed by name to a new port on its host, and to another host only when it is not trusted, since an advertisement proves nothing and trust is held by host.
- An invitation over an IPv6 link-local address was never answered, because the sender's address was kept without its scope. Apple's Network MIDI invites that way and reported that the port did not respond. The address is now kept whole for the control and data ports.
- Adds ed25519-dalek and hex. The packet fuzz target reads the new packets.
2026-10-02 11:56:20 -05:00

3.4 KiB
Raw Blame History

Tasks: Remembered Machines

Tasks by their numbers in the project-wide sequence, which continues across every spec. Each was built and checked in one piece, so they are not broken into phases.

  • T249 Forget a machine remembered only for a connection once no network port connects to it, list an untrusted record as on the network only when a session is advertised at its address, and connect to a remembered machine by its listed identifier, per FR-P01, FR-P02, FR-P03 (R-105) — done: drop_unused_peers runs when a network port disconnects, replaces its peer or is deleted; merge_known_peers matches a trusted machine by host and any other by address; resolve_peer looks among remembered machines after advertised ones. The machines test checks a disconnected machine leaves the configuration, a contract test connects by a listed identifier and finds a named machine kept after disconnecting, and the merge test gains the untrusted cases.
  • T250 Follow a machine to where its session is advertised when its link is down, per FR-P04, SC-P01 (R-105), Constitution Principle I — done: PeerConfig.advertised_as holds the session name advertised at the machine's address; discovery wakes a watcher when a session is resolved or goes, and a session reporting a change prompts the same look; the session supervisor's Move command refuses for a machine carrying MIDI. No contract change. A test starts a network port whose machine is at a dead port, hands the daemon an advertisement as discovery reports one, and checks the connection, the stored address, and that a connected machine is not moved; next_step is unit tested for port, host, trust and identity. Checked live between two daemons on one Mac (R-105).
  • T251 Prove which network port a session is, and follow a proved port to another host or under another name, per FR-P05, FR-P06, FR-P07, SC-P02 (R-106) — done: an Ed25519 key per daemon in identity.key; mhkey and mhport in each session's TXT record through all three responders; IdentityPacket in the RTP-MIDI crate, read by the packet fuzz target; the supervisor answers a challenge and sends one with Prove; PeerConfig.key and port_id are stored once proved at the address connected to. New dependencies ed25519-dalek and hex. No contract change. Tests over real sockets: a daemon without the key advertising it is not followed and one with it is, with trust kept; a forged key at a connected machine's address is not stored and the real one is. Removing the comparison with the expected key fails both. The packet round trip and the proof's refusals are unit tested. Checked live between two daemons on one Mac (R-106), and the packet fuzz target ran 1,474,155 inputs in 61 s without a finding. The Linux gates pass, and a port advertised through Avahi was listed by Audio MIDI Setup, connected to Apple's session, and was invited by rtpmidid, with a note each way (R-106). Not run: the Windows responder.
  • T252 Answer a machine at the address it was heard from, scope included, so an invitation over an IPv6 link-local address is accepted (R-107), per FR-011, Constitution Principle I — done: canonical keeps an IPv6 address whole and on_port moves an address to the data port without rebuilding it. A unit test over the two functions covers an IPv4-mapped sender and a link-local one on each port. Checked live: Apple's Session 1 invited a port on Linux over fe80:: and joined, with a note each way.