ICA is a flexible and extensible protocol. The protocol is designed to accommodate varying degrees of client capability. During handshaking, the ICA client communicates information including screen resolution,
depth, and cache
. The ICA server re-ceives these parameters from the client and
to this information by providing the appropriate drivers and other settings to make the application perform as though it’s running on a local workstation. This communication allows for a wide variety of ICA
from fixed-function monochrome terminals to high-end workstations.
Through its virtual-channel architecture, ICA can be extended to include new data types, such as sound and video. Virtual channels can also be used to support auxiliary client devices such as badge readers, wands, and
The modular design of the ICA protocol allows the supporting
below it to be expanded. For example, the existing encryption layer can be augmented with RSA (Rivest-Shamir-Adleman) encryption or DES (Data Encryption Standard) encryption. Converters, such as those converting an ICA protocol to X.11, can be added in, and new transport protocols, such as ATM, can easily be supported.
You can augment ICA with encryption, new transports, and new protocol extensions from third parties.
Connecting an ICA Client to a WinFrame Session
To take advantage of the ICA protocol features, ICA
connect to a WinStation, a
session on the WinFrame server. The
configuration of the WinStation defines the attributes of a
session that runs on the WinFrame server. A
Win-Station is primarily associated with a network connection, but
it can also be associated with a serial COM port to provide direct
ICA dial-up access to the WinFrame server.
Accessing a WinFrame Server Through LANs and WANs
To attach to a WinFrame server across a LAN or a WAN, WinFrame requires that a network transport (such as IPX/SPX, TCP/IP, or NetBEUI) exist between the ICA client and the WinFrame server.
Once this transport is in place, the ICA protocol builds a list of available WinFrame servers. The ICA client then connects to the server via the transport specified in the ICA client configuration.
The ICA protocol stack is dynamically configured to meet the needs of each transport protocol. For example, the IPX protocol by itself does not guarantee packet delivery, so WinFrame adds a protocol driver to ensure that the data is reliably transmitted between the ICA connection and the host and that it is received by the client. However, because IPX is a
protocol, a frame driver is not included in this particular ICA protocol stack. The Transmission Control Protocol (TCP), however, is a stream protocol; in this case, a frame driver is included. TCP is reliable; therefore, the Reliable protocol driver is not added to the stack. Figure 3-7 illustrates the ICA protocol stack and drivers.
The ICA protocol stack and drivers
The ICA protocol stack includes the following protocols:
The Compression protocol can encapsu-late an encrypted ICA packet. This protocol is system
and is not
defined in the ICA protocol definition.
The Encryption protocol can encapsulate an encrypted ICA packet. This protocol is system replaceable and is not strictly defined in the ICA protocol definition.
The Reliable protocol is a transmission packaging protocol used to detect transmission errors and to request resends of data. This protocol is used in conjunction with any transport mechanism that does not provide
delivery. Two such mechanisms are Novell’s IPX protocol and standard asynchronous connections.
The Framing protocol is a transmission packaging protocol used to manage stream-oriented communications, such as asynchronous communications and TCP. It is used in conjunction with the Reliable protocol to provide error-free data transmission.
The Modem Control protocol allows for modem detection and initialization prior to connection.