What do you mean by SDK and protocol for VDI systems
what sort of driver is it?
so it's a driver in that it's loaded as a module which gets used by Citrix
if you've ever worked with Citrix or with the Citrix Xenapp Virtual Drivers
the Citrix Workspace or Citrix Virtual Channel SDK
also the Citrix Workstation
so the Citrix Workstation is on the client side
which, thus far, we've had a targer which is a windows environment
The Citrix pattern is a solution for controlling a remote workstation
Generally other solutions like a remote desktop interface or application are well let's think of a few of them
there is reminmmma
there are the VNC type clients
there are some variations of those, such as solutions created in Go
I haven't used all of them, I'v egenerally loathed using any sort of remote desktop solution because they're sluggish, and I've never had to rely on one
generally if I need to do anything remote, I prefer to use ssh and some sort of a text based session where I can do the specific things that I need without having to think about a graphical user experience
but as far as remote desktops rae concerned, Citrix seems to be the most fluid, performant, responsive, comprehensive that I've tried
that said, i've also seen plenty of flaws in the documentation and in the example code that we're given
I mean thigns work, but the documentation was not so great in the sense that it's written in a very confusing way
which suggests that either  it's written by a developer who isn't very good at technical writing
or is perhaps not very experienced in doing it
or it's written by someone who does technical writing, but isn't a defveloper or an engineer
and in this sense it can be a bit frustrating, because the terms they choose to represent things are ambiguous and inconsistent, sometimes alluding to the possibility that they could be referring to multiple things
causing you to question the progression of working through the components of the tutorial or setting up the examples
that being said, it all worked in the end
it seems that the software is fairly good, and that though there have been some issuesdsiscovered over the years, everthing appears to be gettting resolved eventually
there are even capabilities which we haven't had to wory about, that we've entertained at least having to support in our work, such as the feature of being able to use up to 8 simultaneous monitors for one desktop environment
that's pretty insane, i can't think of anyone who's had to do that, especially not for a remote session
but nevertheless, we made sure we could support several in our testing, using different measurements on each etc..
so in essence it' sa driver which is a module loaded by the Citrix Workspace, previously Citrix Xenapp, and it provides the means of leveraging a session lifecycle with their citrix technology
the way this work si sby registering a virtual channel
a wire to write and read from
you register your virtual channel, and get a pointer to a C functiointerface
and you write your data on a single thread and have it come out on the other side made available through another Citrix API where you can register another set of functions for use in the other environment
we made this into a library which interfaces with Node JS, allowing you to regisjAvascript functions and import them into a NodeJS application
the goal here was to make an SDK that javascript developers could use to wriet tent applications which are split as two applications in each system environment
so you have a client side application which the user interacts with, such as a messaging or telecommunication program
our use case was video calling application which makes use of the other SDKs provided by our company which couldn't be used by clients who have virtual desktop solutions, such as in banks (at least, our direct client is a major international bank)
and so since they aren't able to use our SDK in their remote session, because the video is unusuable and the media is awful, we set out to create a solution which allows for the commands to be invoked from the user's environment
causing actions in a remote application which is loaded in the user's immediate environment
that remote application is where all of the signalling is performed
then we provide a window from the remote environment which is overlayed in a predictable fashion such that it appears as though it is in the user's remote environment
ie it is over the Citrix Window, and tracks accordingly
so again the idea here is that they needed a video call application to run in a remote desktop environment, where the signalling is being performed locally in an application which could be thought fo as a remote application relative to the primary application
the remote application is run in the driver running in the user's local system, which interfaces with citrix and writes data on a virtual wire which has been registered as what they term a Virtual Channel
the data is split into packets which are somewhat easier to put back together on the other side, as it's not a stream, they are packets with a fixed size which are guaranteed to come out in the same size of chunk
so we essentially referred to that process as packetization, by taking an RFC which detailed the same, and plugged in our numbers, ie the limitation of packet size, and implemented it
our sdk provides several features, including a protocol for messages to be structuredsessions with a lifecycle represented as a progression of states
the original solution was all built into the same process driver process
this created its own rpocesses however as we were using CEF, Chromium Embedded Framework
Chromium Embedded Framework is another SDK which can be used to create Chromium browsers
this allows you to leverage the entire Chromium API, which in our case we were using for loading a remote application which was itself a JavaScript application which holds the other SDK of our company
that SDK provides access to our subscription based services Software as a Service SAAS I should say
we decided to refactor all of this, because the original solution had been rushed as a proof of concept and to get a deployed solution available for the client to use as soon as possible
they were happy with the solution and have been using it internally, first with one team in Hong Kong, and eventually ramping it up to I believe a quarter million of their employees
they are actively using this now
we noticed some bottlenecks in the messaging and some issues which might be alleviated if it were not all piggybacking on the citrix viewer's process
so what we did was redesign it with concerns split amongst separate processes which work together as a networking solution
the first is a Communication link which houses a channel port, encoder/decoder and serializer/deserializer
this would allow us to utilize different serialization solutions in the future, once we adapt the solution for something not involving Citrix
on the radar was,has been and currently is VMWare
essentially any serializer/deserializer could be used
the communication link handles incoming requests from the client side applicationreceives them, sanitizes them, converts them to our own driver's messaging protocol, and then sensd them forward over IPC to another process called the Orchestrator
the orchestrator is
the orchestrator houses a controller to manage session logic and determine message flow, and a process host which we can use for launching other processes
at the moment those other processes are window hosts and browser hosts
the browser host is a daemon which can launch CEF browsers for any number of ongoing sessions
and manage the state of those browsers to ensure that they are acting in accordance with our sessions and processes
the window host is something which can procure, manage the lifecycle of, and destroy a window
and this has to be implemented for each platform
we have window solutions for linux, windows and mac
the linux solution has been deployed for various thin clients
the windows solution mostly for windows 10 64
and the mac solution is one which we are working on right now, is the project for which I am accountable, and is nearing its deployment
we've had to learn some ObjectiveC in order to implement the window properly on MacOS
using a C bridge to give us access to the ObjectiveC API from our C++ based application
I implemented that as an extern declared constant struct which has functions which create an ObjectiveC UI object, call methods on it, and perform cleanup as is necessary
there is multithreading involved, yes
we have a worker class which can be leveraged anywhere it's needed, such as with our orchestrator, whose use of a worker thread is handy for processing message queues
so there are many processes at play here, all communicating and with one another in a patetrn whic his made to allow for a lot of overhead if needs be
we imeplemnted wthis using ZeroMQ, a messaging library for reliable sockets
it offers a few patterns which can be easily implemented
the one which we settled on was a REQUEST-Reply pattern whereby wherein every message sent has to be responded to before another one can go out
this allows us to track the exact order of a messaging scheme
with the original design, everything was just based on passing function pointers on what was mostly

