sorry for spamming the list today. @Dan you have probably read this already: https://stackoverflow.com/questions/41231270/econnrefused-errors-on-udp-sendto
turns out that at least on my system (Windows 7) [netsend -u] only closes the socket when sending to a non-reachable port on *localhost*. sending to any other (existing or non-existing) host won't close the socket. this means that there's even less reason to consider this a feature and I'm not sure if there are really any patches out there which depend on this behaviour. Christof > Gesendet: Dienstag, 26. März 2019 um 04:01 Uhr > Von: "Christof Ressi" <[email protected]> > An: "Dan Wilcox" <[email protected]> > Cc: pd-dev <[email protected]> > Betreff: Re: [PD-dev] netsend/netreceive UDP ignore ECONNREFUSED > > BTW, I've found the commit which introduced the backsending mechanism to > [netsend]: > https://github.com/pure-data/pure-data/commit/33627264be356096ff132272dbaaf7c5cdb44145#diff-92df49f719ba20e4c90e10e70c3d9154 > > before adding a socketreceiver to [netsend -u], the socket would never close > (I just checked with Pd 0.46)! so although the current behaviour of closing > the socket *could* be seen as a feature, it certainly has been a regression > (as it must have broken existing setups). since your fix basically restores > the old expected behaviour, I think it wouldn't need a flag, but that's just > my two cents. > > thanks for your work! > > Christof > > > Gesendet: Dienstag, 26. März 2019 um 03:13 Uhr > > Von: "Christof Ressi" <[email protected]> > > An: "Dan Wilcox" <[email protected]> > > Cc: pd-dev <[email protected]> > > Betreff: Re: [PD-dev] netsend/netreceive UDP ignore ECONNREFUSED > > > > nevermind, I've just seen that you've already implemented the fix by > > catching ECONNREFUSED. the take away from my last e-mail is probably that > > the socket receiver in [netsend -u] doesn't work, so that's something you > > can add to your list :-D. in a few days I can help if needed, at the very > > least I can do crossplatform testing. > > > > > Gesendet: Dienstag, 26. März 2019 um 02:21 Uhr > > > Von: "Christof Ressi" <[email protected]> > > > An: "Dan Wilcox" <[email protected]> > > > Cc: pd-dev <[email protected]> > > > Betreff: Re: [PD-dev] netsend/netreceive UDP ignore ECONNREFUSED > > > > > > that's very strange as it shouldn't make any difference. what I *suspect* > > > is really happening is that the socket isn't added to the readset in > > > sys_domicrosleep and so the pollfunction (containing the call to recv) is > > > never called. this is just a wild guess, though. > > > > > > on the other hand, I couldn't test this quickly, as sending back to > > > [netsend -u] seems to be broken anyway... I've tried with both providing > > > the src port like [connect localhost 9999 9997( or getting the port > > > number with [iemnet/udpreceive]. I even doesn't work when using another > > > [netsend -u]... > > > > > > actually, the easiest fix is to just suppress creating the right outlet > > > (so no socketreceiver is created). it's a bit lazy, though :-) but it > > > could mean something like: we just want to "broadcast" messages without > > > any notion of "connection", therefore we don't need the right outlet > > > either. > > > > > > here's a prove of concept: > > > https://github.com/Spacechild1/pure-data/tree/netsend-experiment > > > > > > I've attached a patch to demonstrate the problem with sending to > > > [netsend] and my lazy fix for [netsend]. > > > > > > Christof > > > > > > > > > Gesendet: Montag, 25. März 2019 um 23:03 Uhr > > > Von: "Dan Wilcox" <[email protected]> > > > An: "Christof Ressi" <[email protected]> > > > Cc: pd-dev <[email protected]> > > > Betreff: Re: [PD-dev] netsend/netreceive UDP ignore ECONNREFUSED > > > > > > I did some quick hacking/testing and it seems that for UDP: > > > > > > * not calling connect() in netsend_connect > > > * using sendto() with the server address struct in netsend_dosend > > > * & using recvfrom() instead of recv() in the socketreceiver > > > > > > results in no "Connection refused" errors being thrown. > > > > > > > > > > > > On Mar 25, 2019, at 11:32 AM, Christof Ressi > > > <[email protected][mailto:[email protected]]> wrote: > > > > > > > For connectionless sending essentially, I think we would need to forego > > > > the call to connect() in netsend_connect and keep a copy of the socket > > > > address struct > > > > > > IIUC, 'connect' on a UDP sockket does exactly that: it doesn't really > > > "connect" to anything but just stores the default destination address, so > > > 'connect' + 'send' is equivalent to 'sendto'. > > > at least that's how it has always worked for me. > > > > > > http://man7.org/linux/man-pages/man2/connect.2.html[http://man7.org/linux/man-pages/man2/connect.2.html] > > > > > > Christof > > > > > > > > > Gesendet: Montag, 25. März 2019 um 10:59 Uhr > > > Von: "Dan Wilcox" <[email protected][mailto:[email protected]]> > > > An: "Chris McCormick" <[email protected][mailto:[email protected]]> > > > Cc: pd-dev <[email protected][mailto:[email protected]]> > > > Betreff: Re: [PD-dev] netsend/netreceive UDP ignore ECONNREFUSED > > > > > > Sure, however neither netsend nor udpsend work this way, so I was first > > > trying to see what I could do without changing the internals a whole lot. > > > It's definitely not "connectionless" when it keeps returning to a > > > receiver... > > > > > > For connectionless sending essentially, I think we would need to forego > > > the call to connect() in netsend_connect and keep a copy of the socket > > > address struct to use with sendto() instead of send() when actually > > > sending. Since sendto() takes the address directly, it doesn't need a > > > connect() ahead of time. Also, the UDP netsend / netreceive relay > > > behavior could then use sendto() and recvfrom(). > > > > > > So conceptually, the current behavior of calling connect() for both UDP > > > and TCP needs to change and I'd think then the the "connected" outlet for > > > UDP simply means the socket is set up, but has no connotation for a > > > current "connection." Again, I'm not sure how that would affect patches > > > which would rely on the old behavior... > > > > > > On Mar 25, 2019, at 3:42 AM, Chris McCormick > > > <[email protected][mailto:[email protected]]> wrote: > > > > > > Hi Dan, > > > > > > On 23/3/19 5:56 am, Dan Wilcox wrote: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. > > > You probably know this already but it is possible to operate UDP in > > > connectionless or connection-oriented mode. Connection-oriented is > > > somewhere between TCP and connectionless. In connection-oriented mode I > > > suppose you would want to know if the other side is there or not, whereas > > > with connectionless you probably just want to fire and forget. Not sure > > > if this affects what you are doing but might help explain what you're > > > seeing. > > > > > > Cheers, > > > > > > Chris. > > > > > > -- > > > https://mccormick.cx/[https://mccormick.cx/] > > > > > > My tech development newsletter: > > > https://mccormick.cx/subscribe[https://mccormick.cx/subscribe] > > > > > > -------- > > > Dan Wilcox > > > @danomatika[http://twitter.com/danomatika] > > > danomatika.com[http://danomatika.com/] > > > robotcowboy.com[http://robotcowboy.com/] > > > _______________________________________________ Pd-dev mailing list > > > [email protected][mailto:[email protected]] > > > https://lists.puredata.info/listinfo/pd-dev > > > > > > -------- > > > 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 > > > > > > > > > > > _______________________________________________ > > Pd-dev mailing list > > [email protected] > > https://lists.puredata.info/listinfo/pd-dev > > > > > > _______________________________________________ > Pd-dev mailing list > [email protected] > https://lists.puredata.info/listinfo/pd-dev > _______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
