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