Thunderlaser UDP code: test for busy condition

[jnweiger]

I've made several torture tests with the current state of the art implementation in https://github.com/jnweiger/ruida-laser/blob/master/udpsendruida.py

• It is not possible to break a transmission by adding delays in between chunks. Tested with up to 4 seconds sleep per chunk.
• Files can be uploaded while a laser job is running. No busy condition seen.
• tmpfile uploads that would start automatically are not started and do not interrupt a laser job when uploading while a laser job is running.

There is however a race condition:

• If two machines send simultaneously, so that the chunks arrive interleaved at the laser, one corrupt file (containing a mix) gets uploaded.

[jnweiger]

@kkaempf @mrlinux1, we should try to reproduce the race condition using udpsendruida.py (with sufficient chunk delay) and the original rdworks firing a second upload while the first one is in progress. And see if rdworks checks for another upload alread in progress.

With two (slow) udpsendruida.py I can reproduce the following situation: Sender A sends file 'dolly.rd' in 30 chunks with a 1 second delay between each. Sender B starts 10 seconds later and and sends file 'kringel.rd' in 5 chunks with a 3 second delay between chunks.

The sequence seen on the network is approximately:

A A A A A A A A A A B A A A B A A B A A A B A A A B A A A A A A A A A

The lasercutter shows the name 'dolly' in the display after the last chunk from B is received. This is indicates a premature end of the first upload. The trailing chunks from A seem to be ignored. Afterwards a file 'dolly' is in the file list, but not file 'kringel'.

The file 'dolly' contains a mix of both, and is incomplete.

[jnweiger]

File 'dolly.rd' if transfered correctly:

File 'kringel.rd' if transfered correctly:

File 'dolly.rd' with simultanesous upload of 'kringel.rd' as described above:

Photo with highlights added indicating the sequence of zerhackstückelt Text:

[kkaempf]

:rofl: