The gateway authorizes remote-to-LAN frames from the relay lifecycle table. A
new client can start sending Ethernet datagrams as soon as it receives its
welcome, so the relay should notify already-present peers before returning that
welcome to the joining peer.
Register the accepted peer, send the PeerJoined event to existing peers, and
then send the welcome to the joining peer. If the welcome write fails after the
pre-notification, remove the accepted peer and send PeerLeft so existing peers
do not retain stale client MAC state.
This still is not a cross-connection delivery proof, but it puts the relay-side
ordering in the right direction for first DHCP/ARP frames after a client joins.
Test Plan:
- cargo test -p lanparty-relay
- cargo fmt --check
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- git diff --check
- git diff --cached --check
Refs: PLAN.md MVP relay lifecycle and gateway MAC learning
ddidderr
1d469d437b