ArtPollReply with more than 4 ports

[ljb2of3]

Hey all, I'm writing a virtual node implementation in Java to include in a larger project. I want it to be fully Art-Net II compliant so Unicast works correctly.

However, if I want more than four DMX inputs or outputs in my virtual node, how do I handle that when building my ArtPollReply packet? The spec only allows for a maximum of four ports.

For this project I need to have one DMX output and 40 DMX inputs in this virtual node.

One thought was to pretend to have one virtual node with one DMX output and four DMX inputs, and nine more nodes with four DMX inputs. But, this is all in one program on one computer with one IP address, so I don't think that is going to work.

Ideas anyone, or anybody see something in the spec that I'm missing?

Thanks,
Landy

[ljb2of3]

I just found the BindIP and BindIndex fields.

The fields aren't really explained, but I'm guessing they are to be used in cases like this. My theory is that each group of four ports can send their own ArtPollReply and increment the bind index field.

Anybody know if this is the intent of the fields and if so if other Art-Net devices take these fields in to account when calculating a unicast map?

[tbaarsch]

Please find the reply from Wayne Howell below:

Hi Landy,

Art-Net does limit you to a max of 4 input and 4 output dmx ports per IP address. This limit is built into ArtPollReply (as you say) but is also implicit in some of the other management packets. The historical reason for this is that I wanted the packet to be of fixed size so it could be statically cast in software terms. Keeping in mind our initial product platforms involved bit bashing data to a NIC from a small microcontroller, this was key to the efficiency of the protocol.

The solution is simply to use multiple IP addresses, one for each group of 4 ports. I’ve done this before on virtual devices and it can be handled fairly simply by multi-homing the NIC.

Re Binding IP. This is a relatively new field and the documentation has only just been updated. Key point is that your guess at its purpose is logical but wrong! It does not allow you to send multiple different ArtPollReplies from the same IP, that will definitely break thinks.

Its purpose is simply to allow different IP addresses to be logically bound to the same physical device. Example Below:

Say you have a product with 12 input ports.

You will need 3 IP addresses, let’s say 2.0.0.1, 2.0.0.10, 2.0.0.20

The ArtPollReplies from each will be:

Logical device 1:

My IP=2.0.0.1

BindingIP=2.0.0.1

BindIndex=0

Logical device 2:

My IP=2.0.0.10

BindingIP=2.0.0.1

BindIndex=1

Logical device 3:

My IP=2.0.0.20

BindingIP=2.0.0.1

BindIndex=2

By doing so, the network consumers know that 2.0.0.1 is the root device and that 2.0.0.10 and 2.0.0.20 are part of the same physical entity. We have recently implemented this hierarchy in DMX-Workshop such that multi-IP products now list in a logical hierarchy.

Conclusion:

a) You need an IP address per 4 ports.

b) Binding is for logical information, nothing more.

Regards

Wayne Howell

[bswinnen]

Hi Wayne

I was just going to implement this in our nodes.
I noticed that you used 6 filler bytes to achieve this however the remaining filler bytes went from 32 to 25 (this is 7). Is there somewhere else in the packet a byte change that I miss?
Or should the filler byte be 26 bytes long?
It looks like the packet length has changed and it is not compatible with earlier versions anymore? Please let me know where I'm wrong.

Kind regards
Bart Swinnen

[ljb2of3]

Wayne,

Thanks for the explanation, make sense, but isn't going to be easy... looks like I'm going to need 12 IP addresses to pull this project off. (It's a pixel mapper, hence the huge number of universes out of one box)

Thanks for the clarification though!

-Landy

[wayne@artisticlicence.com]

Hi Bart,

Thanks for spotting the error! Yes it should be 26. I'm updating the documents and the revised ones will upload overnight.

Cheers

Wayne

Hi Wayne

I was just going to implement this in our nodes.
I noticed that you used 6 filler bytes to achieve this however the remaining filler bytes went from 32 to 25 (this is 7). Is there somewhere else in the packet a byte change that I miss?
Or should the filler byte be 26 bytes long?
It looks like the packet length has changed and it is not compatible with earlier versions anymore? Please let me know where I'm wrong.

Kind regards
Bart Swinnen

[Preormillum]

As it gets harder and harder to get people to whip out there cards for porn, does it take less work to make more in mainstream?

[fokko]

Please find the reply from Wayne Howell below:

[SNIP]

Re Binding IP. This is a relatively new field and the documentation has only just been updated. Key point is that your guess at its purpose is logical but wrong! It does not allow you to send multiple different ArtPollReplies from the same IP, that will definitely break thinks.

[SNIP]

Conclusion:

a) You need an IP address per 4 ports.

b) Binding is for logical information, nothing more.

Regards

Wayne Howell



What will break, as this solution will break normal IP with DHCP, or every added IP must also use DHCP. Even then, it's not sure you will get a row of addresses.

It's surely complicate things on embedded servers with more then 4 universes. Multi-IP is not common on embedded systems, so for us no option.

Just limit to 4 universes?

Fokko van Duin

[tbaarsch]

Hi Fokko,

Wayne has replied the following:

My answer was not related to DHCP. It would break Art-Net as Art-Net devices are designed to expect a single ArtPollReply.

[fokko]

Hi Fokko,

Wayne has replied the following:

My answer was not related to DHCP. It would break Art-Net as Art-Net devices are designed to expect a single ArtPollReply.

Hello Wayne,

The way as it is now, with multi-ip, makes it not very attractive to design an embedded server for more then 4 universes for Art-Net. I don't know what the issue is with multi-Pollreplies, but using many IPs for one device is not really done anymore.

Maybe you can re-consider multi-PollReplies; it's so much simpler to implement, and no need for multi-IP ?

Regards,

Fokko van Duin

[tbaarsch]

Wayne Howell wrote the following:

Hi Fokki,

I agree that your idea is good in principle. However it would cause compatibility problems with all the equipment that has already been designed and sold by some 100 manufacturers world wide.