Independent Computing Architecture

Independent Computing Architecture

The Independent Computing Architecture (ICA) protocol is a presentation layer protocol on the Open System Interconnection (OSI) model and is the engine by which ICA clients and MetaFrame (MF) servers communicate data. It was designed by Citrix systems to be a powerful multichannel protocol that can exchange data over network bandwidth as low as 10 to 20Kbps. The protocol is fine- tuned to enhance the experience of users connecting from remote locations to the servers. The ICA protocol is made up of three components :

• Network The ICA protocol can use a variety of transport protocols to communicate data between ICA clients and MetaFrame servers. These protocols include TCP/IP, IPX, SPX, and NetBIOS.

• Server In a server-based computing environment, which MetaFrame is part of, the logic of the application is completely run on the server. This means that the CPU, memory, and disk input/output (I/O) of the servers are taxed and heavily utilized. Only screenshots showing what is happening on the server are transmitted back to the client. The client only interacts and manipulates the user interface (UI) of the application, but all the commands, keyboard strokes, and mouse clicks are executed on the server side.

• Client Because the logic of the application is executed on the remote server, all the client really needs to be able to do is view and interact with the application's UI. Today, ICA clients exist for almost any type of hardware devicefrom Pocket PCs to laptops to traditional desktops. ICA clients also exist for almost any type of operating system from Windows to Linux, Unix, and Macintosh.

ICA Packet

Let's break down the ICA packet and see how it is composed and encapsulated before it is sent to a transport protocol for delivery between servers and clients. The ICA packet is composed of one required byte known as Command and of several optional bytes that are used as necessary to meet certain criteria. Here is a list of the optional bytes and their uses:

• Frame Head An optional byte that is added whenever a streaming transport protocol is being used, such as TCP or Async. These protocols do not send the ICA packet as a single entity but rather split it and stream it in smaller bits; as such, they require a Frame Head that marks the beginning of the transmission and also require a Frame Trail that marks the end of the transmission to the receiving device.

• Reliable An optional byte that offers reliability. In the event that your chosen transport protocol is unreliablesuch as IPX, which has no method of verifying whether a packet sent has actually reached its destinationyou can ensure reliable delivery with this byte. In this case, the reliability byte is added to the ICA packet to ensure error-free communications between the server and the client.

• Encryption An optional byte that is used whenever encryption is configured. MetaFrame supports different levels of encryption between the servers and the client, and this byte carries the encryption information across the wire.

• Compression An optional byte that is added to manage packets that use compression.

• Command Data An optional byte that is associated with the command byte.

• Frame Trail An optional byte that is added whenever a streaming transport protocol such as TCP or Async is used; it functions as the last bit to be received. This byte ensures that all the data between the Frame Head and the Frame Trail have arrived at the destination error free.

Note

The Command byte is the beginning of the base ICA packet. It is the only required byte that is always present in the ICA packet.

Virtual Channels

Virtual channels are a mechanism by which MetaFrame extends its features and functionality. Using virtual channels, the ICA protocol can offer ICA clients audio and video support, among other things, without impacting performance. Virtual channels can be used to deliver audio or video that is running on the MetaFrame server through speakers attached to the ICA client device. On the opposite side, they can map devices that are physically attached to ICA clients and give the user access to these devices as if they were attached to the MetaFrame server. Virtual channels can provide one-way communication between the ICA client and the MPS server or can be a two-way communication process between the client and server.

For the ICA protocol to deliver these services and maintain the same level of performance, it bundles several virtual channels together in one ICA packet and sends them across the communication link. This technique ensures that transmission is less frequent, which conserves network bandwidth. By using this technique, the ICA protocol avoids sending an ICA packet for every virtual channel and keeps itself thin and light. The default virtual channels available with the ICA protocol include

• Audio Transports the audio that an application running on the MF server generates and delivers the sound through the speakers attached to the local ICA client device.

• SpeedScreen Control Maintains transmission of SpeedScreen data between the server and the client.

• Drive Mapping Displays the ICA client's local hard drives through the MPS server.

• ICA Display Transmits the UI of an application from the MPS server to the ICA client.

• Font and Keyboard Layout Ensures that the client and server font and keyboard layouts do not differ and, in the event that they do, unifies them.

• Clipboard Mapping Makes it possible to share the Clipboard between the server and client. So if you copy on the server, you can paste on the ICA client and vice versa.

• Printer Spooling Sends printer spooler data from the MF server to the ICA client.

• Serial Port Managing Allows the ICA session access to its local serial ports located on the ICA client.

• Parallel Port Managing Allows the ICA session to access the parallel ports of the ICA client.

Note

The ICA protocol can support up to 32 virtual channels in one packet.