With each server continuously announcing the pro gram material available for playback, clients wish ing to receive a particu lar data stream can monitor the server announcements being sent to add ress
A I. By receiving these annou ncements, a c l ie nt can ascertain the address of each server active on the LAN, the data streams currently being transm itted by each server and the mul ticast add ress to which each is being transmitted, and the data streams available for transmission.
With a large reposi tory of program materia l , i t cou ld easily become i mpractical t o annou nce a l l ava il able material. In this case, the announce ments could be used only to locate avai lable servers, and an inquiry protoco.l or database search
mechanism could be used to locate available mate rial more efficiently.
Once a cl ient identifies a server that is offering the desired data stream, it can request that the server begin transmission. The cl ient sends a mes sage identifying the desired p layback program material. In response, the server allocates a unique multicast address, includes the new material and m u lticast address in its announcement messages, and begins transmitting the program material.
Address Allocation and Tracking
Each server maintains a table containing the usage of each of the A2 to An addresses. Each ad dress is t agged as either currently used or available for use. When a server receives a cl ient's request for trans mission of a new data stream, the server selects a currently unused multicast address and includes the address and data stream description in its announcements of data streams currently being transmitted. After send ing two announcements, the server begins transmitting the data to the cho sen multicast address. Sending two announcements before beginning transmission provides cl ient nodes with ample time to ascertain the address to which the data will be sent and to enable reception of the video program.
In addition to sending announcement messages, the servers also l isten to the announcements from other servers to keep track of all multicast addresses currently in use on the LAN. Each time a server receives an announcement message from another server, it notes the addresses being used and marks them a l l as used in its table. This pre vents a server from allocating an address already used by another server and elim inates the need for a central database or clearinghouse.
I f a server observes that it is using the same address as another server, then the server moves its data transmission to another address if and only if its node address is numerically lower than the other server's node address. The new address is allocated exactly as it would be if the server were beginn ing to transmit the data stream for the first time. This algorithm resolves conflicts where two or more servers choose the same available multi cast address at the same time. In addition, it resolves a similar confl ict that occurs when two
separate LA.I'I segments become joined and two
servers suddenly find they are using the same cast address.
Digital Techuical ]ournal Vol. 5 No. 2 Spring 1993
LAN Addressing fo r Digital Video Data
Clashing allocations of multicast addresses can be held to a minimum if servers allocate an address at random from the remaining pool of add resses rather than all servers a llocating i n the same fixed order.
Identifying and Stopping Playback
After a client requests playback of new material, it can then examine the server's announcements, and when the desired data stream appears as being transmitted by the server, the cl ient can begin receiving data from the advertised multicast address. At this point, any other c lient stations on the LAN can also receive the same video program by enabling receipt of the same address.
When no more cl ients wish to view a partic u lar program, a mechanism is needed to inform a server to stop transmission and return the asso ciated address to the free pool. Two alternative approaches were considered to stop playback; one was chosen for several reasons.
In the first approach, each server tracks the num ber of c lients that have requested a particular pro gram by simply cou nting the number of requests for that program. In addition, clients are required to notify the server when they are finished viewing. The server then continues to transmit the material until all interested clients have ind icated they are no longer interested in viewing. This approach has two problems. If a viewing client node is reset or disconnected, or iJ its message to end viewing is lost, the server could lose track of the nu mber of viewing cl ients and never stop playing a particular program. The second problem, which is more of a nuisance, is that clients have to request playback of a program even if it is already playing to enable the servers to track the number of viewers.
In the preferred approach, interested cl ients periodically remind the se rver that they wish to continue viewing the program. Servers then simply keep playing the m aterial until no cl ient expresses interest for some period of time. For example, cl ients could reiterate their interest in a program every second, and a server could continue transmit ting a requested program until it d id not receive a reminder for 3 seconds. This time lapse would accommodate lost reminder messages from clients, and cl ient failure would result in transmission ter mination within 3 seconds. In addition , when a l l cl ients had finished viewing the m aterial, the server, multicast address, and consumed network bandwidth would be released within 3 seconds,
Multimedia
making them ava i lable for other uses. Selection of the actual timer value depends on the desired bal ance between ongoing consumption of network resources (bandwidth and m u lticast addresses) after all receiving parties have stopped viewing the data, and network, end system , and server resource consumption caused by more frequent reminder messages.