[PD] UDP server with Pd

Christof Ressi info at christofressi.com
Mon Jun 7 22:02:51 CEST 2021


> The only problem I see with it is that while the socket is connected
> for a send, it won't receive anything.
Why is that? This shouldn't happen.

BTW, you don't actually have to call connect(), instead you could just 
save the sockaddr and use sendto(). Consequently you could also rename 
the [connect( method to something else, e.g. [set <host> <port>( or 
[client <host> <port>(, etc. After all, a server doesn't *connect* to a 
client...

Christof

On 07.06.2021 21:34, Martin Peach wrote:
> OK, I have implemented something that might work: [udpsrvr] can listen
> on a port and send to an address using the same or a different port.
> The only problem I see with it is that while the socket is connected
> for a send, it won't receive anything. I overcome this partly by
> sending the connect/send/disconnect sequence in one comma-delimited
> message.
> The code is at
> https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/mrpeach/net/udpsrvr.c
>
> Martin
>
> On Mon, Jun 7, 2021 at 3:48 AM Roman Haefeli <reduzent at gmail.com> wrote:
>> On Sun, 2021-06-06 at 20:26 -0400, Martin Peach wrote:
>>>
>>> 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.
>>
>> Again, this does not work. The socket on the client side will only
>> accept packets originating from the port it has sent packets to, but
>> [udpsend] on the server cannot use this port as bind port, because it
>> is already occupied by [udpreceive]. To put this into telephone
>> analogy: When you call someone, you expect a third party to be
>> prohibited from shouting into your call, and you expect to hear only
>> the party you called.
>>
>> The only solution to this is to use the same socket for both sending
>> and receiving, as Christof already suggested.
>>
>> 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





More information about the Pd-list mailing list