(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 reduzent@gmail.com 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
On Wed, Jun 2, 2021 at 9:58 AM Roman Haefeli reduzent@gmail.com wrote:
(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 reduzent@gmail.com 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).
You're correct. I thought I had fixed that a few years back but I guess I hadn't. You could still have the server reply to the source port plus one, or something like that, Usually I have the client include its replyto port in a message.
Martin
So, I believe my goal can (so far) only be achieved with [netsend -u]/[netreice -u] as Miller suggested. Mission accomplished.
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 02.06.2021 16:55, Martin Peach wrote:
On Wed, Jun 2, 2021 at 9:58 AM Roman Haefeli reduzent@gmail.com wrote:
(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 reduzent@gmail.com 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).
You're correct. I thought I had fixed that a few years back but I guess I hadn't. You could still have the server reply to the source port plus one, or something like that,
This doesn't solve anything regarding firewall + NAT.
Usually I have the client include its replyto port in a message.
But why? UDP sockets are already bidirectional. If you need to receive replies from the other end, just use the appropriate object, i.e. [iemnet/udpclient] or [netsend -u -b].
EDIT: I just saw your mail about [mrpeach/udpsndrcv] which probably achieves the same thing.
<rant> There is some persistent misunderstanding that UDP sockets can only be used in one direction. I think one reason is that many creative coding environments only provide very basic and limited networking objects, so users without a background in network programming think that's the way it should be done. In the "real world", a UDP server would simply send the reply to the source IP address + port obtained with recvfrom() while a TCP server would send its message to the client socket it received the message from. It's ironic that Pd doesn't provide an easy way for such a common task... </rant>
I just remembered that I already opened an issue: https://github.com/pure-data/pure-data/issues/949. Maybe it's time to also make a PR :-)
Martin
So, I believe my goal can (so far) only be achieved with [netsend -u]/[netreice -u] as Miller suggested. Mission accomplished.
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Wed, Jun 2, 2021 at 12:09 PM Christof Ressi info@christofressi.com wrote:
On 02.06.2021 16:55, Martin Peach wrote:
On Wed, Jun 2, 2021 at 9:58 AM Roman Haefeli reduzent@gmail.com wrote:
You could still have the server reply to the source port plus one, or something like that,
This doesn't solve anything regarding firewall + NAT.
What is/are the issue{s} with firewall + NAT? Asking because I never used either, I only ever use them on a LAN.
Usually I have the client include its replyto port in a message.
But why? UDP sockets are already bidirectional. If you need to receive replies from the other end, just use the appropriate object, i.e. [iemnet/udpclient] or [netsend -u -b].
So the client can dictate which port it wants to listen on.
<rant> There is some persistent misunderstanding that UDP sockets can only be used in one direction. I think one reason is that many creative coding environments only provide very basic and limited networking objects, so users without a background in network programming think that's the way it should be done. In the "real world", a UDP server would simply send the reply to the source IP address + port obtained with recvfrom() while a TCP server would send its message to the client socket it received the message from. It's ironic that Pd doesn't provide an easy way for such a common task... </rant>
I think as far as the Pd net objects (netsend] and [netreceive] go, it's because they were conceptually based on Pd's [send] and [receive]. I mutated [netsend] and [netreceive] into [udpsend] and [udpreceive] in order to be able to pass raw bytes instead of FUDI messages, so that the [packOSC] and [unpackOSC] objects could work with them. The more recent [udpsndrcv] is more aligned with [comport] in being bidirectional. The main persistent misunderstanding I find with UDP is the connection -- it doesn't exist. Hitting [connect( doesn't do anything on the network, it only sets the address for subsequent sends. So sending the first datagram after 'connecting' may take longer as the OS may need to find the route to that address on the network by sending other packets.
Martin
On Wed, 2021-06-02 at 17:29 -0400, Martin Peach wrote:
What is/are the issue{s} with firewall + NAT? Asking because I never used either, I only ever use them on a LAN.
From what I know, NAT firewalls forward packets coming back from a public server only when previously a matching packet was sent from the client behind the firewall. They remember src and dst address of the outgoing packets and forward packets from the server (with reverse src and dst address) back to the client. If the client doesn't send anything for a certain while, the firewall "forgets" about the "connection".
Client sends packet: UDP(src:(192.168.1.33:55444) dst:(195.176.247.12:3025))
Firewall translates this to: UDP(src:(81.4.3.1:55444) dst:(195.176.247.12:3025))
Server responds: UDP(src:(195.176.247.12:3025) dst:(81.4.3.1:55444))
Firewall looks it up in its translation table and forwards it to the local client: UDP(src:(195.176.247.12:3025) dst:(192.168.1.33:55444))
If the server uses a different src address (for instance, different port), the firewall simply discards the packet because it doesn't match anything in its lookup table.
Also, some firewall also translate the port number. Many try to keep the port number, but that's not always possible, if - for example - two different local clients use the same bind port for a connection to the same destination address.
Roman
OK, I found it now...The object is [udpsndrcv] in mrpeach. It allows you to set the source and destination ports and send and receive on them.
Martin
On Wed, Jun 2, 2021 at 9:58 AM Roman Haefeli reduzent@gmail.com wrote:
(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 reduzent@gmail.com 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 _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Christof Ressi -
Martin Peach -
Roman Haefeli