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]
 

Attachment: netsend-test.pd
Description: Binary data

_______________________________________________
Pd-dev mailing list
[email protected]
https://lists.puredata.info/listinfo/pd-dev

Reply via email to