Category Archives: Citrix

Citrix XenApp Mobile Application SDK Version 1 Available

The first version of the Citrix XenApp 6.5 Mobile Application (XAMA) SDK has been published on the Citrix web site as of December 17, 2011.  In order to use the SDK, the XenApp server must have the Citrix XenApp 6.5 Mobility Pack (XAMP) installed first.  The team has worked for around a year bringing this together.  The overall goal is to make it easy for enterprise Windows developers write software that works well on mobile devices (phones and tablets).

Continue reading

Dilbert and Citrix

Back in 1993, the Citrix Engineering team used to get amusement from Dilbert.  I remember posting clippings on the outside of my cubicle wall for others to read.  Later I linked my personal website (1994) to the official Dilbert site.  Many of us had come from IBM and fully understood Dilbert’s world.

Continue reading

One in Ten

Just last week, Citrix announced a cutback which would lead to 10% of the workforce being laid off. This resulted in approximately 500 to be forced to leave. Every section of the company was required to follow the 10% rule.

As a result, our Sydney Advanced Products group lost three people. Two of these people I know well. It is not going to be easy for anyone that has left.

There has not been much discussion about the layoff in the Citrix blogs. Perhaps the subject is a bit taboo.

The worst aspect was that was a gap between the announcement and when the names were released. In Sydney this lasted for about a day. There is one location that is still going based on local regulations.

In that one day in Sydney, everyone was concerned about losing their jobs. When you don’t know, that is when things become very difficult.

When the names were announced (more correctly the people were notified and the rest of us heard), it was bittersweet. We still had jobs but we lost important team members.

There is a sense of frustration about the situation but largely there is nothing to be done. This same story is playing out at many different companies now.

Session Recovery Idea 422

Here’s another idea ahead of its time. This one also came from iForum 2003, but from a different customer.
At the time it seemed like a largely unsolvable problem with MetaFrame. This has since changed with the advancement of virtualization and the implementation of XenDesktop.

Here’s the text:

A customer was asking for the ability to recover sessions during iForum in Sydney.
Essentially there are looking for “rock solid” application connections.
Given the nature of networks, this seams like a pretty big request.
I think this request belies a bigger request for being able to have sessions that are fault-tolerant.

The faults could happen at many different places:
Network (down)
Hardware (faults)
Software (exceptions)

Based on the potential for error, it is fairly easy to see that it would be impossible to guarantee 100% up-time.
However, we could greatly improve what we do today.

1. Change ACR to be at a transport layer level so that the user does not experience the session going away until the transport layer has died after a given retry duration and count. It is very important for the user to think it is still running even when it is in the process of reconnecting. This is definitely an image issue.

[ This did change not long after. Connections look alive even if the connection has errors.]

2. Use a RAID-like strategy for running applications. Have multiple sessions controlled by the same user input. I know this would be more difficult than it sounds but it would allow for instantly switching from a bad session to a good session in potentially a fraction of a second.

[Interesting but impractical. Divergent states would not be prevented.]

3. Potentially use record/playback to recreate session states. This does not seem as promising since states can change (files for example) and playing back the stream would not get you to where you want to be.

[This also sounds good but wouldn't work]

4. When you have multiple sessions running to support fault tolerance, have them talk to each other (master slave relationship) so that the sessions will always be in sync even if one goes down.

[Better, but certainly would not work universally]

5. Run the different copies of the same sessions on different machines in case the hardware fails.

[Hints of virtualization but not quite]

Another concept that come out of this is the idea of “Always on” applications.

This just means that for a given user, a certain application is always guaranteed to be running. This would be great for re-connect times and also would give the image of permanence to the user. For example, I would love to have a copy of Outlook “Always On” so that I could quickly check my email without having to fully start a new session. I know this can be done with disconnect times and other tricks but it would be a big coup to be able to say that a server will always be on with your app waiting and running.

[This would be an easy win if Citrix ever decided to push this angle. The technology for this is already there but it would require essentially getting rid of timeouts and making re-connections super smooth]

Back to 2008…

Session recovery is another one of those requirements that has been around for most of Citrix’s history. It is only recently with virtualization that it is possible to move VMs from one host to another. This concept overlaps well with how XenDesktop is built. Companies such as Marathon have focused on making Citrix fault tolerant.

However, the dream of moving around an individual session on XenApp seems almost impossible.

There was a brief glimmer of hope with the announcement of Luflogix from Brian Madden, but alas it was only an April Fools joke.

Given the age of the requirement and also the potential applications, there is a renewed possibility this could be addressed using modern technology.

The first step is to realize that there is a real need. The second step would be to setup a research project within Citrix Advanced Products. As a result, hopefully customers will finally get the ability to guarantee session permanence regardless of failures or location.

Once you get a session that can live forever, the next logical step is to find a way to move it to anywhere else in a self contained aspect. As usual, this kind of thinking is a bit ahead of the curve.