[PD] receive UDP message from 224.0.0.1

[Christof Ressi]

> I don't use SC, but I'll check anyway if some years ago I installed it 
> and then forgot about it.
Ok, then this was a red herring. That's a pretty strange coincidence, 
though. Anyway, sclang.exe must not only be installed, but also *running*.

However, you can check if some other program already uses port 57120! On 
Windows you can do this by running "netstat -abno" in cmd.exe as Admin.

Also, have you tried with other port numbers?

Christof

On 11.01.2024 10:34, João Pais wrote:
> I don't use SC, but I'll check anyway if some years ago I installed it 
> and then forgot about it.
>
> It is a multicast address - I might be able to change it to the normal 
> broadcast address, but I wouldn't count on it. So for now, it's better 
> to assume that this can't be changed.
>
>     Hmmm... 57120 happens to be the default port of sclang (the
>     SuperCollider language interpreter). Could it be that sclang(.exe)
>     is running? Check the task manager to be sure.
>
>     Explanation: Generally, only one application can listen to a port
>     at a time. Normally, applications will just refuse to bind to
>     ports that are already taken. However, Pd sets the SO_REUSEADDR
>     socket option, which allows to bind to an existing port.
>
>     This is needed for TCP sockets, because they typically "linger"
>     for a while after you close them. If you close and immediately
>     reopen a patch, [netreceive] would refuse to bind.
>
>     However, we probably should /not/ set SO_REUSEADDR for UDP sockets
>     because it doesn't do anything useful. On the contrary, it just
>     causes confusion because [netreceive -u] does not post an error if
>     the port is already taken.
>
>     Christof
>
>     On 10.01.2024 23:08, João Pais wrote:
>>     Hi everyone,
>>
>>     I'm trying to receive some UDP data from a mobile device into Pd.
>>     The data arrives in the computer (windows or ubuntu), here is a
>>     description from wireshark:
>>
>>     Frame 173: 90 bytes on wire (720 bits), 90 bytes captured (720
>>     bits) on interface
>>     \Device\NPF_{2ADD2685-ACB9-4C51-B708-F1F62FAE86C7}, id 0
>>     Ethernet II, Src: XiaomiCommun_1d:0e:fd (4c:e0:db:1d:0e:fd), Dst:
>>     IPv4mcast_01 (01:00:5e:00:00:01)
>>     Internet Protocol Version 4, Src: 192.168.178.34, Dst: 224.0.0.1
>>     User Datagram Protocol, Src Port: 43641, Dst Port: 57120
>>     Data (48 bytes)
>>
>>
>>     But with [netreceive -u -b 57120] (or any other options to
>>     netreceive) no data comes into Pd. Does anyone have any
>>     suggestion on how to receive the data?
>>
>>     When is sent to 224.0.0.1, the data gets into the computer but
>>     not into Pd. But if other udp data is sent to the broadcast ip
>>     (192.168.178.255) from the same device, it does get also into Pd.
>>
>>     Frame 31: 66 bytes on wire (528 bits), 66 bytes captured (528
>>     bits) on interface
>>     \Device\NPF_{2ADD2685-ACB9-4C51-B708-F1F62FAE86C7}, id 0
>>     Ethernet II, Src: XiaomiCommun_1d:0e:fd (4c:e0:db:1d:0e:fd), Dst:
>>     Broadcast (ff:ff:ff:ff:ff:ff)
>>     Internet Protocol Version 4, Src: 192.168.178.34, Dst:
>>     192.168.178.255
>>     User Datagram Protocol, Src Port: 42797, Dst Port: 57120
>>     Data (24 bytes)
>>
>>     Best,
>>
>>     Joao
>>
>>
>>
>>
>>     _______________________________________________
>>     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
>
>
> _______________________________________________
> Pd-list at lists.iem.at  mailing list
> UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20240111/553f6068/attachment.htm>