lost TCP connections of relays are not handled gracefully
I'm running icecast with a mointpoint that has both a IPv4 and a IPv6 address. IPv4 and IPv6 traffic go over different providers, so this is also being done for redundancy reasons.
I tested how well icecast handles the fallback from the IPv4 path to the IPv6 path or vice versa by killing the TCP connection or changing the route to "unreachable". It turns out that icecast connects to the other IPv4 or IPv6 path but connected clients will lose their connection immediately, which is bad. Of course we don't want to lose all our users and hope for them to reconnect to our stream in case of such a fallback in our upstream mount.
I tested exactly the same szenario with https://rocketbroadcaster.com/streaming-audio-server - and the Rocket Streaming Audio Server does handle this gracefully. The only thing that I was able to notice from the client side here was an ffmped audio decoding error message when the RSAS switched from the one path to the other path. But the switch was almost not noticable by clients.
It would be great if icecast would handle such a case as gracefully as the Rocket Streaming Audio Server.