Serializing commands to the server

#1
Hello,

Maybe this is more of a programming style question that a caspar-specific one--

Given that most clients will have a single persistent TCP connection to the caspar sever, and that some commands take more time (and may produce more results) than others, what techniques are commonly used for serializing the commands?

In most cases, I doubt that there is much of a contention issue. But if you have, say, one entity updating a clock, another periodically changing a background, another changing a template or other data, and maybe another occasionally getting INFO or doing an LS command, without interlocks there is the small but non-zero possibility that one command could be sent while the previous response is still arriving (or that the client gets the statuses out of order).

Implement a command queue and have a single thread service that?
Use a mutex and wait for it?
Something else?

My application is a playout server and really has a low command load, but the perfectionist (and SQA engineer) in me says that without interlocks there's still the possibility of command collusion. (IIRC a PLAY cmd can take 100s of ms to return the status, and that's a long time :).)

Thanks,

z!

Re: Serializing commands to the server

#4
Thanks Jesper, I'll look into that. Does it prevent things like interleaved responses? The client would still have to maintain some data of which requests were sent, pending, or complete.

I guess I'm more concerned about sending one command while the previous one is still processing and how to handle that in the client. Since this -shouldn't- happen much at all, perhaps a simple mutex would suffice.

(BTW, RES/REQ is not yet in the AMCP 2.1 wiki page, so look to the source code for documentation.)

Later,

z!

Re: Serializing commands to the server

#5
I'll use a own connection library that allows only one command at a time by waiting for the response of this command. It's not thread safe (at least not by intension) but for single threaded clients this works just fine.

I used to implement it this way just because of the problems you pointed out. The RES/REQ is great and was a very old feature request I started 2014/15 or so.

So, for now a mutex or any other mechanism that makes sure only one command is on the tcp connection should do well.

cheers
mcdikki
sublan.tv - Wir teilen Begeisterung

Re: Serializing commands to the server

#6
Thanks, mcdikki, just wanted to see if it was missing something obvious.

Currently, my main application is event-driven tcl, so it's single-threaded, but it's still possible for a command send event to arrive before the previous response ready event does. I've covered most of that already, just need to implement a more formal mutex. And look at RES/REQ.

z!