CGA Multi-Port is an application of the C2PC Gateway Accelerator (CGA) to workaround a basic problem with C2PC that does not allow it to run in a Citrix multi-user environment.
Normally the term thin-client is used to refer to web based applications where the thin-client is a web browser. Some of the advantages of thin-client based application are centralized management (installation and upgrade of applications at the server) and zero installation on the client machine. The benefits of thin-client deployment can be achieved with legacy applications that were not originally designed as web applications by using technologies such as Windows Terminal Server or Citrix Presentation Server. These products allow applications to be virtualized so that a single server can host many users remotely. Each remote user has virtual access to the application almost as though it was installed locally.
However, legacy applications such as C2PC and JADOCS were not designed to run in multi-user environments such as Windows Terminal Server and Citrix Presentation Server. The original design called for one active user per machine. In many cases, the issues encountered can be solved by using application isolation so that shared resources are automatically copied on a per user bases in a manner that is transparent to the application. Despite the power of application isolation some resources cannot be de-conflicted using the provided application isolation.
C2PC presents several issues that mean that out of the box C2PC cannot be shared by multiple users. First, since version 5.9.X of C2PC, C2PC actively checks to see if more than one instance of C2pc.exe is running on the entire machine. Prior to 5.9.X C2PC only checked for more than one instance per-user. This issue can be solved by using application isolation or replacing mutex strings in the C2PC executables which contain GLOBAL\ with GLOBAL_. The second issue is that C2PC binds to a UCP port from a user launched process named Tracks.exe. Because of this, the first user works fine, but the second and subsequent users are not able to receive the COP because their instances of Tracks.exe cannot bind to the UDP port.
Moebius Solutions, Inc. developed one approach to running C2PC on a Citrix based server named C2PCUTC. This approach replaces some of the components of C2PC that have flawed designs with components that are designed to work in a multi-user environment. A white paper about the C2PCUTC approach can be found at http://www.moesol.com/current_proj/white-papers/c2pc-utc.html
However, this approach was deemed too invasive for use in the CoC. Furthermore, the C2PCUTC approach does not attempt to address user file isolation. User file isolation allows each user's files to be independent from all of the other users on the system. In conjunction with Coherent Systems International Corporation, Moebius Solutions, Inc. designed and developed an alternative approach to allowing C2PC to work on a Citrix based server.
At the core of the second approach is a role based file system isolation system developed by Coherent and a multi-port C2PC Gateway server bridge named CGA Multi-Port. CGA Multi-Port is an extension to the C2PC Gateway Accelerator project which is briefly described below.
The C2PC Gateway Accelerator (CGA) is designed to accelerate the C2PC Variable Data Exchange (VDX) Protocol over low bandwidth and/or high-latency networks. The goal of CGA is to help C2PC Clients and C2PC Gateway machines retain an up to date track picture even when deployed across slow network links. Although CGA can be used on any IP enabled network to reduce bandwidth congestion caused by C2PC data exchanges, it is especially useful at improve situation awareness by decreasing latencies across radio-linked networks or satellite networks.
More information about CGA, including some performance metrics, is available at http://www.moesol.com/products/cga/
To perform the protocol acceleration and still inter-operate with C2PC the CGA must implement the C2PC VDX protocol. This fact is the key enabler for use in solving the C2PC/Citrix problem. The VDX protocol operates on the same port over both TCP and UDP. UDP is used to broadcast data to clients on the network and TCP is used to communicate control data to and from the client.
In a typical installation of C2PC the C2PC Gateway Server will create a TCP service end point bound to port 2701. Meanwhile, all C2PC Gateway Clients will create a UDP service bound to port 2701 so that the clients can receive VDX blob data. Each client is required to bind to the same port so that the server can broadcast a single packet to port 2701 and reach all interested clients.
In a CGA Multi-Port implementation the CGA Multi-Port server binds a TCP service to a series of ports, 52701 - 52725. Then it tracks which ports clients connect on and transmits UDP packets to the port number the client connected to the server with. For example, if client a connects to 52701 and client b connects to 52702 then the server sends client a UDP packets to 52701 and client b packets to 52702. This allows the clients then to bind there UDP end points to 52701 and 52702 respectively, thus solving the problem of multiple clients needed to bind to port 2701.
In testing CGA Multi-Port with live data from Iraq, some issues were identified and most issues were resolved. The first issue is that C2PC (and therefore CGA) uses a UDP throttling method that is purely based on estimates of network throughput. The VDX protocol uses UDP for data transmission and UDP is not reliable nor does it have built in semantics to throttle transmission based on network congestion. Contrast that with the capabilities of the TCP protocol which is reliable and does slow transmission when the network is congested. VDX does not layer a flow control protocol onto UDP, instead you must configure the estimated bandwidth available to VDX to transmit UDP data.
The following serves to highlight why UDP without flow control is a bad practice.
During the initial development of CGA, the UDP throttle was not yet implemented and
a bug in the early CGA implementation of the VDX protocol caused the server to
ring
. Any UDP VDX packet that it transmitted it would receive and re-transmit.
During testing we quickly found our entire network was saturated with VDX UDP traffic
essentially bringing to a halt. Web and email traffic failed as the switch was
overwhelmed with UDP traffic.
The initial estimates for UDP bandwidth for CGA where based on values derived for the HFIP link and were too low for the connected networks in the CoC. Furthermore, the queue overtake logic used in CGA was limited to the DVDX protocol. So CGA was experiencing transmit queue lengths growing the their maximum limit (at which point CGA would drop older data) and track data time-late values that where on the order of 48 minutes.
The solution for this problem was two-fold. First CGA was configured to use TCP to deliver VDX data to C2PC. Second, CGA was modified to implement the queue overtake for the TCP send queue. This worked well, except that the C2PC client has a design flaw that causes its internal processing queue to grow to infinity. Under heavy loads the C2PC client would grow until it ran out of memory and then crash.
The solution to that problem is still under development. The basic approach is to re-tune CGA to use UDP, but implement the queue overtake logic so that the server is never sending out stale data.