[PD] UDP server with Pd

[Martin Peach]

On Wed, Jun 2, 2021 at 12:09 PM Christof Ressi <info at christofressi.com> wrote:
>
> 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:

> > 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