with this new design, each process has 3 sets of sockets
1 main socket for initializing IPC with the broker, heartbeating and shutting down
1 socket for sending requests
so for example, the Communication Link sends incoming messages from the client application as "requests" which are processed so as to infer session actions
all requests are replied to at a 1 to 1 rate
The broker will send requests to the communication link, which are usually events which need to be sent up the wire to the client application

so let's talk about the previous stuff I was doing, very quickly

So first of all there was the Kandy SDK which was a WebRTC callstack written in JavaScript with a more sophisticated SDK written around it to provide access to all of the SAAS features of our various platforms. These mostly involve calling, SMS messaging, text messaging, a contact/phone book user system, and user status type of feature to see who is online or offline etc..

On that I worked on a lot of bugs with our callstack having different behaviours for either CISCO backends or our own application servers with respect to the various platforms

I also worked on creating a new versionof the SDK to be launched as a product under a major telephony company
I worked on the chat / group chat / SMS features, mostly involving creating an interface for calling our APIs and managing an application state

the application state was managed using Redux and Redux Sagas

Sagas are interesting in it uses generators to make handling of side effects easier to reason about and read in code
There is a standard order in flow of middleware with Redux Sagas
Sagas are ongoing infinite loop functions calling generators and the result in actions being evocation of actions, actions cause events, and events are responded to with reducers which transform the application state

Then we also worked on a project called werkout, which was essentially bots with sockets who could communicate with a broker or director which runs a test plan with multiple participants who communicate and interact with one another using the services of our platforms, such as video calling

This serves as a means of performing integration testing, on top of our unit testing

we had really good coverage of unit testing in all of the projects

## KIQ

So how did KIQ come about?
KIQ was an idea that I had to have all of my wife's digital business concerns available to be analyzed and acted upon from one interface
KIQ involves several things, but at the heart of it is a backend server which uses a protocolllllll\