Or, simpler yet, just send "listen 0" to netreceive to get it to relinquish whatever socket it's listening on.
cheers M On Sun, Feb 28, 2021 at 07:35:23PM +0100, Pierre Guillot wrote: > Thank you! In fact, this problem is the opportunity for me of a really good > introduction to sockets :) I was completely lost in this subject and I > might have gone in all the possible directions. > So I have to ensure that netreceive_free() is called before the new object > is created and the netreceive_listen() is called. I can debug directly with > Xcode attached to Reaper so it should be easy to check. > Thank you again IOhannes and Cristof! > > Le dim. 28 f??vr. 2021 ?? 12:52, Christof Ressi <[email protected]> a > ??crit : > > > To give some more background info: > > > > When you close a UDP socket, the port becomes available immediately, > > because UDP is connectionless. > > > > With TCP, however, a closed socket remains in the TIME WAIT state for > > some time during which the port still appears to be taken (for an > > explanation, see > > > > https://urldefense.com/v3/__https://networkengineering.stackexchange.com/questions/19581/what-is-the-purpose-of-time-wait-in-tcp-connection-tear-down__;!!Mih3wA!RkjZdCSInig2AhjZNM7HuV0K_MU8NU1sJnEEXfOQxePt0DIftRRb4vBbbkM3$ > > ). > > > > > > > > Now, as IOhannes explained, SO_REUSEADDR resp. SO_REUSEPORT allows > > several sockets to bind to the same port. > > > > In the context of TCP, this is often used to make a TCP port available > > immediately after closing a socket. This should never be necessary for UDP. > > > > There are some cases where you want several *active* sockets to listen > > on the same port. Generally, it is not specified which one receives the > > packet. Since TCP is a stream protocol, it rarely makes sense to have > > several active sockets listening on the same port because the data would > > be distributed arbitrarily between sockets. With UDP, you always get a > > complete datagram. On Linux, you can even use SO_REUSEPORT to build a > > multi-threaded UDP server > > ( > > https://urldefense.com/v3/__https://engineering.opensooq.com/using-so_reuseport-flag-in-multi-processes-and-multi-threaded-udp-server/__;!!Mih3wA!RkjZdCSInig2AhjZNM7HuV0K_MU8NU1sJnEEXfOQxePt0DIftRRb4v_MXUTq$ > > > > ). > > > > Finally, there is an exception for UDP multicast, where it is guaranteed > > that all sockets on the same port that have joined the same multicast > > group receive the same packet. > > > > --- > > > > > So the problem might be that when the patch is closed in the camomile > > plugin, the connection used by the [netreceive] object is not really > > detached > > > > In your case, since you're using UDP, the port should be released > > immediately on closing the patch. Maybe the DAW tries to open the new > > plugin *before* closing the old one? You could check this with some good > > old printf debugging :-) > > > > Christof > > > > > > On 28.02.2021 09:29, Pierre Guillot wrote: > > > Thank you for the clarification! > > > > > > So the problem might be that when the patch is closed in the camomile > > plugin, the connection used by the [netreceive] object is not really > > detached (I guess internally, it???s not synchronous). So when the patch is > > reopened, the new connection cannot be done because the address is still > > already in use. > > > > > > One solution could be to ensure that the connection is detached when > > closing a patch. > > > > > > But I don???t understand why this is different in Pd and in Camomile... > > > > > >> Le 27 f??vr. 2021 ?? 21:17, IOhannes m zm??lnig <[email protected]> a > > >> ??crit > > : > > >> > > >> ???Am 27. Februar 2021 19:22:26 MEZ schrieb Pierre Guillot < > > [email protected]>: > > >>> Is it normal? > > >> yes. > > >> this is how networking works. > > >> only a single listener on any given port pet interface. > > >> > > >> > > >>> I managed to solve this problem by replacing SO_REUSEADDR to > > >>> SO_REUSEPORT > > >>> on the function socket_set_boolopt() (l. 703 of x_net.c). I don't know > > >>> much > > >>> about sockets but I understand that it allows two [netreceive] objects > > >>> to > > >>> use the same address AND the same port. Do you think this is a proper > > >>> way > > >>> of fixing this problem? > > >> no it's not. > > >> as you've already discovered, this is not supported on all platforms, > > and those platforms that do support SO_REUSEPORT, can (and do) implement it > > very differently. > > >> in most cases it will allow you to bind to the same port multiple > > times, but you will not receive data on all clients. > > >> > > >> https://urldefense.com/v3/__https://stackoverflow.com/a/14388707__;!!Mih3wA!RkjZdCSInig2AhjZNM7HuV0K_MU8NU1sJnEEXfOQxePt0DIftRRb4t88zawK$ > > >> > > >> > > >> one possible fix for this is to have a single socket that binds to the > > port, that serves all `[netreceive]` instances (using that port). this > > obviously canbonly work if all `[netreceive]` instances live in the same > > application. > > >> > > >> you might also have luck with multicast. > > >> > > >> > > >> mfg.hft.fsl > > >> IOhannes > > >> > > >> > > >> _______________________________________________ > > >> Pd-dev mailing list > > >> [email protected] > > >> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!RkjZdCSInig2AhjZNM7HuV0K_MU8NU1sJnEEXfOQxePt0DIftRRb4smhDPu8$ > > >> > > > > > > > > > _______________________________________________ > > > Pd-dev mailing list > > > [email protected] > > > https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!RkjZdCSInig2AhjZNM7HuV0K_MU8NU1sJnEEXfOQxePt0DIftRRb4smhDPu8$ > > > > > > > > > > > _______________________________________________ > > Pd-dev mailing list > > [email protected] > > https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!RkjZdCSInig2AhjZNM7HuV0K_MU8NU1sJnEEXfOQxePt0DIftRRb4smhDPu8$ > > > > > _______________________________________________ > Pd-dev mailing list > [email protected] > https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!RkjZdCSInig2AhjZNM7HuV0K_MU8NU1sJnEEXfOQxePt0DIftRRb4smhDPu8$ > _______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
