I’ve been working on removing a COM component from our App-V integration in XenDesktop recently and replacing it with a Windows service. Previously the design needed a out of process COM object which was run under the context of a administrative user. This COM object would interact with the Microsoft App-V API, particularly the parts of the API that required administrative privileges. The COM object responsibilities traditionally was to add App-V packages to the VDA, add/remove publishing server URLs, and recently to create Isolation groups, basically a fledgling implementation of Connection Groups – see 1, 2, 3 . These normally occur when the App-V packages are published in XenDesktop.

One of the problems with this is that the COM object cannot access the network, and this is primarily what moving to a service, which runs under the context of Local System, allows us to now achieve. The COM object is owned by a local administrator account(which is generated randomly on installation). This wasn’t an issue for a long time because for a long time we didn’t need to access the local network. However with the introduction of a new way to manage App-V in XenDesktop called Single Admin, we now need to. With the traditional App-V support for XenDesktop, we would interact with the existing App-V infrastructure/servers and as such just needed to access those and through these servers, much of the integration of these servers into XenDesktop was achieved. One thing you needed to ensure was you had a managed App-V system up and running. That was called Dual-Admin support for App-V and XenDesktop because effectively you needed to administrator two systems – the existing App-V infrastructure and the Citrix integration. With the newer integration model, you don't need the App-V infrastructures to take advantage of deploying App-V packages in XenDesktop. Single Admin allows you to do that by putting you in charge of the App-V packages(which previously was a responsibility of the App-V servers).

So with this, you’ll need to define a location of your App-V packages on your network and we’ll need to access them – something the COM component can’t do without the help of another component which fetches the packages and copies them locally, then the COM component can access them. So we’re doing away with this need to copy the packages locally as its a little stupid to tell you the honest truth: Shared content mode, fault streaming,feature block streaming are effectively impossible to achieve, not to mention the fact that we’re clogging up the space on the VDA by coping these packages locally, before publishing and using them. So all be gone!

So that’s what I’ve been working on, designing a service to manage much of these tasks, it’ll have access to the app-v packages on the network, wont need to copy them down, and should still be able to perform the admin functions that the Microsoft API require, while lifting those serious restrictions currently in place with Single Admin. There is still more stuff to do to make Single Admin as feature rich as Dual admin because its still getting started but this is a step in the right direction. We don't support many things that Dual admin does, such as user/package deployment configuration and a whole bunch of other things, but we’re well on our way.

The implementation requires a communication channel between the App-V Broker VDA plugin and the service, in much the same way it needed one with the COM component – and basically accessing the COM component from the VDA plugin was that. So we’ve implemented a named pipe between the two parts to be that communication channel – so the VDA plugin can ask the service to perform those admin functions when it needs to. Its currently pretty rudimentary but it works. Like the previous implementation this communication channel will be locked down so that only communication can occur between our two components, thereby maximising security because security is important.

I implemented a nice way to stream strings across the named pipe from both sides because like I found in BSD Sockets, you need to tell the server how much data your are going to send and the server needs to read just that much. Same requirement but in the Named pipe implementation, you write to a stream by sending bytes or a group of bytes. If you send the length of your buffer(data to send) in the first byte, what could happen is that the length of your buffer cannot be represented by merely one byte, so you’d find on the server, the buffer overflow would occur because the byte had the number ‘wrap-around’ and be represented as something like –254. So the solution I came up with was cool:

Send the number of bytes it would take to represent the length of the buffer, in one single byte. Then store the length into that number of bytes and send those number of bytes to the server. Then send the entire buffer to the server. On the server, it would get how many bytes it must take off the stream in order to represent the length of the buffer, do that and then interpret those bytes as the actual length of the incoming data and then read that amount.

I say the solution is cool but its really not, I can’t really see any other way to do this without doing some naïve tricks(see below) to store a big number in one byte(like reducing that number on the client and increasing that number again on the server side – eventually your algorithm will blow up in your face somewhere and it will be defeated, say or instance when you’re sending lots of data – buffer overflow!). Here is what I mean by naïve and by naïve I mean I naïvely tried it and it eventually corrupted my test data… :

