It is currently 22 Jun 2017, 19:35



Serializing commands to the server

CasparCG Server, Client and development

Moderators: Macey, Jonas Hummelstrand, didikunz

Serializing commands to the server

Postby zbang » 25 Apr 2017, 02:18

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!
zbang
 
Posts: 44
Joined: 10 Apr 2015, 02:09

Re: Serializing commands to the server

Postby Jesper Stærkær » 25 Apr 2017, 07:29

And this was exactly my problem leading up to Helge implementing the new REQ/RES protocol in 2.1, which solved your problen. Append an ID on REQ and have it back on RES. Fully async ftw!
Jesper Stærkær
Independent Consultant at SuperFly.tv
User avatar
Jesper Stærkær
 
Posts: 853
Joined: 13 Apr 2010, 18:06
Location: Trondheim, Norway

Re: Serializing commands to the server

Postby ASmith3006 » 25 Apr 2017, 14:17

Jesper, that sound great. Where can I find more details on this, please?

Thanks
ASmith3006
 
Posts: 66
Joined: 12 Dec 2013, 14:47

Re: Serializing commands to the server

Postby zbang » 25 Apr 2017, 17:44

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!
zbang
 
Posts: 44
Joined: 10 Apr 2015, 02:09

Re: Serializing commands to the server

Postby mcdikki » 30 Apr 2017, 12:34

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
User avatar
mcdikki
 
Posts: 1059
Joined: 11 Dec 2012, 15:48
Location: Germany

Re: Serializing commands to the server

Postby zbang » 30 Apr 2017, 17:30

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!
zbang
 
Posts: 44
Joined: 10 Apr 2015, 02:09


Return to Tech and Development

Who is online

Users browsing this forum: Google [Bot] and 5 guests