Eventually I could figure what was wrong: Besides the pure audio streaming I perform a traceroute for statistical reasons. The call is set via fp = popen(exec.c_str(), "r"); where exec contains the console based traceroute call and this one is still in action after the main app has shut down and this keeps the port up until the traceroute has timed out (which can take several minutes in cases when ICMP answers are blocked for specific locations). Now I just need to reimplement this differently. I investigated this issue on OSX where netstat cannot show the PID. Therefore I used lsof -i -n -P | grep 50050 which did the job eventually and showed the traceroute still running. At the end it was not really boost related but thanks a lot anyways for your help ! Best Alex -- http://www.carot.de Email : Alexander@Carot.de Tel.: +49 (0)177 5719797
Gesendet: Sonntag, 16. Januar 2022 um 23:02 Uhr Von: "Gavin Lambert via Boost-users" <boost-users@lists.boost.org> An: boost-users@lists.boost.org Cc: "Gavin Lambert" <boost@mirality.co.nz> Betreff: Re: [Boost-users] casually blocked UDP port
On 17/01/2022 06:35, Alexander Carôt wrote:
P.S.: see below – I now know how to reproduce the issue: When my application does receive UDP streaming data I spontaneously quit the application. [...] So, basically the receive queue for this socket is not empty and the previous bind port is indeed still there. If anyone has an idea how to proceed from here on please let me know but now I might be able to fix it myself already.
Yes, the OS will hold the port for a while after an ungraceful shutdown to allow proper Internet protocol timeouts.
I'd consider using boost asio SO_REUSEPORT option in order to reuse
On 17/01/2022 09:15, Alexander Carôt wrote: the port if already taken according to this thread:
https://stackoverflow.com/questions/34596638/boost-asio-so-reuseport
I will try it asap but please let me know if you have concerns or better solutions.
That is indeed one possible approach; the other is to back off and wait to retry later.
Bear in mind that your new process may receive stale data intended for the old process, and may also receive garbage data from some completely unrelated process, and must be able to tolerate both without crashing.
In addition, the other end of the conversation may not be able to detect that the connection was dropped and restarted, so may not do any "connection re-established" logic that might be required.
That's the tradeoff you make for using that option. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users