Issues with ArtNetClient Sequence IDs

[simon-kollision]

The ArtNetClient class multiple issues related to its sequenceId field.

1. According to the ArtDmx packet specification (as seen here) the sequence field should either be:
   a) a constant 0 (to indicate that the field is not used) or
   b) an incrementing value between (and including) 1 and 255.

   Currently, the field varies between 0 and 255 (both included), which would seem to be an inappropriate combination of both options.

2. Perhaps more importantly (but also more complicated to patch), the sequence field should be unique for each Port-Address (which apparently is defined as Net+Sub-Net+Universe).

   Right now, the field is incremented for each DMX package without regards for the receiver of the package. This leads to issues in a setup with multiple receivers and multiple universes, where a single receiver might get packages with sequence IDs such as 1, 2, 52, 53, 103, 105 and so on.

We recently experienced this issue using 5 hardware Art-Net to DMX converters. The converters would choke on the packages since they appeared to be out-of-order and the framerate would drop from the expected 30 FPS to something closer to 5 FPS.
We fixed this by patching the void unicastDmx(String address, int subnet, int universe, byte[] dmxData) method so that it uses a sequence ID which is unique for the given address (by means of a Hashmap<String, Integer>). Our setup now runs a 30 FPS.

While this solved our specific issue, after rereading the specification it seems like my solution is not compliant either so I won't provide a pull-request (and also, I haven't fixed this issue for the other, related, methods of the class).

[cansik]

Hi Simon, thank you for the comment about this issue. Yes, the ArtNetClient is not following the standard as it did not seem relevant so far, but your case is showing that some implementations may depend on it. I am not actively developing the artnet4j library anymore, so if you already spent some time to implement a solution (at least for one method), I would be happy to merge it. Extending it to the other methods could be done later as well or it could at least be a starting point for someone to implement a fully compliant solution.

Basically as I understand you correctly, the solution would be to:

• Create a function to calculate the hashcode of Port-Address (Net+Sub-Net+Universe)
• Create a HashMap<Int, Int>
• For each method (broadcast & unicast)
  • calculate the hash for the current Port-Address
  • update the value: hashMap[portAddressHash] = max((hashMap[portAddressHash] + 1) % 256, 1)

Is that right?

Or the simple solution: set the value just to 0 and tell receiving clients that this is not used.