| Real-Time TV Program Distribution and Storage Server with Keyword Access Capability | ||
|---|---|---|
| Prev | Chapter 4. Design and implementation of the Video Server | Next |
Push server is the real-time component, which pushes 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 large local storage, where TV programs are stored.
Push server is a single-threaded application, although it may serve several clients and several jobs at the same time. To obtain this goal, the event driven architecture is used. The idea is that any action that must be performed has an associated class Event. Each instance of this class handles the type of action, with associated data and timestamp. Then Standard Template Library (STL) container priority queue is used to hold and to sort all events.
Push server picks up the head of the heap, which is in fact the nearest event in the future and measures the time between now and this event's timestamp. If there is sufficient time, it spends it checks incoming sockets and sleeps. After the event's action is performed, push server calculates the time for the next event based on the video bandwidth.
There are two kinds of events: load and send . To achieve the smooth network transfer, send events are scheduled to send packets with the size of Maximum Transfer Unit (MTU) after equal periods of time. For UDP protocol, MTU is 1472. With the bandwidth of 1.5 Mbits/sec the push server will send one packet every 8 milliseconds, or 127 packets per second. If there are several broadcast destinations, the push server have independent events for each of them.
The load event is not executed so frequently, because the disk operation is expensive and the bandwidth is better when large chunks of data are loaded. The size of data to load from disk is adjustable at compile time, at presently is equal to 128 Kbytes, so there are 86 network events per a single disk event.
Push server does not maintain a 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.
One-time commands from the database server must be followed by acknowledgements. If the acknowledgement is lost, the behavior of the push server must be correct when receiving duplicated commands. To implement this, database server must place all commands to the push server in the pool, from where there are sent in a round-robin order. When the acknowledgement to the particular command is received, it must be removed from the pool. In fact, the database server is notified 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 involved. So, each command must have its time-to-live, and each unsent command is put in the log file.
In the case of client-to-push server communication, a feedback mechanism is used. This means that all commands from the client are related only to the playback cycle of operation. So, if a client requests a movie but does not receive the video stream, it must repeat this command several time until the playback starts or request this movie from another server if the problem persists. Next, while listening to the playback, the client must send feedback messages of interest, it means periodically acknowledge that it is still interested for listening this stream. If the message of interest does not come from the client for a while, push server assumes that this client is terminated and stops the broadcast. All this may be applied to the case when the broadcast must be stopped.
Push server maintains a connection with a dedicated acquisition server to receive the live video stream. If the connection is lost, push server will open a socket to wait for a new connection. The polling of sockets for incoming data happens when there is a certain time lag before the next event, or if the polling is forced after some timeout. The outgoing UDP stream is scheduled to send packets of the maximum UDP size ( 1472 bytes ) every equal period of time. Assuming that the MPEG1 stream is approximately 150 K/s, a hundred of packets is sent every second.
At this time the push server does not support the RTP payload standard. RTP requires that packets are formed with the understanding of the MPEG data structure. Push server is the real-time application operating with strict deadlines, so the acquisition server must take the job to parse MPEG when it reads data from the acquisition hardware.