Ok, I've rolled up my initial work and ideas into: https://github.com/pure-data/pure-data/pull/577 <https://github.com/pure-data/pure-data/pull/577>
> On Mar 24, 2019, at 1:25 PM, Dan Wilcox <[email protected]> wrote: > > 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> 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" <[email protected] <mailto:[email protected]>> >>>> An: pd-dev <[email protected] <mailto:[email protected]>> >>>> 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 >>>> [email protected] >>>> <mailto:[email protected]>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/> > > > -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
