On Fri, 2019-01-25 at 22:44 +0100, Christof Ressi wrote: > > From reading a bit more about protocols, particularly about ICMP > > [1], I > > think what happens is that the receiving host sends a ICMP error > > packet > > to the sending host, telling that the destination port is > > unreachable. > > thanks, this might explain what happens. note, though, that this is > not required behaviour for a UDP socket (and I haven't encountered > this outside Pd), so I would rather make this optional (or add an > option to deactivate this). The reason is that sometimes you just > want to broadcast messages no matter if something is actually > listening and you don't want that the sender to shut down just > because the receiver is temporarily unavailable. of course you can > wrap each message in a [connect( [disconnect( pair, but I think it's > only an ugly workaround.
Yeah, I see how the current behavior is impractical. I'm just saying it is probably not a bug. > > can tell that the socket of [udpsend] is closed, because when you > > fire > > up the listening socket again, messages sent with [udpsend] still > > don't > > reach their destination. > > I can't confirm this. I just tested with a pair of [udpsend] and > [udpreceive] (both iemlib and mrpeach) and I can change ports in > [udpreceive] or delete/recreate it without [udpsend] closing its > socket. only tested via localhost, though. The key is that you send something between deletion and recreation. Otherwise you won't trigger an ICMP response. I tested also on localhost with a [udpreceive] and still get same behaviour I described. BTW, that's on Linux, maybe other platforms behave differently? Roman
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
