Client thread

[knoterich]

Opens from the server method.
Responsible for reading queues and sending to the cell and reading incoming messages from the cell and logging them.

[krameler]

Just to clarify:
With "logging" do you mean "writing them to a queue"?
I'm normaly connecting saving notices about program events/states to a log-file with the verb "logging" and in this project we also have the core-functionality of "logging" a constant stream of measurements. As this is might be a bit confusing in conversations i woudn't want it to have a third meaning.

[knoterich]

At the moment the client thread is handling the saving of the measurements by writing it to a file if en_log is set.
We can either just write them always to a queue and push the data to a database by a handler or directly push them from withing the clientThread.
I'd prefer the handler variant with the clientThread only pushing to the queue if datalogging (just a word do differentiate from pure logging) is enabled after pressing record.

[krameler]

At the moment the client thread is handling the saving of the measurements by writing it to a file if en_log is set.

I'm pretty sure handlerThread is currently the one writing mes. to a file if en_log.
Currently the clientThread is only acting as a stream between the client-specific queues and does some connection management. While the handlerThread evaluates the recieved messages(ack/blk/mes) for every client. In short: two different OSI-Layers.

We can either just write them always to a queue and push the data to a database by a handler or directly push them from withing the clientThread.
I'd prefer the handler variant with the clientThread only pushing to the queue if datalogging (just a word do differentiate from pure logging) is enabled after pressing record.

I don't see that there would be any interactivity between the different clients that would require a singleton to handle all clients. I would even say they are completly independent as they only meet where their data gets accumulated and maybe in some common user inputs e.g. the record button. So as they only have common input/output interfaces and as the processing merging handler feels like a huge bottleneck, i would maybe suggest to inflate the clientThread to include all the evaluating logic up to the I/O interfaces. Which would basically scrap the handlerThread.

[krameler]

Also i like the word "datalogging"

[knoterich]

You are right about the handler writing to the files, my bad.
The reason for a central handler to push data to the database was mainly to centralize database access.
We can do this in all the clientThreads independent from each other.
The maximum samplerate is 3,5kHz for the one with the custom analog frontend. With about 50 bytes per measurement we get 175kB/s per cell or 1,05MB/s with all 6 connected and firing at the full rate.
If you think this might cause a bottleneck go for the inflated clientThread.