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>
To: pd-list@lists.iem.at
Subject: Re: [PD] UDP server with Pd
Message-ID: <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
danomatika.com
robotcowboy.com