[PD] ugly "already connected" errors
reduzent at gmail.com
Fri Jan 25 23:48:37 CET 2019
On Fri, 2019-01-25 at 22:44 +0100, Christof Ressi wrote:
> > From reading a bit more about protocols, particularly about ICMP
> > , 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: This is a digitally signed message part
More information about the Pd-list