Push server is the real-time component, which push video data to the network. It does not know the complete network topology. Instead, it is driven by incoming commands. Push server must be physically installed on the computer with big local storage, where local copy of the movie is stored.
Push server is the single-threaded application, although it may serve several clients and several jobs at the same time. To obtain this goal, event driven architecture is used. The idea is that any action that must be performed by application has the associated class Event. Each instance of this class handles the type of action, associated data and timestamp. Then STL container priority queue is used to hold all events. The head of the priority queue is always the nearest event.
Push server pickups the head of the heap, which is in fact the nearest event and measure the time remaining to this event's timestamp. If this time is sufficient, it spends it to check incoming sockets and to sleep.
Push server do not maintains the permanent TCP connection with the database server. Instead, it receives all commands as UDP packets. Those commands may come from the database server and clients that use this server. The UDP stream is not reliable enought to handle commands vital to the system's reliability. This is the point where the video server must be improved. The general idea to increase the reliability of the system is simple.
First, one-time commands from the database server must be followed by acknowledgements. If the acknowledgement is lost in its turn, the behaviour of the push server must be correct while receiving duplicated commands. To implement this, video server must place all commands to the push server in the pool, from where there are sent in round-robin sequence. When the notification to the particular command is received, it must be removed from the pool. In fact, the database server is reported when each particular push server is up and down by the corresponding acquisition server, but this information may be used only in recording cycle, because in the playback cycle the acquisition server is not required. So, each command must have its time-to-live, and each unsent command must be reported in the log file.
Second, in the case of client-to-push server communication, the feedback mechanism must be used. This means that all commands from the client are related only to the playback cycle of operation. So, if the client requests the movie but do not receive the stream, it must repeat this command several time until the playback starts or request this movie from another serevr if the problem persists. Next, while listening the playback, client must send feedback messages of interest, it means periodically acknowledge that it is still interested to listen for this stream. If the message of interest does not come from the client for a while, push server must imply that this client is terminated and stop the broadcast. All this may be applied to the case when the broadcast must be stopped.