[PD] ugly "already connected" errors

[Christof Ressi]

> 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.

> 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 only inconsisteny
> I can see with [netsend] is that you need to send actually two messages
> to an unreachable destination before it outputs a '0' (the first
> message only triggers the error: 'recv: Connection refused (111)').

that's true. I have observed this too.

Christof


> Gesendet: Freitag, 25. Januar 2019 um 22:25 Uhr
> Von: "Roman Haefeli" <reduzent at gmail.com>
> An: "Christof Ressi" <christof.ressi at gmx.at>
> Cc: pd-list at lists.iem.at
> Betreff: Re: Aw: Re: [PD] ugly "already connected" errors
>
> On Fri, 2019-01-25 at 21:09 +0100, Christof Ressi wrote:
> > > the sender socket is in some cases
> > > notified about the termination of the receiving socket.
> > 
> > this what happens in Pd with [netsend -u], but it's *not* what one
> > would expect from UDP. on all the socket libraries I've used,
> > "connect" doesn't do much on a UDP socket, it only sets the default
> > address, so you don't have to provide it explicitly for every
> > datagram you send, and you can change it whenever you like.
> > see also: http://man7.org/linux/man-pages/man2/connect.2.html
> > 
> > So UDP shouldn't really know if the destination socket actually
> > exists because there is no established connection. I actually filed a
> > bug report which is somehow related to this: 
> > https://github.com/pure-data/pure-data/issues/373
> > 
> > Note that [udpsend] from iemlib / mrpeach behaves correctly in that
> > it doesn't stop working if the destination doesn't exist.
> > 
> > I promised to look at the code and find out what's really going on in
> > [netsend -u] but I didn't have time yet :-(
> 
> If I understand you correctly, you observe a difference between
> [netsend -u] and [iemnet/udpsend].
> 
> Contrary to your observation,  I observe that both behave similar, but
> only [netsend -u] shows an appropriate error. 
> 
> It seems that sending UDP datagrams to an unreachable destination
> causes the internal socket of [udpsend] or [netsend -u] to be closed.
> [netsend -u] even reflects that by sending '0' to its outlet. But you
> 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. You have to first 'disconnect' and'connect'
> again, before messages are actually sent. Also here, [netsend -u] is
> more consistent in that you have to only 'connect' (it is already in a
> disconnected state).
> 
> 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.
> 
> It's important to note that merely sending 'connect' to
> [udpsend]/[netsend -u] doesn't trigger a ICMP error message. You have
> to actually send a datagram for that to happen. So the notion that UDP
> has no notion of a connection is still valid. 
> 
> You can send data to a destination, close the socket on the
> destination, open it again and still send data. However, when you send
> data at the time the receiving socket is closed, the ICMP message is
> triggered.
> 
> Also, not all firewalls let such a ICMP response pass, so you might
> find some setups where the socket of [netsend -u] and [udpsend] is not
> shut down.
> 
> I don't think [netsend] has a bug in this regard. The only inconsisteny
> I can see with [netsend] is that you need to send actually two messages
> to an unreachable destination before it outputs a '0' (the first
> message only triggers the error: 'recv: Connection refused (111)').
> 
> [udpsend] doesn't even show an error or reports anything to its outlet,
> although its socket was shut down. That might be worth writing a bug
> report for.
> 
> Roman
> 
> [1] 
> https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#Destination_unreachable
>  
>