(replying to list as - I believe - you intended to) On Wed, 2021-06-02 at 09:34 -0400, Martin Peach wrote: > On Wed, Jun 2, 2021 at 3:31 AM Roman Haefeli <[email protected]> > wrote: > > On Tue, 2021-06-01 at 19:19 -0400, Martin Peach wrote: > > > A [udpsend] normally has a different port number to the one it > > > sends > > > to, but a [udpreceive] in the same Pd process can still receive > > > on > > > that port. > > > > My understanding is that a client won't accept messages with a > > different source port than it has sent to. Also, such packets > > wouldn't > > be able to traverse NAT firewalls. > > > > A udp packet almost always has a different source port from its > destination. It's not the same as TCP as there is no real > "connection" > established or maintained, it's just fire and forget. I modified the > udp objects in response to a request to do just that: send back to > the > same port.
You're absolutely right. I think my wording was not clear. Sorry for that. When a client with bind port 52333 sends a packet to the server listening on port 5000, it won't accept response packets from the server with (matching) destination port 52333 and (different) source port 5001. [udpsend] on the server side cannot use bind_port=5000, because it is already used by [udpreceive]. And from what I see in the documentation, [udpsend] doesn't support setting a bind port, it seems to pick a random one (which is the normal thing to do when acting as a client, but not sufficient for a server response to a client request). So, I believe my goal can (so far) only be achieved with [netsend -u]/[netreice -u] as Miller suggested. Mission accomplished. Roman
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