public string ReadString()
    {
        int len = 0;

        // Here begins a hack that works..until it doesn't:
        len = ioStream.ReadByte() * 256;
        len += ioStream.ReadByte();
        byte[] inBuffer = new byte[len];
        ioStream.Read(inBuffer, 0, len);

        return streamEncoding.GetString(inBuffer);
    }

    public int WriteString(string outString)
    {
        byte[] outBuffer = streamEncoding.GetBytes(outString);
        int len = outBuffer.Length;
        if (len > UInt16.MaxValue)
        {
            len = (int)UInt16.MaxValue;
        }
        
        // Here begins a hack that works..until it doesn't:
        ioStream.WriteByte((byte)(len / 256));
        ioStream.WriteByte((byte)(len & 255));
        ioStream.Write(outBuffer, 0, len);
        ioStream.Flush();

        return outBuffer.Length + 2;
    }

In other news, I’m also working on writing a game engine – really more for the challenge than anything else. I’m finished my foray into the broker pattern so I'm moving on. I’ve got a rudimentary game loop, with a fixed framerate update function with a rendering part which runs as much as possible – two facts you need to start implementing a game. The next steps really are to compute the frame’s contents – what will happen in forming each frame – animation will need to be calculated, AI will need to be processed for that frame, player input will need to be used to adjust stuff and that stuff needs to be reflected in the frame. When all that is done, the rendering part needs to draw everything we’ve done. The tricky and interesting parts is implementing AI, simulating, animating, and efficiently storing and manipulating data in such a small amount of time – one frame.

One thing I’m toying with is writing the game engine in C++, because then I can abstract a lot of stuff and can use the STL library. The other part of me wants to write it in C because its faster and I could use the Glib library or roll my own library into it – stulibc.  But then again, C++ is really C with extra bits to make things more complex… I’m particularly looking forward to interfacing with technologies I’ve not worked with before – DirectX, Direct3D, OpenGL and that kind of stuff – I guess particularly around the rendering and animation side of things. Oh and I’ve not even decided what this ‘game’ is going to be – don't know if that's a good thing or not. A game engine needs to be tested and a game tests a game engine. I think it will be a 2D game, very simple and hopefully I can engineer the game engine so its cross platform and relatively platform independent – though I hear the input aspects are hard to implement generically and  perhaps this is where C++ comes into its own with abstraction capabilities – not that pure C can achieve the same outcome(but with extra legwork).

That's pretty much the week’s work. Today is Saturday and we’ll continue again on Monday.

I had a rather useful day yesterday. I started working on involving myself in Glib as this is a cross platform library not dissimilar to my own(only more feature rich, stable and mature) and includes some interesting and useful constructs notably the wide ranging data structures, regular expression support(yay!), and cross platform IPC mechanisms among other things. I did notice that the similarities include a command line parsing routine, file utilities, string utilities, a .ini style configuration file parser, threading support(albeit mine is simplistic). It doesn’t however have any specific support for networking sockets but I suspect that's because they don't think its necessary due to native BSD Sockets being implemented in all OSs.

Another interesting omission is encryption and compression routines, again I suspect that's because their are better solutions out there already namely libssl and gxip/bzip etc. Still, I like the idea of my library having some ‘small’ support for these – like in the future perhaps support for ceaser cipher or ROT ciphers – that sort of thing – weak but still something to protect text. I think basically glib is the library that mine is trying to be though it will never compete unless it really focuses on issues not already achieved by glib.

I looked at implementing RSA in C using libssl and was surprised to realise that one cannot encrypt anything larger than the size of the key used, say 2048-bit. The idea makes sense in as much as you’d only encrypt using RSA a special key that you then transmit insecurely. That key obviously being a symmetric key used for the encryption/decryption of the data being sent. But prior to that public/private keys are used to encrypt this symmetric key (which again can’t be bigger than the RFA key size used for the public/private key combination).

