Quick History Lesson
ay back in the early days when Citrix and Microsoft were figuring things out together, it was clear that there needed to be a way for multiple users to have sessions on the same machine at the same time. Windows NT was updated, and profiling was born.
So the first reason why the Citrix protocols are superior is that it was born on a modem–designed for thin bandwidth.
One of the genius things that Citrix did at the time was to write a display protocol. Nothing like it existed at the time, but it needed to be fast, small, and work over a 9600 baud modem with acceptable performance. Additionally, it needed to be resilient in case of connection issues, and allow users to actually run applications based in the data center with whatever device they had, even if it didn’t have the horsepower to run the application.
So in the opinion of many, that protocol is the reason why Citrix still exists. At the time, in their work with Microsoft, this is the one thing that Citrix would not give up to its partner. Microsoft owned the OS and user profiling, but Citrix retained ICA (Independent Computing Architecture) as the display transport protocol. Microsoft had to write their own, RDP (Remote Desktop Protocol).
Through time, Citrix has been diligent about making the display protocol better, more adaptive, more efficient. Among the improvements, for examples, were the introduction of channels, purchase of Framehawk (which is now a channel inside the protocol stack) so they could work over UDP rather than just TCP.
WHY UDP?
Quick lesson. TCP is stateful, which means that every bit of data must get to the other side intact. If something is dropped, missed, or delayed, it will be re-transmitted until the far side indicates, with a checksum response, that all the data made it. UDP, on the other hand, is stateless. This means that if some of the data is lost on the way over, it is ignored. Why would we want this? Think of a phone call or a video. The loss of some of the quality or bits on the screen are far less important than keeping the stream going–it’s about timing. TCP is good when all data needs to arrive. UDP is good when timing is more important than a complete data set.
The second reason why the Citrix protocols are superior is that it utilizes UDP as an option.
The third reason is that it is adaptive, meaning that it can fall back to TCP and utilize the many channel options for a user experience optimized for the situation the user is in.
The protocols themselves deserve a deeper look. Please refer to the excellent posts by Fernando Klerfan and Gregory Momchilov of Citrix. This post, parts I and II, give a good history and technical functional discussion of Citrix protocol stack.
HDX Adaptive Transport and EDT: ICA’s New Default Transport Protocol (Part I)
HDX Adaptive Transport and EDT: ICA’s New Default Transport Protocol (Part II)
WHY EDT?
Why is this important to Citrix? Think of it this way. The display is more like a video than a database. It is more important for the screen to be usable than for every bit to be exactly rendered correctly. And we can now operate very intense highly complex video streams (because it’s really just video after all) without having to make sure we have all the data in place.
Plus, it’s adaptive. If UDP isn’t available (say because it’s blocked, or the version of Receiver you’re on doesn’t support it, it just goes back to TCP. The EDP stack–all channels–at this point, run over UDP, managed by EDP.
This is excellent news! It means that ICA/HDX has finally reached its promised potential, and allows for more future innovation. Stay tuned for more.
