sdk3.md 12 KB
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