Acquisition server
Acquisition server is the slave server that serves as the initial source of video and closed captioned text. In the current implementation it supports the Mpegator video capturing board and the Text grabber device to extract captions.
Implementations of particular hardware platforms are made as the specialization of the abstract base classes by inheritance. Thus, more hardware may be added without affecting the existing code.
Implementation
Acquisition server is the Widows NT-based application, but written without a GUI. So, it starts with "main" function instead of "WinMain".
The server consists of the three threads, protocol thread, video thread and text thread . The first is interactive, the second and the third are real-time.
When the protocol thread starts, it connects to the database server and keeps this connection alive all the time when the server is active. The first command the acquisition server sends to the database server is the registration. The database server will check the incoming address of this acquisition server. If the address matches the entry in the configuration file, a static ID will be assigned and sent back. If the address is unknown, database server will complain to the log and disconnects. Next, acquisition server receives the list of push servers to transfer the data stream. The video thread sets-up a permanent TCP connection with each of the push servers. At the same time protocol thread reports to the database server the status of each push server. If the particular push server goes down, this is immediately reported as well.
The video thread keeps all of its connections alive. If one of the connections is broken for whatever reason, the server tries to reconnect it periodically. Thus, any component, including the database server may be shut down and restarted without the need to restart the acquisition server.
The video thread does not block waiting for hardware. The reason for that is that most video hardware and the Mpegator board in particular need to be properly shut-down at the end of recording. So the video thread performs non-blocking polling of hardware and loops checking for messages from the protocol thread. If the shutdown flag is raised, the application never ends before the video thread completes the shutdown of hardware.
The text thread on the other hand blocks waiting for closed captioned text, because the text information comes from the serial port which does not require any shutdown.
All threads are fully synchronized with mutexes, so one thread places messages to another in a memory container which may never be accessed by two threads simultaneously. Synchronization between the interactive and real-time threads is always very accurate. That means, all instructions executed in the mutually exclusive fragments of code have the guaranteed execution time. For example, no I/O should happens when some object is locked. The drawback is that sometimes the correct synchronization may involves the duplication of some data in memory.
Acquisition server have one or several destiantion push servers to transmit the video. The video thread splits new data from the capturing board into packets and then transmits it to each of those push servers. If one of the push servers is unavailable or is just added as the video destination on-the-fly, its address is placed into the queue. Acquisition server periodically picks up the next target from this queue and tries to reconnect. If failed, the address is placed back into the queue.