IMO, those are just silly workarounds. When I send a packet from A to B, I would expect to get a reply from B and not some random socket C.
What we actually need is a UDP networking object that can independently
listen for packets on a given port
send packets to any destination
There is no reason why we would need two seperate objects for this. A UDP socket is perfectly capable of doing both at the same time.
Christof
On 07.06.2021 02:26, Martin Peach wrote:
On Sat, Jun 5, 2021 at 3:31 AM Roman Haefeli reduzent@gmail.com wrote:
On Fri, 2021-06-04 at 19:09 -0400, Martin Peach wrote:
On Fri, Jun 4, 2021 at 6:16 PM Roman Haefeli reduzent@gmail.com wrote:
On Fri, 2021-06-04 at 23:27 +0200, Christof Ressi wrote:
Instead of waiting for https://github.com/pure-data/pure-data/issues/949
- which will probably take months -,
I am exploring stuff, partly out of curiousity. There is no expectation of anything to happen in certain time.
you could make a feature request to iemnet ;-)
I just did: https://git.iem.at/pd/iemnet/-/issues/7
Or you could copy the code from mrpeach/udpsndrcv into your own external.
To me, [mrpeach/udpsndrcv] looks more similar to [iemnet/udpclient] than to [iemnet/udpserver]. Both, [mrpeach/udpsndrc] and [iemnet/udpclient] require the bind port to be closed before creating a new connection. [udpserver] would (ideally) keep the bind port open at any time and still be able to set an address (destination address and port) for sending.
If you have a [udpreceive 9898] as your 'server' it will receive from anywhere on port 9898. So you can take the sender's ip and port from the latest incoming message (route 'from' at the second outlet) and use them to set the address and port of a single [udpsend] for the reply. There is no connection in udp so you need to add metadata in your datagrams for routing and so forth. Martin
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list