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/