I hope I’m not butting in where I have no business, but I’d like to mention that Ross Bencina’s ‘OSCGroups’ (http://www.rossbencina.com/code/oscgroups) does an excellent job of handling group formation, broadcast and NAT tunneling. Our group has been using it for over fifteen years, and it’s as solid as a rock. It may not be Pd-native, but it does the job extremely well.
Best,
Phil Stone Davis, CA
From: Christof Ressi info@christofressi.com To: Pd-List pd-list@lists.iem.at Subject: Re: [PD] UDP server with Pd Message-ID: 06b68c67-a27e-81d8-4b6e-5b60db9436c5@christofressi.com Content-Type: text/plain; charset="utf-8"; Format="flowed"
If you want the server to reply only to the current client, [iemnet/udpserver] actually works fine (despite the error message in the console): the list method will send the packet to the source address of the most recently received packet.
However, if you need to send packets to several/all registered clients, e.g. like a game server, this doesn't work (yet).
Christof
On 02.06.2021 08:54, Roman Haefeli wrote:
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.
That absolutely works. And since that can be done in zero logical time, [netsend] doesn't claim any packets coming in on the port "shared" with [netreceive]. Cheers to Pd's determinism!
That opens up an a lot of new things to explore for me. Thanks!
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list