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.
I'd consider using boost asio SO_REUSEPORT option in order to reuse
Yes, the OS will hold the port for a while after an ungraceful shutdown to allow proper Internet protocol timeouts. 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.