Hi list,
I wanted to check if there are any new methods to get one's own ip from Pd - that is, so that a user doesn't go check the system settings. It would be necessary for all windows, macos and linux. Older messages talk about using [shell] in unix systems, and some hack with a batch file in windows. If this is still the current method, how would one activate a batch file in windows from inside pd?
As my knowledge of network isn't that good, just to check: to send a broadcast message for all peers in the same network, is the correct IP e.g. xxx.xxx.xxx.255? I read somewhere that 255.255.255.255 was also for broadcast, but since it's not working I imagine I read wrong.
Resuming: to send a broadcast message in the network, it's necessary to know the first 3 parts of one's IP?
And final question: besides netpd, are there any known public patches where users from several networks can connect to and send/receive data?
Best,
jmmmp
Hi,
I wanted to check if there are any new methods to get one's own ip from Pd
Are you talking about the local IP address or your public IP address?
I read somewhere that 255.255.255.255 was also for broadcast, but since it's not working I imagine I read wrong.
255.255.255.255 is indeed the broadcast address. What is not working? Which Pd version? Which network objects? Broadcast works just fine for me with [netsend -u] in Pd 0.51 on Windows 7.
Note that broadcast/multicast can only be used for local networks. Also, for p2p communication over the internet you need https://en.wikipedia.org/wiki/UDP_hole_punching.
And final question: besides netpd, are there any known public patches where users from several networks can connect to and send/receive data?
Are talking about local networks or the internet?
Shameless plug: The next (pre)release of "aoo" will allow sending arbitrary OSC messages over the internet. It has methods for sending messages to individual peers and also "broadcast" messages to all connected peers. Hopefully I manage to release it soon... It's way overdue :-/
Christof
On 22.01.2021 19:41, João Pais wrote:
Hi list,
I wanted to check if there are any new methods to get one's own ip from Pd - that is, so that a user doesn't go check the system settings. It would be necessary for all windows, macos and linux. Older messages talk about using [shell] in unix systems, and some hack with a batch file in windows. If this is still the current method, how would one activate a batch file in windows from inside pd?
As my knowledge of network isn't that good, just to check: to send a broadcast message for all peers in the same network, is the correct IP e.g. xxx.xxx.xxx.255? I read somewhere that 255.255.255.255 was also for broadcast, but since it's not working I imagine I read wrong.
Resuming: to send a broadcast message in the network, it's necessary to know the first 3 parts of one's IP?
And final question: besides netpd, are there any known public patches where users from several networks can connect to and send/receive data?
Best,
jmmmp
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi, I'm replying to both mails in one:
I wanted to check if there are any new methods to get one's own ip from Pd
Are you talking about the local IP address or your public IP address?
I'm trying first to implement this on local networks, so the first. But I would like later to also do this for any network connection, where the second will be necessary (I know this only from websites such as whatismyip).
I read somewhere that 255.255.255.255 was also for broadcast, but since it's not working I imagine I read wrong.
255.255.255.255 is indeed the broadcast address. What is not working? Which Pd version? Which network objects? Broadcast works just fine for me with [netsend -u] in Pd 0.51 on Windows 7.
Note that broadcast/multicast can only be used for local networks. Also, for p2p communication over the internet you need https://en.wikipedia.org/wiki/UDP_hole_punching.
I'll have a closer look, this is new to me. I did made performances with data transfer in pd (and max) in the internet some years ago, but haven't done this often or sistematically in a while.
Depends on the kind of subnet. If your netmask is 255.255.255.0, then yes. But networks can be of any size and depending on the size, the broadcast address of that network might be a different one. The IP- Address in a local network is divided in a network-prefix and host part. You see often addresses specified in CIDR notation, for example: 192.168.50.244/24. The '24' means that the first 24 bits of the address are the network prefix, and the remaining 8 bits is the host part. For getting the broadcast address of a given subnet, you set all bits of the host part to 1, which results in x.x.x.255 for a /24 network.
I think I would try to keep it safe and use ipv4 for now.
And final question: besides netpd, are there any known public patches where users from several networks can connect to and send/receive data?
Are talking about local networks or the internet?
First local, but later also internet.
Shameless plug: The next (pre)release of "aoo" will allow sending arbitrary OSC messages over the internet. It has methods for sending messages to individual peers and also "broadcast" messages to all connected peers. Hopefully I manage to release it soon... It's way overdue :-/
That is interesting. But unfortunately I'll also need to use this on mobiles, so I'm trying for a vanilla solution.
I've done some tests the last days, and here some more concrete information to who might be interested:
- I'm adding networking to my Click Tracker patch
(http://j.mp/click-tracker), and since it will be used by musicians who don't even know what Pd is, it would be comfortable to avoid them search for computer details when on a local network.
- there isn't much data to be sent: loading the scores (a text file) to
all users, and then basically a play/stop switch, velocity, etc.
- The purpose is to work on all OSs and android (the app version is
based on mobmuplat)
- I've done tests on my local network using 2 computers (W10, Pd 0.51.4,
wireless) and an android phone with mobmuplat. Sending from [oscformat]->[netsend -u -b] to [netreceive -u -b]->[oscparse]. The results are:
- both 255.255.255.255 and 192.168.178.255 work fine in all directions
- so does communicating with direct IPs (if I end up implementing this outside of local networks, I'll need to use this and prepare a system to manage users)
- 255.255.255.0 doesn't work, although that's my subnetmask. Pd's console shows the error "a socket operation related to an unavailable network" (translated loosely from German)
- strangely, one of the computers receives all messages 2x. Both when it's connected to wireless+lan, or also when only one of these.
- the phone can send lists such as "list /test", but floats (as both float or "/list $1") aren't sent. This isn't a problem when sending from the computers.
Any other suggestions/experiences regarding this context?
Best,
jmmmp
Hi João
On Fri, 2021-01-22 at 19:41 +0100, João Pais wrote:
I wanted to check if there are any new methods to get one's own ip from Pd - that is, so that a user doesn't go check the system settings.
I need that, too, and I can't wrap my head around figuring out how to do it. Using a [shell]-like solution would require different scripts for each platform. Also, "knowing" the IP address is not that trivial: A computer might have many physical network interfaces (ethernet and wlan) and a localhost interface and even has more when hosting virtual machines and VPN is configured, etc. I count 10 addresses on my laptop. So, which is the one you're interested in?
Usually, it's the other party (that you're connecting to) that knows. For a specific connection, the other party knows the address that is interesting in the context of that particular connection. In Pd vanilla, [netreceive] reports the source address for received data only for TCP connections, but not for UDP. iemnet's [udpreceive] will tell you the sender, though.
There is no deterministic way to define your own address. Depending on the destination, packets might be routed differently and thus the source address will be different. If you know the destination address, you could parse the routing table and deduce the (your) source address from it.
It would be necessary for all windows, macos and linux. Older messages talk about using [shell] in unix systems, and some hack with a batch file in windows. If this is still the current method, how would one activate a batch file in windows from inside pd?
As my knowledge of network isn't that good, just to check: to send a broadcast message for all peers in the same network, is the correct IP e.g. xxx.xxx.xxx.255?
Depends on the kind of subnet. If your netmask is 255.255.255.0, then yes. But networks can be of any size and depending on the size, the broadcast address of that network might be a different one. The IP- Address in a local network is divided in a network-prefix and host part. You see often addresses specified in CIDR notation, for example: 192.168.50.244/24. The '24' means that the first 24 bits of the address are the network prefix, and the remaining 8 bits is the host part. For getting the broadcast address of a given subnet, you set all bits of the host part to 1, which results in x.x.x.255 for a /24 network.
I read somewhere that 255.255.255.255 was also for broadcast, but since it's not working I imagine I read wrong.
It's the broadcast address of the 0.0.0.0/0 subnet, a.k.a the whole IPv4 internet. However, routers do not pass broadcast message from local network to the internet. But at my home, I can send messages to all my devices using this address.
Note: it works only with shoot-and-forget protocols like UDP, but not with connection-aware protocols like TCP.
Also, I'm not sure if all routers pass on such messages.
Resuming: to send a broadcast message in the network, it's necessary to know the first 3 parts of one's IP?
In my experience not. Just use 255.255.255.255
Roman
On Fri, 2021-01-22 at 22:52 +0100, Roman Haefeli wrote:
Hi João
On Fri, 2021-01-22 at 19:41 +0100, João Pais wrote:
I wanted to check if there are any new methods to get one's own ip from Pd - that is, so that a user doesn't go check the system settings.
I need that, too, and I can't wrap my head around figuring out how to do it.
Oh, my... João just pointed me to an old thread [1] about the same topic. The thread ended into iemnet adding support for reporting local address for [tcpclient] and [udpclient]. That is exactly what I need.
About the long sermon from my previous mail: It's only hard to know _before_ you connect. When connected, it's quite clear.
@João, if you're using iemnet's [udpclient] or [tcpclient], use the fourth outlet and [route local_address].
Roman
[1] https://lists.puredata.info/pipermail/pd-list/2017-12/121209.html
[netreceive] reports the source address for received data only for TCP connections, but not for UDP
[netreceive -u -f] works just fine for me on Pd 0.51 ;-)
Christof
On 22.01.2021 22:52, Roman Haefeli wrote:
Hi João
On Fri, 2021-01-22 at 19:41 +0100, João Pais wrote:
I wanted to check if there are any new methods to get one's own ip from Pd - that is, so that a user doesn't go check the system settings.
I need that, too, and I can't wrap my head around figuring out how to do it. Using a [shell]-like solution would require different scripts for each platform. Also, "knowing" the IP address is not that trivial: A computer might have many physical network interfaces (ethernet and wlan) and a localhost interface and even has more when hosting virtual machines and VPN is configured, etc. I count 10 addresses on my laptop. So, which is the one you're interested in?
Usually, it's the other party (that you're connecting to) that knows. For a specific connection, the other party knows the address that is interesting in the context of that particular connection. In Pd vanilla, [netreceive] reports the source address for received data only for TCP connections, but not for UDP. iemnet's [udpreceive] will tell you the sender, though.
There is no deterministic way to define your own address. Depending on the destination, packets might be routed differently and thus the source address will be different. If you know the destination address, you could parse the routing table and deduce the (your) source address from it.
It would be necessary for all windows, macos and linux. Older messages talk about using [shell] in unix systems, and some hack with a batch file in windows. If this is still the current method, how would one activate a batch file in windows from inside pd?
As my knowledge of network isn't that good, just to check: to send a broadcast message for all peers in the same network, is the correct IP e.g. xxx.xxx.xxx.255?
Depends on the kind of subnet. If your netmask is 255.255.255.0, then yes. But networks can be of any size and depending on the size, the broadcast address of that network might be a different one. The IP- Address in a local network is divided in a network-prefix and host part. You see often addresses specified in CIDR notation, for example: 192.168.50.244/24. The '24' means that the first 24 bits of the address are the network prefix, and the remaining 8 bits is the host part. For getting the broadcast address of a given subnet, you set all bits of the host part to 1, which results in x.x.x.255 for a /24 network.
I read somewhere that 255.255.255.255 was also for broadcast, but since it's not working I imagine I read wrong.
It's the broadcast address of the 0.0.0.0/0 subnet, a.k.a the whole IPv4 internet. However, routers do not pass broadcast message from local network to the internet. But at my home, I can send messages to all my devices using this address.
Note: it works only with shoot-and-forget protocols like UDP, but not with connection-aware protocols like TCP.
Also, I'm not sure if all routers pass on such messages.
Resuming: to send a broadcast message in the network, it's necessary to know the first 3 parts of one's IP?
In my experience not. Just use 255.255.255.255
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Christof Ressi -
João Pais -
Roman Haefeli