<div dir="ltr"><div>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. </div><div>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. <br></div><div>Thank you again IOhannes and Cristof!<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 28 févr. 2021 à 12:52, Christof Ressi <<a href="mailto:info@christofressi.com">info@christofressi.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">To give some more background info:<br>
<br>
When you close a UDP socket, the port becomes available immediately, <br>
because UDP is connectionless.<br>
<br>
With TCP, however, a closed socket remains in the TIME WAIT state for <br>
some time during which the port still appears to be taken (for an <br>
explanation, see <br>
<a href="https://networkengineering.stackexchange.com/questions/19581/what-is-the-purpose-of-time-wait-in-tcp-connection-tear-down" rel="noreferrer" target="_blank">https://networkengineering.stackexchange.com/questions/19581/what-is-the-purpose-of-time-wait-in-tcp-connection-tear-down</a>). <br>
<br>
<br>
Now, as IOhannes explained, SO_REUSEADDR resp. SO_REUSEPORT allows <br>
several sockets to bind to the same port.<br>
<br>
In the context of TCP, this is often used to make a TCP port available <br>
immediately after closing a socket. This should never be necessary for UDP.<br>
<br>
There are some cases where you want several *active* sockets to listen <br>
on the same port. Generally, it is not specified which one receives the <br>
packet. Since TCP is a stream protocol, it rarely makes sense to have <br>
several active sockets listening on the same port because the data would <br>
be distributed arbitrarily between sockets. With UDP, you always get a <br>
complete datagram. On Linux, you can even use SO_REUSEPORT to build a <br>
multi-threaded UDP server <br>
(<a href="https://engineering.opensooq.com/using-so_reuseport-flag-in-multi-processes-and-multi-threaded-udp-server/" rel="noreferrer" target="_blank">https://engineering.opensooq.com/using-so_reuseport-flag-in-multi-processes-and-multi-threaded-udp-server/</a>).<br>
<br>
Finally, there is an exception for UDP multicast, where it is guaranteed <br>
that all sockets on the same port that have joined the same multicast <br>
group receive the same packet.<br>
<br>
---<br>
<br>
> 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<br>
<br>
In your case, since you're using UDP, the port should be released <br>
immediately on closing the patch. Maybe the DAW tries to open the new <br>
plugin *before* closing the old one? You could check this with some good <br>
old printf debugging :-)<br>
<br>
Christof<br>
<br>
<br>
On 28.02.2021 09:29, Pierre Guillot wrote:<br>
> Thank you for the clarification!<br>
><br>
> 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.<br>
><br>
> One solution could be to ensure that the connection is detached when closing a patch.<br>
><br>
> But I don’t understand why this is different in Pd and in Camomile...<br>
><br>
>> Le 27 févr. 2021 à 21:17, IOhannes m zmölnig <<a href="mailto:zmoelnig@iem.at" target="_blank">zmoelnig@iem.at</a>> a écrit :<br>
>><br>
>> Am 27. Februar 2021 19:22:26 MEZ schrieb Pierre Guillot <<a href="mailto:guillotpierre6@gmail.com" target="_blank">guillotpierre6@gmail.com</a>>:<br>
>>> Is it normal?<br>
>> yes.<br>
>> this is how networking works.<br>
>> only a single listener on any given port pet interface.<br>
>><br>
>><br>
>>> I managed to solve this problem by replacing SO_REUSEADDR to<br>
>>> SO_REUSEPORT<br>
>>> on the function socket_set_boolopt() (l. 703 of x_net.c). I don't know<br>
>>> much<br>
>>> about sockets but I understand that it allows two [netreceive] objects<br>
>>> to<br>
>>> use the same address AND the same port. Do you think this is a proper<br>
>>> way<br>
>>> of fixing this problem?<br>
>> no it's not.<br>
>> 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.<br>
>> in most cases it will allow you to bind to the same port multiple times, but you will not receive data on all clients.<br>
>><br>
>> <a href="https://stackoverflow.com/a/14388707" rel="noreferrer" target="_blank">https://stackoverflow.com/a/14388707</a><br>
>><br>
>> 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.<br>
>><br>
>> you might also have luck with multicast.<br>
>><br>
>><br>
>> mfg.hft.fsl<br>
>> IOhannes<br>
>><br>
>><br>
>> _______________________________________________<br>
>> Pd-dev mailing list<br>
>> <a href="mailto:Pd-dev@lists.iem.at" target="_blank">Pd-dev@lists.iem.at</a><br>
>> <a href="https://lists.puredata.info/listinfo/pd-dev" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> Pd-dev mailing list<br>
> <a href="mailto:Pd-dev@lists.iem.at" target="_blank">Pd-dev@lists.iem.at</a><br>
> <a href="https://lists.puredata.info/listinfo/pd-dev" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-dev</a><br>
<br>
<br>
<br>
_______________________________________________<br>
Pd-dev mailing list<br>
<a href="mailto:Pd-dev@lists.iem.at" target="_blank">Pd-dev@lists.iem.at</a><br>
<a href="https://lists.puredata.info/listinfo/pd-dev" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-dev</a><br>
</blockquote></div>