search

mcallegari / qlcplus

Q Light Controller Plus (QLC+) is a free and cross-platform software to control DMX or analog lighting systems like moving heads, dimmers, scanners etc. This project is a fork of the great QLC project written by Heikki Junnila that aims to continue the QLC development and to introduce new features.
Apache License 2.0
1.02k stars 360 forks source link

Add Unicast Artnet Output support #179

Closed alexit84 closed 9 years ago

alexit84 commented 11 years ago

I'd like to have unicast support in Artnet output plugins (as ArtNet II standard says)

Specifying an output IP address could lower network load.

Thank you!

mcallegari commented 11 years ago

Since you read the ArtNet specifications, do you know what is the difference between broadcast and unicast for ArtNet ? How did you end up saying it would reduce the network load ?

alexit84 commented 11 years ago

As I read artnet packets are broadcasted to all nodes. Every nodes listen all packets and accepts only the one which is configured to listen for this universe. Since I use a very small powerful client (a Raspberry Pi running OLA) I think it can lead to a loss in performance (as experienced with other artnet servers) since the "selection" is made client-side. Tell me if I'm wrong, maybe I'm misinterpreting it.

mcallegari commented 11 years ago

As far as I know from what I read, using unicast with ArtNet is useful only when performing direct communication with one or few nodes. So, for example, if you have one ArtNet moving head with 10 channels, ArtNet will transmit only one packet with 10 values at every DMX universe cycle. Also, if I remember, unicast can be TCP (while broadcast is UDP), so there is no risk of packet loss.

Now, if you're using the Pi as a fixture it can be considered, but if you use the Pi to control 20-30 fixtures or as a reflector, then I guess unicast won't save that much of bandwith and CPU. For 512 channels we're talking about 250Kbit/s...nothing that a modern device can't handle.

alexit84 commented 11 years ago

Yes, I'm using the Pi as a single OLA node driving 2 universes of led pixels (and maybe other fixtures in future). Anyway I've not yet fully tested it in this scenario. I will tell you my results in the near future...

kripton commented 11 years ago

Am 20.10.2013 18:00, schrieb Massimo Callegari:

As far as I know from what I read, using unicast with ArtNet is useful only when performing direct communication with one or few nodes. So, for example, if you have one ArtNet moving head with 10 channels, ArtNet will transmit only one packet with 10 values at every DMX universe cycle. Also, if I remember, unicast can be TCP (while broadcast is UDP), so there is no risk of packet loss.

Unicast vs. Multicast really depends on the situation you are using it in.

When you use ArtNet to replace a system close to conventional DMX (one sender, multiple fixtures listening to and parsing the same date), multicast uses less ressources since the data is only sent once over the network. The sender doesn't need a single (TCP) connection per fixture/receiver. That makes error handling easier (since there is none) but the sudden loss of one fixture is not detectable by the sender.

Multicast has its disadvantages when a large, switched network structure is used since all multicast packages are sent to all ports of a switch. Thus, the traffic is copied multiple times and needlessly when the data is not used by receivers on a port of a switch. In that case, the receivers need to do more filtering work. When using WiFi, multiple connections with smaller data packets (unicast) usually have greater latency than fewer connections with larger data packets (multicasts) since the shared medium (air) needs some time of silence for a packet to be sent. And of course in case of packet loss, the TCP retransmission takes some time.

Just my 2 cents :) Jannis

mcallegari commented 11 years ago

Kripton, multicast is another thing. Here we're talking about broadcast and unicast. I work on IPTV technologies since 12 years and I assure you I know the difference :)

On a multicast network, clients must join the desired address (or channel) by a specific IGMP join request. Therefore you also need network switches with the IGMP capability. And also multicast is perfect for large switched networks. Nothing related to ArtNet though.

Broadcast packets, instead, are replicated by any low cost network device. Even on WiFi most of the times.

kripton commented 11 years ago

Hi,

Am 21.10.2013 23:04, schrieb Massimo Callegari:

Kripton, multicast is another thing. Here we're talking about broadcast and unicast. I work on IPTV technologies since 12 years and I assure you I know the difference :)

On a multicast network, clients must join the desired subnet by a specific IGMP join request. Therefore you also need network switches with the IGMP capability. Nothing related to ArtNet though.

Broadcast, instead are replicated by any low cost network device. Even on WiFi most of the times.

yep, you're right there, I don't seem to have read carefully enough. I just had OLA in mind that defaults to broadcast. At least it starts sending network traffic as soon as I patch an universe to ArtNet and my other "wireless DMX" nodes don't need to join a multicast-group and are able to process all data without any further ado. So I just assumed ArtNet is either Unicast or Broadcast. One just never learns out on those topics :)

(By the way: funny that I used email to respond to the topic when I usually use the github web interface. I just thought this was just another mailing list)

lynxis commented 10 years ago

maybe you can take a look at this (outdated and hacky) qlc plugin. https://github.com/lynxis/qlc-plugin-artnetout

btw. multicast traffic is handled by the most wireless APs as broadcast traffic on the lowest (1mbit) wireless rate.

mcallegari commented 9 years ago

Finally this has been implemented, as a unicast representation of a universe (not fixture-based)

Closing at last.