How the Components Work Together

Communication between the client PC (or any other ICA-enabled client device) and the WinFrame server takes place via ICA—the physical line protocol. The application’s graphical screen image is exported as a logical datastream that is encapsulated in ICA by ThinWire, the data protocol. (ThinWire is not a physical protocol.) The physical protocol—ICA—must guarantee the delivery of the ThinWire datastream with no errors and no missing or out-of-sequence data.

From the perspective of the WinFrame application server, the major portion of the ThinWire component is part of the graphical device interface (GDI) and video driver subsystem. This ThinWire component, in conjunction with key elements in the WinFrame Win32 subsystem, generates highly optimized drawing primitives called the “ThinWire protocol.” The output of the ThinWire pro-tocol driver is a logical datastream that is sent back up a virtual channel API, which takes the datastream and encapsulates it into an ICA packet. Once the ICA packet is formed, it optionally passes through a series of protocol drivers to add functionality such as encryption, compression, and framing. It is then placed on the transport layer and sent to the client. Once at the ICA client, the data packet passes through the same layers in the opposite order, resulting in the graphical display of the remote application user interface on the client. This flow of information is shown in Figure 3-6 on the following page.

FIGURE 3-6

Flow of information between the WinFrame application server and the ICA client