Re: [Boost-users] casually blocked UDP port

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. Then doing: "netstat -p UDP" shows me the following Proto Recv-Q Send-Q Local Address Foreign Address (state) udp4 1026 0 *.50050 *.* 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. Best Alex Thanks for the swift response, Andreas ! In fact I am aware of what you wrote but with regard to the conditions my app works under it is extremely unlikely that some other process is taking this port. However, the next step for me is to identify which process actually has taken it. In that regard a follow-up question: Once an application (which uses boost sockets) has shut down (for crash or other reasons) the local bind port is also automatically released, right ? In other words: Can the OS stick a port although the corresponding application is not existent anymore ? I've been assuming no so far but maybe I am mistaken so I just need confirmation. Thank you, best Alex -- http://www.carot.de Email : Alexander@Carot.de Tel.: +49 (0)177 5719797

Gesendet: Samstag, 15. Januar 2022 um 23:46 Uhr Von: "Andreas Wehrmann via Boost-users" An: boost-users@lists.boost.org Cc: "Andreas Wehrmann" Betreff: Re: [Boost-users] casually blocked UDP port

Am 14.01.2022 um 22:50 schrieb Alexander Carôt via Boost-users:

...

Hello all,

I have a problem with a a casually blocked UDP bind port: My application uses UDP port 50050 and initiates the socket this way:

So I am basically using bind port 50050 and if it fails I am increasing it by one until the bind suceeds. In most cases the bind to port 50050 works fine but casually after a relaunch of the app or a crash the bind port 50050 appears to be blocked which is why it increases to higher numbers.

Hi, be aware that UDP sockets may are opened and closed for sending a single request only by many applications/services. If the sending application doesn't care about the local port and leaves it up to the OS to assign a local port number, you may run into the situation that another application/service/daemon is opening a UDP socket, not caring about the local port and the OS happens to assign the port number that you want to bind your own socket to.

All the best, Andreas

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users