[Solved] UDP multicast messages without java?
Is there a way to transmit multicast messages with udpsend / udpreceive instead of using mxj net.maxhole on both ends?
Now that Jitter doesn't require JAVA I'm experimenting with ways to keep my standalones free of JAVA dependency.
Thanks - ZLP
not that i am aware of ... :(
I'm replying to my own post 4 yrs later!
Yes, it seems possible, thanks to some info gleaned from this thread:
https://cycling74.com/forums/maxhole-in-max-7
Short answer: Just send UDP packets to this IP: 255.255.255.255
Here is a patch (tested under Mac OS 10.13.6 High Sierra) that sends multicast UDP messages to all computers on the LAN that care to listen (very much like the old mxj net.maxhole technique). I received the messages on another Mac and several android phones (via UDP monitor app).
Hope it helps somebody!
-ZLP
Example patch below:
There is another, maybe better option than broadcasting to 255.255.255.255
because that might be blocked on some routers.
This is a simple patch that gets broadcasting address assigned by router.
Thanks Source Audio!
I've had good luck with the generic broadcast address but your method is elegant and seems like a safer way to do it. (plus it discovers your IP address too, which is handy.)
I grepped the ifconfig command to automatically select the currently active interface (since it may be en0, en1, etc).
Update to my example patch is below:
The reason I use call to specific interface to report is simply
because one can have several active network connections.
One can be on internet using ethernet, and communicate over USB wifi dongle
for UDP messaging...
In Your patch only the first interface in use will get reported.
I had once a setup of master computer and 250 client machines,
with very low traffic, but still very difficult to run without any lost packets.
Broadcasting only from master, and clients sending only to master using it's IP adress was the only possible way.
So I broadcasted master's ip on load for clients to know where to send data to.
This is good stuff! Thanks for sharing!
In my networked music performance system, apart from UDP, I also use the TCP protocol for data that 'must' arrive (UDP is faster but not so reliable). For that I use the [mxj net.tcp.send] and [mxj net.tcp.recv] objects. Maybe, I could replace them with [jit.net.send] and [jit.net.recv] in order to stop depending on Java, although I don't need to send matrices (only max messages).
Indeed, getting rid of Java would render things more practical regarding client installation!
But what is your opinion in terms performance gains or losses if I make the switch?
And, also, is this method (using the [shell] object) compatible with Windows?
shell works on windows, the syntax to get infos is different, have a look at ifconfig.
awk does not work on windows, You must use some other kind of extracting data from the shell output, but that is all possible.
In my particular case I was collecting data from the clients, I mean sending calls
to clients to send the data, then counted number of received messages, and requested not arrived messages again.
It was possible because every client had ID which ended as index in coll,
so I could easilly see if all messages arrived.
Using TCP was not possible with that large amount of linked computers.
UDP worked.
But again, it had nothing to do with music, and timing was not critical,
so I had enough time to re-request the lost data.
Thanks for the reply!
How many computers were you using?
I didn't know there could be problems with TCP and large number of connected computers...
As noted in previous post 1 Master and 250 client computers.
Sorry, I hadn't read that one (I was composing mine at the same time).
Yes, that's a lot of machines, indeed...
The maximum I've tried was with 14 client machines without problems. I hope to go up to 60 machines someday... do you think I'll be in trouble?
EDIT: I mainly use TCP to send data from server to clients.
My problem was also that I had to use combined wired and wireless
network.
If You can use wired ethernet it would give You much less trouble than wifi.
60 clients on good quality ethernet gear with well organised traffic should be no problem.