rtpclient: harden connect path against port=0 endpoints and +1 port collisions

[ibiltari]

Hi! another small fix proposal:

What this PR fixes

Issue 1 — silent acceptance of [connect_to] blocks without port=

A [connect_to] block in the INI without an explicit port= line leaves settings.connect_to[].port as the empty string. That flows all the way through main.cpp::setup_network_rtpmidi_listener → make_local_alsa_listener → local_alsa_listener_t::connect_to_remote_server → rtpclient_t::add_server_addresses({{hostname, ""}}).

state_resolve_next_ip_port then calls network_address_list_t(hostname, "") → getaddrinfo(hostname, NULL), which returns sockaddrs with port 0. control_address.port() ends up 0, and every subsequent sendto() fails with EINVAL:

[ERROR] udppeer.cpp:112 | Error sending to 169.254.9.204:0. This is UDP... so just lost! (Invalid argument)
[ERROR] rtpclient.cpp:87 | Client: Could not send all data to CONTROL_PORT. Sent -1. Invalid argument (22)
[ERROR] rtpclient.cpp:314 | Error at rtpclient_t. Will try to connect again in 30000ms

The state machine's retry path re-resolves the same broken endpoint, so the client loops forever.

Fix (commit 1): default connect_to_t::port = "5004" in settings.hpp. The IANA-registered RTP-MIDI control port matches what users almost certainly mean when they omit it (and what every published INI example uses for [rtpmidi_announce]).

Issue 2 — state_resolve_next_ip_port should refuse port=0 entries

Even with the default in place, anyone constructing endpoints programmatically (or any other malformed config path) can still produce a resolved sockaddr with port 0. The state machine has no guard against this — it happily uses the entry, loops on EINVAL, and never recovers.

Fix (commit 2): in state_resolve_next_ip_port, refuse entries whose resolved port is 0, emit a clear ERROR, and advance to the next resolved sockaddr via ResolveFailed. Belt-and-braces alongside commit 1.

Issue 3 — state_connect_midi collides with other processes on control_port + 1

state_connect_control opens control_peer at a kernel-assigned ephemeral (when local_base_port_str == "0", which is what local_alsa_listener_t and rtpmidiremotehandler both pass for avahi-discovered peers). Then state_connect_midi calls bind(local_base_port + 1) for the MIDI socket.

The kernel ephemeral allocator can hand us a control_port whose +1 is owned by another process. Production case we hit: another cuems daemon on the same host (cuems-node-engine) had a UDP source port at 48650 from an outbound NNG connection; rtpmidid was assigned control = 48649 → MIDI bind on 48650 → EADDRINUSE → ConnectFailed → 30 s reconnect_timeout. On retry, kernel reuses the same ephemeral, same conflict — loop.

Fix (commit 3): speculatively bind both control_peer and midi_peer in state_connect_control before sending IN to the remote peer. If the +1 bind fails, close control_peer and retry with a fresh ephemeral pair, up to MAX_PAIR_RETRIES=5 times.

• Retry is gated on local_base_port_str == "0" (ephemeral mode). A user-configured fixed local_udp_port that collides on +1 is a config error — fail after one attempt with a clear message (unchanged behavior).
• state_connect_midi no longer calls midi_peer.open() (it's already bound). An is_open() sanity guard catches state-machine misuse.
• The new "midi_peer is bound before IN" invariant required closing midi_peer on every exit from the not-yet-fully-connected window. Three places now call midi_peer.close(): the control connect_timeout timer lambda, the control status_change !CONTROL_CONNECTED branch, and state_disconnect_control.

Verified

Reproduction on a real two-node cluster (one controller rtpmidi server, one node rtpmidi client driving an MTC chain through cuems-videocomposer):

State	MTC outage on controller systemctl restart rtpmidid
Pre-fix	permanent (the loop in Issue 1 never recovers without manual restart on both ends)
With commit 1 only	~33 s (Issue 3 still hits, 30 s reconnect_timeout + handshake)
With all three commits	~3 s (just the natural avahi REMOVE + rediscover latency)

Packet captures, journals, and aconnect snapshots from the test runs are available if useful for review.

Backward compatibility

None broken.

• Existing INIs with port= set in [connect_to] are unaffected (commit 1 only sets the default).
• Existing endpoints with valid resolved ports are unaffected by commit 2 (only port=0 entries are refused).
• Existing connect paths see commit 3 as a transparent retry on a rare-but-real failure mode. With local_udp_port set to a fixed value, the one-attempt + ERROR behavior matches pre-patch.

Thanks!!