Re: casually blocked UDP port

From: Gavin Lambert (boost_at_[hidden])
Date: 2022-01-16 22:02:37

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.

On 17/01/2022 09:15, Alexander Carôt wrote:
> I'd consider using boost asio SO_REUSEPORT option in order to reuse
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.