Video server architecture
Components, topology and protocols
SBSVS consists of several components: a database server, one or multiple acquisition servers, one or multiple push servers and the clients. The following is the architecture of the SBSVS.
Database server is the master server, which stores various kinds of metadata and manages the video data network configuration. It receives incoming connections from clients and acquisition servers, answers informational queries, performs actions requested by super-user authorized clients and sends commands to slave acquisition and push servers. It is responsible for managing the recording schedule as well. Only database server knows the whole network topology and the state of the system. If any other component is turned off, crashes or joins the system, the database server modifies the new topology of the system accordingly. The best way to keep track of the state of other components is to maintain the permanent network connection. Thus the database server is the only component of the system that maintains a pool of active connections.
Acquisition server is one of two slave servers. This is NT-based program that captures Mpeg data using the Mpegator board and reads closed captions with Text grabber device. This server does not store any data locally, instead, it transmits the mpeg video stream to one or multiple push servers and closed captioned text stream to both database server and push servers. Video (mpeg) data are stored by push server's local discs and all text data is stored in the database server.
Upon startup, acquisition server maintains the permanent TCP connection with the database server to receive commands and send notifications. ( protocol 1 on Fig. 3.1 ). After the direction from the database server it opens the permanent TCP connection with the dedicated push server to transmit the video stream( connection 3 on Fig. 3.1 ).
Push server is the other slave server. It performs two types of activities at the same time. Firstly, it receives live broadcasting video/text streams, stores them on local storage for later playback and pushes that data to various broadcast destinations as specified( UDP stream 6 on Fig. 3.1 ). Secondly, it pumps locally stored mpeg data to the specific client by request ( UDP stream 5 on Fig. 3.1 ). Video data may be, but not necessarily, duplicated in multiple push servers to optimize the access speed. Push server may transmit live broadcast data as well as the stored data at the same time. Various clients may request different movies from the same push server. All activities of the push server are performed in response to command packets sent from database server or client ( UDP command packets 4 on Fig. 3.1 ). UDP is chosen for performance reason: push server is the real-time application, so polling the single UDP port is much more efficient than polling several TCP connections and then performing blocking reads upon data arrival.
Client is the Linux/Unix application, which uses a convenient user interface to show data and perform actions. Mpeg video is displayed by MpegTV library, which is available for all major Unix platforms. User interface is written with GTK+ toolkit and the Gtk-- C++ wrapper for it. SBSVS client also runs on Solaris as well.
Client maintains a permanent TCP connection with the database server to send various requests and commands ( protocol 2 on Fig. 3.1 ). If the client passes the superuser authorization, it may edit the movie database, server and whole system settings for administration and perform manual movie recordings.
Broadcast service
Let's consider in depth the network topology in the case of the live broadcasting service. The acquisition server streams a video sequence through a TCP connection to the push server, while the push server, which in turn retransmits it as UDP packets to the client.
Each acquisition server is uniquely identified by its ID, which may serve as the locator to request the acquisition server's content. SBSVS stores the static topology of servers. That means that the database server stores the static graph of servers and connections. Some servers may be inactive, but no server may join the system without being specified in the configuration file. We define the ID number of each acquisition server as a channel.
At the client side, the channel should appear as the ID number, description, port number to listen for UDP packets and the address of push server to send feedback packets. ID is sufficient to retrieve the remaining information. This does not restrict that different acquisition servers may deliver the same TV program - just like two absolutely different channels may have the same description and the same content while been defined as different channels.
The acquisition server does not know the final destinations of the broadcasting and never loads this information. Instead, at the boot time it receives from the database server the list of push servers that will (may) work as transmitters and will (may) store the data locally. The push server should be located on the computer that have a convenient access to all local networks where the clients reside. It is convenient to make the push server's computer a router or a computer with several network interfaces. Thus the area reached by the server is expanded.
If the broadcast destination is a multicast address this computer should support multicasting. The push server may have only one connection with acquisition server to receive data, but it may have several broadcast destinations. Picture 3.2 shows the network topology example, where two channels are broadcasted from the single computer. Two acquisition servers, located at addresses 130.245.22.15 and 13.245.24.30 are transmitting video to the corresponding push servers, located at the same computer with two network interfaces 130.245.22.1 and 130.245.24.1. First push server accepts data on socket 7081, the second accepts data on socket 7082.
Each push server have only single incoming stream of video from the dedicated acquisition server, but it may have several outgoing broadcast addresses. In our example the push server computer has two network interfaces: 130.245.22.0 and 130.245.24.0. Thus, each of push servers is configured to broadcast to both of the UDP addresses 130.245.22.255 and 130.245.24.255. The first channel may have the assigned port number 7080 in both of local networks, the second one is broadcasted to the port 7081.
All those network parameters are assigned once by the system administrator and are maintained by the database server. The client may request from database server the list of active channels broadcasted at the specific LAN. For example, the client with the network address 130.245.22.12 will receive the response that the channel #1 is available at port #7080, and the channel #2 is available at port #7081.
The static topology should not imply that all data are broadcasted permanently in all possible destinations. This problem is resolved requiring clients to acknowledge the interest in a push server. If given some fixed timeout the push server had not received any acknowledge of interest from the specific destination, this channel should be suspended. We should not confuse the suspended transmission of channel with inactive channel. While the channel is suspended the network topology is not affected. The database server that controls the graph of the network is not interested about the details of transmit-ion. On the other hand the client distinguishes only active and inactive channels, but don't know if the transmission is suspended. When the client wants to receive the channel, it starts the periodical posting of packets of interest to the push server. It's the push server responsibility to change the status of transmission to not suspended.
In our example, if the acquisition server #1 is down, this channel is inactive. Suppose there is no clients that listen for the channel #2, so this channel is suspended, but active. If the client at the address 130.245.22.12 requests the list of channels from the database server, it will receive the list of two channels, with channel #1 inactive and channel #2 active. Then, the client may join the channel #2 and the push server will start to broadcast it.
The described network topology is static, because it is preconfigured once. This does not imply that all components are required to operate, been located in permanently accessible networks on computers that never crash or reboot. Instead, we define that the status of the channel may change relatively to the particular destination. The status may be active or inactive. If the acquisition server does not operates or is unreachable, its channel ID may not be used by another source, so this channel is defined to be inactive relatively to all destinations. If the particular local network is not listed as the destination in any push server destinations list, this channel is not listed by request of any client from that network and its status is undefined. If the acquisition server successfully transmits data to some push servers while some others are not operating, the status of this channel will be different relatively to different clients. If several push servers may transmit the same channel to the same destination, this is not the error, but that means that user may not distinguish which push server it wants to listen because by definition this channel have only one ID. So one of push servers will be selected. If one push server is operating while another does not work by some reason, the database server will assign the operating one when the client requests this channel.
Playback service
Playback stream is the point-to-point UDP stream: from push server to the client. When client requests the movie to play, the database server returns the parameters of the nearest push server to serve the request. Then client sends the "play movie" command directly to the push server. The database server use the preconfigured table to dynamically select which push server will serve the incoming client request. At any time it knows the list of working push servers and the selection is performed only from this list.
To control the streaming, the client sends feedback packets back to the server. Those packets include acknowledgment of interest and any messages related to the control flow. In RTSP standard all control flow messages are supposed to come through a permanent RTSP connection. To implement this in our case the client might send messages to the database server and let it transfer commands to the corresponding push server or to open another RTSP connection directly with the push server. Both options seems to be inappropriate. In the first case, the database server that operates without any real time guarantee will be in charge of inappropriate real-time activity. In the second case, the performance of the push server will suffer because it needs to poll many open TCP connections. But it is possible to implement RTSP on UDP instead of TCP.