[PD] ugly "already connected" errors

Roman Haefeli reduzent at gmail.com
Fri Jan 25 22:25:07 CET 2019


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
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20190125/02e6b5f0/attachment.sig>


More information about the Pd-list mailing list