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
