[PD] UDP server with Pd

[Christof Ressi]

On 02.06.2021 16:55, Martin Peach wrote:

> On Wed, Jun 2, 2021 at 9:58 AM Roman Haefeli <reduzent at 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 at 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 at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list