James Coleman
be2e93bcda
- 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.
2.1 KiB
Data Model: Network Ports
Part of the domain model; identity and the endpoint are
shared by every spec. Types live in midi-harbor-core unless noted.
NetworkSession (FR-008..015)
NetworkSession {
local_name: String // what we advertise (FR-009)
control_port: u16 // data port is control_port + 1
peer: Option<PeerRef>
invitation_policy: InvitationPolicy
sync: Option<ClockSync>
journal_stats: JournalStats
direction_policy: SessionDirection
}
InvitationPolicy is Prompt (default), AcceptKnown, AcceptAll, or RejectAll (FR-014).
ClockSync carries the estimated offset, round-trip latency, and time of last successful exchange
— the last of which is the authoritative liveness signal (R-010).
JournalStats carries messages_recovered, journal_bytes, and highest_seq_acked, exposing
FR-045's "lost" and "recovered" counters.
Peer
A discovered or manually added remote party (FR-008, FR-010).
Peer {
id: PeerId
advertised_name: String
addresses: Vec<SocketAddr> // may be several; may change over time
source: PeerSource // Discovered | Manual
trusted: bool // "always accept from this peer"
advertised_as: Option<String> // the session name advertised at its address; followed when it moves (R-105)
key: Option<String> // its daemon's public key, once proved (R-106)
port_id: Option<EndpointId> // which of that daemon's network ports it is, once proved (R-106)
last_seen: Option<Timestamp>
is_self: bool // never offered to the user (edge case)
}
Validation: a peer whose addresses is empty and whose source is Manual is invalid.
Discovered peers may briefly have no address while mDNS resolution is pending. Two peers
advertising the same name are kept distinct by PeerId and disambiguated in the UI by address
(edge case: duplicate peer names).