You could try a longer connection timeout via the [timeout f( message. The default is 10 seconds, I believe, but maybe it might need more time if hosts take forever to resolve.
On Jun 3, 2021, at 6:00 PM, pd-list-request@lists.iem.at wrote:
Message: 3 Date: Thu, 03 Jun 2021 14:52:07 +0200 From: Roman Haefeli <reduzent@gmail.com mailto:reduzent@gmail.com> To: pd-list@lists.iem.at mailto:pd-list@lists.iem.at Subject: Re: [PD] UDP server with Pd Message-ID: <d588131641f4e973e59201abc884fc5191cb0e6c.camel@gmail.com mailto:d588131641f4e973e59201abc884fc5191cb0e6c.camel@gmail.com> Content-Type: text/plain; charset="utf-8"
On Tue, 2021-06-01 at 15:27 -0700, Miller Puckette via Pd-list wrote:
One solution (which the conniption server/client and quacktrip both use in somewhat different ways) is for a "netreceive" object to wait for an incoming connection and then, once one arrives, immediately to close its own listening port and for a "nestsend" in the same patch to open a connection to the IP and port that the "netreceive" reported (via its second outlet). It's a bit complicated but gets the job done.
Turns out this works for light loads only. For the loads I'm interested in, the clients get "disconnected". Probably the server is sending an ICMP notification that the destination port is not ready or something like that and [netsend -u -b] on the client side terminates the "connection" (outlet turns zero).
Roman
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Thu, 2021-06-03 at 19:51 +0200, Dan Wilcox wrote:
You could try a longer connection timeout via the [timeout f( message.
Isn't the 'timeout' method only affecting TCP sessions? In UDP nothing at all is sent when using 'connect' method. It internally sets destination address and port, I believe.
What I discovered is that when I create a UDP server with Miller's trick and I send a stream of packets to it, the [netsend -u -b] on the client side reports '0' shortly after starting the stream. Since UDP is actually state-less , what happens - I _believe_ - is that the server sends back a notification about the destination port not being reachable. I read somewhere that some systems do that.
The default is 10 seconds, I believe, but maybe it might need more time if hosts take forever to resolve.
In my experience, its usually not a non-existing domain names that take long to resolve (they usually get a NXDOMAIN answer quite quickly), but trying to connect to unreachable addresses or ports takes long, and also only when the connection request is silently dropped, but not when it is denied.
Roman
-
Dan Wilcox -
Roman Haefeli