Control clients do not receive updates on time

[arpena]

Describe the bug Some clients of the control port (1705) don't receive updates on time. The TCP connection shows a non-zero Send-Q value on netstat:

$ netstat -an | grep 1705
tcp        0      0 0.0.0.0:1705            0.0.0.0:*               LISTEN
tcp        0      0 172.22.0.2:1705         192.168.1.x:59663     ESTABLISHED
tcp        0      0 172.22.0.2:1705         172.22.0.1:45342        ESTABLISHED
/ $
/ $ netstat -an | grep 1705
tcp        0      0 0.0.0.0:1705            0.0.0.0:*               LISTEN
tcp        0    127 172.22.0.2:1705         192.168.1.x:59663     ESTABLISHED
tcp        0      0 172.22.0.2:1705         172.22.0.1:45342        ESTABLISHED
/ $ netstat -an | grep 1705
tcp        0      0 0.0.0.0:1705            0.0.0.0:*               LISTEN
tcp        0    253 172.22.0.2:1705         192.168.1.x:59663     ESTABLISHED
tcp        0      0 172.22.0.2:1705         172.22.0.1:45342        ESTABLISHED

The example above is from running snapserver on a docker container with a bridged network, but I could reproduce the same behavior with host networking. Also, this is not dependent of the client, I can reproduce it using python's snapcast module or even netcat.

The behavior is not present on the websocket control port, that correctly pushes the message to the client as soon as it is generated.

Steps to Reproduce

1. Connect to a snapcast server control port 1705 using netcat or telnet
2. Receive correctly a few updates and wait for a while (typically 10 minutes or so, but sometimes it never receives even the first updates)
3. The updates are not received by the client and the server operating system shows a growing send-q
4. Sometimes the server port closes before sending the updates, others it synchronizes with the client

Environment details

• OS: Ubuntu 22.04.3 LTS
• Snapcast version 0.27.0
• Installed from ubuntu distro package

[arpena]

Probably disabling Nagle Algorithm could help at https://github.com/badaix/snapcast/blob/39ee4cc3a5dffc57221015dbc291fb429ac82835/server/control_server.cpp#L143

[badaix]

Not reproducible on my side. Since you're facing the problem, could you test with Nagle disabled? I cannot imagine that Nagle is causing the problem. It will latest send packets out upon reception of the previous packet's ACK.