[netsend -u] shouldn't disconnect if there is no receiver

[Spacechild1]

Let's say I have a [netsend -u] object. Whenever I send one or more messages while there's currently no listener, I get one of the following socket errors:

netsend: Unknown error (10057)

warning: 812 removed from poll list but not found

---

netsend: Unknown error (10038)

warning: 836 removed from poll list but not found

the sender has basically shut down and I can't send any more messages until I "reconnect".

this behaviour makes sense for [netsend] in TCP mode where you really have a connection, but UDP is connectionless and the sender shouldn't care if someone is listening.
for example, [iemnet/udpsend] gets it right: you can "connect" and send bytes no matter if there's a listener or not, but with [netsend -u] you have to make sure to not send any message
a) before the listener is opened.
b) whenever the listener is (temporarily) gone.

this kind of defeats the purpose of using UDP...

I'm on Windows 7, Pd 0.48.1. Does this also happen on Linux and OSX?

[umlaeute]

otoh, you could simply issue a [disconnect, connect <HOST> <PORT>( message whenever the object tells you that it has lost "connection".

[Spacechild1]

this is a valid workaround, but I still think it's a bug we should fix. I basically don't understand why [netsend -u] cares at all if the endpoint exists... I'll have a look in the code to see what's going on.

[danomatika]

I find it useful that it prints the fact there is no-one to receive the message. Closing the socket keeps messages for being printed over and over.

[Spacechild1]

A UDP socket shouldn't care if someone is receiving the message.

[danomatika]

... but it's not a bad idea to know the receiver isn't there. From what I've read of the IP & sockets API, the connection refused error is thrown in the IP layer and sent up to the application layer. So even though the concept of the UDP message is "connectionless", the application has to decide to ignore the error directly. In this case, I don't think we'd want to change the current behavior but perhaps add a new creation flag to ignore the error per-instance.

[danomatika]

I actually think this is more of a bug fix now...

[Spacechild1]

already fixed in master