Here is a autotools recipe to build glib linked apps under a posix environment (I’m using autotools for cross platform compatibility but initially used MinGW under Windows 10).

AC_PREREQ([2.67])
AC_INIT([glib_test], [0.1], [fakeaddress@foo.net])
AM_INIT_AUTOMAKE([foreign]) 
AC_CONFIG_SRCDIR([])
AC_CONFIG_HEADERS([config.h])
 
# Checks for programs.
AC_PROG_CC
PKG_PROG_PKG_CONFIG([0.27])
PKG_CHECK_MODULES([GLIB], [glib-2.0 >= 2.26.0])
 
# Checks for libraries.
AC_SUBST([GLIB_CFLAGS])
AC_SUBST([GLIB_LIBS])
 
# Checks for header files.
 
# Checks for typedefs, structures, and compiler characteristics.
 
# Checks for library functions.
 
AC_CONFIG_FILES([Makefile])
AC_OUTPUT

I basically downloaded the Windows binary of the GTK+ drawing library because it includes glib (cunning indeed) and its this that actually guided me through the process.

In other news I did read up on book about ANSI SQL, a book by Ben Forta called “SQL in 10 Minutes” – you can get it from Amazon here if you’d also like to read it.

It basically took me most of the afternoon to read, in between the Scotland-Ireland(Scotland nipped a win) and England/France(England won) rugby matches incidentally. Of the content of the book a few concepts were welcome additions to my knowledge: Transaction managment such as the statements:

BEGIN TRANSACTION
-- Do stuff
SAVE TRANSACTION point1
-- Do more stuff
ROLLBACK TRANSACTION point1
-- Do more stuff after rollback
COMMIT TRANSACTION

Which is all about dealing with errors and partial commits. Then the aspects around Group By’s HAVING syntax in contrast to WHERE syntax, where the former is about filtering groups down and the latter about filtering rows down(has no concept of groups). I also learned about check constraints which I’d never touched on before. I finally figured out why CURSOR constructs are used though, I’m not sure I like the amount of work one has to do with them. All in all a good book I’d say – to the point, concise and covering most of what you need to know to be a generalist SQL programmer.

So this weekend I decided it was high time that I document my project that I undertook more than 6 months ago. Its a C-based software broker that I’ve been tinkering with for a long time now and the whole idea behind it has been achieved so their is no point in continuing. The idea was to learn how the broker pattern works and moreover how TCP/IP sockets work. To that end, I’m done – I know how the broker pattern works and why its useful and how to communicate between the various components in the design.

Someone told me once that in order to move on, you need to celebrate the end of the previous. To that end, I’m ceremoniously declaring my broker finished and done so I now have no need to work on it. I can totally understand the sentiments of the previous saying because I’m continually ‘tinkering’ with it, as if its not finished but I’ve got no goals for it now so the tinkering seems empty and pointless. I want to stop working on it and move on to other projects. Its nice to say that something is done. I wrote about the broker here and you can read about it there. That was the primary thing I did yesterday.

If I was going to write another broker, I’d do most things the same but I’d do a lot differently . One thing I’d so is allowing the protocol format to change easily. By far the part that I spent the most time on trying to figure out was how to call a C function when you’ve received a protocol message saying that a specific function should be called with the provided arguments:

{ "request-type" : SERVICE_REQUEST }
{ "message-id": 3456789 }
{ "sender-address" : "127.0.0.1" }	
{ "reply-port": 8090 }	
{ "op"=>"getServerDate" }	
{ "params" => [ buffer, length, ... ] }

So I’d now have to dynamically figure out how to call getServerDate(buffer, length) or whatever the protocol message says I should do. I spent a long time trying to figure out how to do that. But because this is C (and C can do anything) I was determined to do this somehow but didn’t know how. So I’ve ended up creating an array of void pointers for each parameter and then somehow I’d cast those void pointers to the right pointer types parameters, based on the type of parameter that is passed in to the “params” section above (in libmsgpack you can specify the type) to call a real C function…