[PD-dev] netsend/netreceive UDP ignore ECONNREFUSED

[Dan Wilcox]

Actually, this behavior leads to another problem: setting the keep alive flag for [netsend] object results in other objects staying alive as well. This is because of the aforementioned recv() catching the errno instead of send().

Obviously, it would be best if any flag only applies to its individual object and I have a workaround...but this seems like more of a fundamental problem. I can imagine patches using multiple [netsend]/[netreieves] may run into issues where an error thrown by one object ends up closing the socket of another in the t_socketreceiver polling function.

> On Mar 24, 2019, at 12:32 PM, Dan Wilcox <danomatika at gmail.com> wrote:
> 
> Ah, this is because [netsend] also creates a receiver which polls for messages for the return outlet. The initial send() blocks a little but the recv() in the polling function catches the error before send() returns. If I change netsend_new() so it does not create the receiving, the error is caught after send() as expected.
> 
> In any case, I think a creation arg may be the safest way to go with this for now. This kind of change definitely requires some cross platform testing to vet and we can decide later on about keeping the flag or promoting new default behavior.
> 
>> On Mar 24, 2019, at 12:21 PM, Dan Wilcox <danomatika at gmail.com <mailto:danomatika at gmail.com>> wrote:
>> 
>> (sending again, on list)
>> 
>> One thing weird to me, is that the error not caught after nets end's send() call. It's caught later on by recv() at some point. So send() is not blocking on my system and/or we only receive that error when the IP subsystem "sends" as a reply to the application. Weird.
>> 
>> The man pages for send() on macOS don't list ECONNREFUSED in the error codes for the function...
>> 
>>> On Mar 23, 2019, at 12:59 AM, Christof Ressi <christof.ressi at gmx.at <mailto:christof.ressi at gmx.at>> wrote:
>>> 
>>> ha! the [netsend -u] behaviour has always been a pet peave of mine. I've always wanted to fix this, but didn't find time yet... :-(
>>> 
>>> personally, I would prefer solution nr. 1 (keep the socket open) as this is how most people expect UDP to work. I don't know how many patches rely on the current behaviour (apart from reconnecting after the socket has been closed). can you think of any sane use cases for this? (I'm only talking about UDP sockets of course).
>>> 
>>> anyway, I'm already happy if there would be *some* way to keep the socket open, so a flag would be also fine.
>>> 
>>> regarding improvements to [netsend], have you also considered this? https://github.com/pure-data/pure-data/issues/378 <https://github.com/pure-data/pure-data/issues/378>
>>> 
>>> I can also contribute, but only after March.
>>> 
>>> Christof
>>> 
>>> 
>>> Gesendet: Freitag, 22. März 2019 um 22:56 Uhr
>>> Von: "Dan Wilcox" <danomatika at gmail.com <mailto:danomatika at gmail.com>>
>>> An: pd-dev <pd-dev at lists.iem.at <mailto:pd-dev at lists.iem.at>>
>>> Betreff: [PD-dev] netsend/netreceive UDP ignore ECONNREFUSED
>>> 
>>> Howdy all,
>>>  
>>> I've been making some proposal work for updates to netsend/netreceive.
>>>  
>>> One issue is making UDP sending ignore connection refused errors. I have this working by catching the return value from recv():
>>>  
>>>         /* keep UDP alive */
>>>     if (sys_sockerrno() == ECONNREFUSED && x->x_protocol == SOCK_DGRAM)
>>>         return;
>>>  
>>> (I added sys_sockerrno() to return the socket errno.)
>>>  
>>> From my reading on the socket API, sending a UDP message conceptually shouldn't care about whether the receiver is there. However this is detected on a lower networking layer and propagated up to the application layer where it can be used or ignored.
>>>  
>>> My questions are:
>>>  
>>> 1. Should this ignore silently and not close the connection? I notice mrpeach [udpsend] seems to ignores the first try, then closes the socket on the next failure. However, I like keeping the socket as no errors are thrown and you can easily break than re-establish UDP sending/receiving. This works well with the [netsend] dst & source relays.
>>>  
>>> 2. Should this be a creation argument, say -k? I imagine there are plenty of patches which expect the socket to be closed automatically and respond to a 0 from the connection outlet. On the other hand, as UDP is "connectionless" my thinking is that the conceptual "connection" of a UDP [netsend] (aka outlet) refers to the internal socket and not necessarily that the destination is reachable. With TCP, the connection state more obviously refers to 1-1 connection with the other side.
>>>  
>>> 
>>> --------
>>> Dan Wilcox
>>> @danomatika[http://twitter.com/danomatika <http://twitter.com/danomatika>]
>>> danomatika.com <http://danomatika.com/>[http://danomatika.com <http://danomatika.com/>]
>>> robotcowboy.com <http://robotcowboy.com/>[http://robotcowboy.com <http://robotcowboy.com/>]
>>>  _______________________________________________ Pd-dev mailing list Pd-dev at lists.iem.at <mailto:Pd-dev at lists.iem.at>https://lists.puredata.info/listinfo/pd-dev[https://lists.puredata.info/listinfo/pd-dev <https://lists.puredata.info/listinfo/pd-dev[https://lists.puredata.info/listinfo/pd-dev>]
>> 
>> --------
>> Dan Wilcox
>> @danomatika <http://twitter.com/danomatika>
>> danomatika.com <http://danomatika.com/>
>> robotcowboy.com <http://robotcowboy.com/>
>> 
>> 
>> 
> 
> --------
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com <http://danomatika.com/>
> robotcowboy.com <http://robotcowboy.com/>
> 
> 
> 

--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20190324/b5d785ea/attachment-0001.html>