In support of a hardware architecture that allows users to move from Sun Ray thin client to Sun Ray, C2PC needs to be deployed in such a way that multiple instances of the C2PC Client can operate at the same time on a Windows Terminal Server. Currently, the C2PC Tracks.exe process that replicates track data from a C2PC Gateway Server into a Microsoft Access database file can not run more than a single instance because it uses a designated UDP socket port. Once the first instance of C2PC Tracks.exe opens the UDP port all subsequent instances fail because the port is already in use.
C2PC Tracks.exe is a COM object server, hosting the ClientGwConn COM class. When a COM server is registered as multi-use only a single sever will be very every client needing its services. However, by default the server is run as the invoking user and two users are not allowed to share the same service. So, when the second user starts C2PC a second instance of C2PC Tracks.exe is started. COM allows special configuration so that a single instance of a server can support more than one user. The COM server must be configured to "run as" a designated user. DCOMCNFG.exe can be used to setup C2PC Tracks.exe so that only one instance will run for all users.
However, doing this will then lead to the follow problems. C2PC Tracks.exe will be marked as a "Run as batch program" so that it will start in its own "Windows Station". When C2PC Tracks.exe posts the username/password dialog it will not appear to any interactive user. Second, the notification scheme used by
C2PC Tracks.exe to notify C2PC TrackPlot.exe also uses windows messages, and since the windows are in different "Windows Stations" these messages may not correctly be delivered to the listeners.
C2PC Tracks.exe needs to be modified so that it can act as a proper server and not attempt to post UI to the user. Instead, the UI elements should be moved to the C2PC TrackPlot.exe program (which is a UI program). The COM interface C2PC Tracks.exe exposes, IClientGwConn should be extended with IClientGwConn2 that allows the gateway IP address, username and password to be passed as arguments to that C2PC Tracks.exe does not need to post a dialog. C2PC Tracks.exe needs to modify its use of IDBNotify to call the UseServer method so that DBNotify messages can cross "Windows Station" boundaries.
Due to the sort time frame of deployment it is unlikely that a new version of C2PC with the changes required from the background section can be delivered. There are some simple changes that can be made independent of C2PC source code changes that will allow dynamic track updates on multiple client machines.
Instead of enhancing C2PC Tracks.exe to be a true server, a true server, C2PC Tracks Controller, can be written that makes use of the C2PC Tracks.exe server. C2PC Tracks Controller will be registered as a "run as" server. When it is started it will create the C2PC Tracks.exe instance. This instance will run in the same "Windows Station" as the C2PC Tracks Controller (because of the default way in which C2PC Tracks.exe is registered).
When a connection to the C2PC Gateway Server is needed, the C2PC Tracks Controller will instruct the C2PC Tracks.exe program to connect as usual. Then the Controller will wait for the C2PC Tracks.exe to post it UI to ask the user for the IP, user, and password. Once the UI is posted the Controller will send the UI WM_COMMAND, ID_OK, which will be just as though a user had clicked on the (invisible) OK button. Thus C2PC Tracks.exe will then connect to the C2PC Gateway server and start synchronizing the Microsoft Access track database, TacticalObjects.mdb.
To simplify the deployment an operation, the C2PC Tracks Controller will be written as a service that starts at boot, so that before the first user starts C2PC, the C2PC Tracks.exe program will be connected to the C2PC Gateway and synchronizing tracks. The system can be disconnected from the C2PC Gateway server only by stopping the C2PC Tracks Controller server. If more control is needed a separate UI could easily be written with two commands, Connect to Gateway Server, and Disconnect from Gateway Server.
A consequence of this approach is that no user should click on the Connect to Gateway or Disconnect from Gateway menu item of the C2PC UI (perhaps via command profiles these menu items can be removed or disabled). If a user does either action a second instance of the C2PC Tracks.exe program will be started that will fail if the service based instance is already running. If the server instance is not running the user launched instance of C2PC Tracks.exe will interfere with the service based instance when the service based instance is started.
Another consequence of this approach is that the UI for displaying message statistics will not appear. It will be in the hidden "Windows Station".
To allow the notifications from the service based C2PC Tracks.exe without changing C2PC Tracks.exe to call the UseService method of IDBNotify, IDBNotify can be replaced with a socket based version. IDBNotify is a small interface with methods for registering for send/receive and methods to send/receive notifications.
A socket based IDBNotify will require two components to be written. First, a new implementation of IDBNotify must be written. Second a service process that can serve the send requests and deliver them to all registered listeners.
An additional benefit of a socket based IDBNotify is that it will be robust even in the face of client process crashes are client process kills. The existing shared memory based IDBNotify interface may require a system reboot if a client crashes or is killed without allowing it to perform its normal client shutdown which includes un-registering from IDBNotify.