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-requ...@lists.iem.at wrote: > > Message: 3 > Date: Thu, 03 Jun 2021 14:52:07 +0200 > From: Roman Haefeli <reduz...@gmail.com <mailto:reduz...@gmail.com>> > To: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> > Subject: Re: [PD] UDP server with Pd > Message-ID: <d588131641f4e973e59201abc884fc5191cb0e6c.ca...@gmail.com > <mailto:d588131641f4e973e59201abc884fc5191cb0e6c.ca...@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/>
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
