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
