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 danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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
I can also contribute, but only after March.
Christof
Gesendet: Freitag, 22. März 2019 um 22:56 Uhr Von: "Dan Wilcox" danomatika@gmail.com An: pd-dev pd-dev@lists.iem.at 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] danomatika.com[http://danomatika.com] robotcowboy.com[http://robotcowboy.com] _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li...]
(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 <christof.ressi@gmx.at mailto:christof.ressi@gmx.at> 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" <danomatika@gmail.com mailto:danomatika@gmail.com> An: pd-dev <pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at> 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:
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.
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 Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li... 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/
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 danomatika@gmail.com 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 <christof.ressi@gmx.at mailto:christof.ressi@gmx.at> 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" <danomatika@gmail.com mailto:danomatika@gmail.com> An: pd-dev <pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at> 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:
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.
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 Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li... 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/
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 danomatika@gmail.com 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 <danomatika@gmail.com mailto:danomatika@gmail.com> 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 <christof.ressi@gmx.at mailto:christof.ressi@gmx.at> 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" <danomatika@gmail.com mailto:danomatika@gmail.com> An: pd-dev <pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at> 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:
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.
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 Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li... 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/
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 danomatika@gmail.com 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 <danomatika@gmail.com mailto:danomatika@gmail.com> 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 <danomatika@gmail.com mailto:danomatika@gmail.com> 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 <christof.ressi@gmx.at mailto:christof.ressi@gmx.at> 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" <danomatika@gmail.com mailto:danomatika@gmail.com> An: pd-dev <pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at> 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:
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.
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 Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li... 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/
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.
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 chris@mccormick.cx 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.
My tech development newsletter: https://mccormick.cx/subscribe
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Well, that’s what the code does now, as far as I can tell.
enohp ym morf tnes ----------- Dan Wilcox danomatika.com robotcowboy.com
On Mar 25, 2019, at 11:32 AM, Christof Ressi christof.ressi@gmx.at 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
Christof
Gesendet: Montag, 25. März 2019 um 10:59 Uhr Von: "Dan Wilcox" danomatika@gmail.com An: "Chris McCormick" chris@mccormick.cx Cc: pd-dev pd-dev@lists.iem.at 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 chris@mccormick.cx 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.
My tech development newsletter: https://mccormick.cx/subscribe
Dan Wilcox @danomatika danomatika.com robotcowboy.com
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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 christof.ressi@gmx.at 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
Christof
Gesendet: Montag, 25. März 2019 um 10:59 Uhr Von: "Dan Wilcox" danomatika@gmail.com An: "Chris McCormick" chris@mccormick.cx Cc: pd-dev pd-dev@lists.iem.at 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 <chris@mccormick.cx mailto:chris@mccormick.cx> 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 Pd-dev@lists.iem.at 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/
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" danomatika@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-dev pd-dev@lists.iem.at 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 <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]> 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%5Bhttp://man7.org/linux/...] Christof
Gesendet: Montag, 25. März 2019 um 10:59 Uhr Von: "Dan Wilcox" <danomatika@gmail.com[mailto:danomatika@gmail.com]> An: "Chris McCormick" <chris@mccormick.cx[mailto:chris@mccormick.cx]> Cc: pd-dev <pd-dev@lists.iem.at[mailto:pd-dev@lists.iem.at]> 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 <chris@mccormick.cx[mailto:chris@mccormick.cx]> 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/%5Bhttps://mccormick.cx/]
My tech development newsletter: https://mccormick.cx/subscribe%5Bhttps://mccormick.cx/subscribe]
-------- Dan Wilcox @danomatika[http://twitter.com/danomatika] danomatika.com[http://danomatika.com/] robotcowboy.com[http://robotcowboy.com/] _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at] https://lists.puredata.info/listinfo/pd-dev
-------- Dan Wilcox @danomatika[http://twitter.com/danomatika] danomatika.com[http://danomatika.com] robotcowboy.com[http://robotcowboy.com]
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" christof.ressi@gmx.at An: "Dan Wilcox" danomatika@gmail.com Cc: pd-dev pd-dev@lists.iem.at 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" danomatika@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-dev pd-dev@lists.iem.at 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 <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]> 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%5Bhttp://man7.org/linux/...] Christof
Gesendet: Montag, 25. März 2019 um 10:59 Uhr Von: "Dan Wilcox" <danomatika@gmail.com[mailto:danomatika@gmail.com]> An: "Chris McCormick" <chris@mccormick.cx[mailto:chris@mccormick.cx]> Cc: pd-dev <pd-dev@lists.iem.at[mailto:pd-dev@lists.iem.at]> 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 <chris@mccormick.cx[mailto:chris@mccormick.cx]> 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/%5Bhttps://mccormick.cx/]
My tech development newsletter: https://mccormick.cx/subscribe%5Bhttps://mccormick.cx/subscribe]
Dan Wilcox @danomatika[http://twitter.com/danomatika] danomatika.com[http://danomatika.com/] robotcowboy.com[http://robotcowboy.com/] _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at] 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 Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
BTW, I've found the commit which introduced the backsending mechanism to [netsend]: https://github.com/pure-data/pure-data/commit/33627264be356096ff132272dbaaf7...
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" christof.ressi@gmx.at An: "Dan Wilcox" danomatika@gmail.com Cc: pd-dev pd-dev@lists.iem.at 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" christof.ressi@gmx.at An: "Dan Wilcox" danomatika@gmail.com Cc: pd-dev pd-dev@lists.iem.at 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" danomatika@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-dev pd-dev@lists.iem.at 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 <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]> 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%5Bhttp://man7.org/linux/...] Christof
Gesendet: Montag, 25. März 2019 um 10:59 Uhr Von: "Dan Wilcox" <danomatika@gmail.com[mailto:danomatika@gmail.com]> An: "Chris McCormick" <chris@mccormick.cx[mailto:chris@mccormick.cx]> Cc: pd-dev <pd-dev@lists.iem.at[mailto:pd-dev@lists.iem.at]> 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 <chris@mccormick.cx[mailto:chris@mccormick.cx]> 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/%5Bhttps://mccormick.cx/]
My tech development newsletter: https://mccormick.cx/subscribe%5Bhttps://mccormick.cx/subscribe]
Dan Wilcox @danomatika[http://twitter.com/danomatika] danomatika.com[http://danomatika.com/] robotcowboy.com[http://robotcowboy.com/] _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at] 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 Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
sorry for spamming the list today. @Dan you have probably read this already: https://stackoverflow.com/questions/41231270/econnrefused-errors-on-udp-send...
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" christof.ressi@gmx.at An: "Dan Wilcox" danomatika@gmail.com Cc: pd-dev pd-dev@lists.iem.at 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/33627264be356096ff132272dbaaf7...
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" christof.ressi@gmx.at An: "Dan Wilcox" danomatika@gmail.com Cc: pd-dev pd-dev@lists.iem.at 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" christof.ressi@gmx.at An: "Dan Wilcox" danomatika@gmail.com Cc: pd-dev pd-dev@lists.iem.at 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" danomatika@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-dev pd-dev@lists.iem.at 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 <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]> 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%5Bhttp://man7.org/linux/...] Christof
Gesendet: Montag, 25. März 2019 um 10:59 Uhr Von: "Dan Wilcox" <danomatika@gmail.com[mailto:danomatika@gmail.com]> An: "Chris McCormick" <chris@mccormick.cx[mailto:chris@mccormick.cx]> Cc: pd-dev <pd-dev@lists.iem.at[mailto:pd-dev@lists.iem.at]> 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 <chris@mccormick.cx[mailto:chris@mccormick.cx]> 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/%5Bhttps://mccormick.cx/]
My tech development newsletter: https://mccormick.cx/subscribe%5Bhttps://mccormick.cx/subscribe]
Dan Wilcox @danomatika[http://twitter.com/danomatika] danomatika.com[http://danomatika.com/] robotcowboy.com[http://robotcowboy.com/] _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at] 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 Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
That's good to know.
I think I have this working. I will do some cleanup and a push, then you can test.
On Mar 26, 2019, at 4:43 AM, Christof Ressi christof.ressi@gmx.at wrote:
sorry for spamming the list today. @Dan you have probably read this already: https://stackoverflow.com/questions/41231270/econnrefused-errors-on-udp-send...
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
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Incidentally, I get the same behavior (send fails if to a nonexistent local port, but keeps trying if non-local) on linux.
cheers Miller
On Tue, Mar 26, 2019 at 05:41:58PM +0100, Dan Wilcox wrote:
That's good to know.
I think I have this working. I will do some cleanup and a push, then you can test.
On Mar 26, 2019, at 4:43 AM, Christof Ressi christof.ressi@gmx.at wrote:
sorry for spamming the list today. @Dan you have probably read this already: https://stackoverflow.com/questions/41231270/econnrefused-errors-on-udp-send...
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
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
Chris McCormick -
Christof Ressi -
Dan Wilcox -
Miller Puckette