Method and system for fault tolerant media streaming over the internet

[0001] (Technical field) The present invention generally relates to digital signal transmission over a computer network, especially on the Internet.<u style="single">Live media</u>Content<u style="single">Tsu</u>Streaming<u style="single">Delivery</u>To do<u style="single">Fault-tolerant, or fault-tolerant delivery</u>It's about the method. [0002] (Explanation of related technology) Most Internet users do not have fast enough access to the Internet to download large multimedia files quickly. Streaming is usually Microsoft's NetPlayer (R), Apple's Quicktime (R), and RealNetworks (Real). Using browser plug-ins such as Networks' RealSystem (R) etc., web-based video, audio, and multimedia files as a constant, continuous stream on the requesting client. It is a technique for delivering these files so that they can be processed. Video streaming, for example, is an online video distribution mechanism that provides audio and video to Internet users without the user having to wait for the content to be completely downloaded to the user's hard drive. The cache method reproduces the content when it is received, and the buffering mechanism smoothly reproduces the content. Theoretically, streaming video acts as an immediate on-going broadcast to the end user or viewer. [0003] From a network perspective, the traditional approach to streaming content on the Internet is to send a streaming signal from the source to a device known as a splitter (or repeater, reflector, or reflector), which device Copy the source signal to create a large number of signals. Many signals are the same, and each is sent to a different destination. By tandemly connecting splitters in a tree, a single source stream can be duplicated to make thousands or more identical copies. In this way, many viewers on the Internet can receive the same streaming signal at the same time. [0004] A serious problem with existing streaming methods of this type is that they are not fault tolerant. Figure 1 shows the reason. In this example, the source signal (A) is sent to the splitter (B), which in turn sends a copy of the signal to the 10 splitters (C1, ..., C10). Each second-level splitter then sends a copy of the signal to five endcasters (D1, ..., D50). So, for example, splitter C1 sends a copy to end user D1-D5, splitter C2 sends a copy to end user D6-D10, and so on. However, if communication with a given splitter fails, some users will not be able to receive the original signal. In the network of Figure 1, this is true for users D6-D10 if C2 fails. To overcome this problem, the end user can detect that the end user is no longer receiving the streaming signal, and an alternative splitter (such user trying to get another copy of the signal). For example, it is also known to those skilled in the art to be able to try to contact C3). However, such an approach can interrupt the signal and is expensive to implement. [0005] Therefore, there is still a need by those skilled in the art to provide improved fault-tolerant streaming techniques. The present invention solves this important problem. [0006] (A brief overview of the invention) The present invention provides fault tolerance for streaming signals in computer networks. Provide a copying process to give. In one embodiment, the original signal or source signal is sent to several splitters. Each splitter makes a copy of the signal and sends the copy into a second layer device called a "concentrator." A given concentrator receives one or more copies of the source signal as input. In a preferred embodiment, a given concentrator receives two copies of the source signal from at least two splitters. The concentrator processes a copy of the input streaming signal, for example, according to a given processing algorithm, by coalescing the copies of the input streaming signal into a single, or synthetic copy, of the original source signal. In this way, preferably a given concentrator receives streams from multiple sources, removes duplicate packets, and then outputs a single stream. The output of the given concentrator can then be given to the splitter. At this time, if you want to make any number of copies of the signal, the process is repeated. At the end of the copying process, the output of the splitter or concentrator is given to the end user directly or indirectly. Since the copying process is fault tolerant, the end user's signal is uninterrupted regardless of signal or device issues within the distribution mechanism.<u style="single">Therefore, the present invention is a fault-tolerant delivery method for live media content that can be used as a stream of data packets in a given media format, with data packets in a set of splitters located in each data center. Each server receives a stream and outputs a copy of each packet of the stream from each splitter to a set of server areas, each server area containing a concentrator and a set of media servers associated with a given media format. The stream of data packets is reorganized by having the concentrator in the area receive and process the data packets from each splitter, discard the redundant data packets, and send the data packets without delay after receiving them if they are not redundant data packets. , Each set of media servers in the server area has data by feeding the data packets transmitted from the concentrator as a stream of data packets to each set of media servers associated with a given media format. Allows a stream of packets to be supplied, causes each of the set of media servers in each server area to receive the stream of data packets sent from the concentrator, and receives the stream of data packets sent from the concentrator. It consists of steps to output a stream of data packets from a given media server in the server area in response to an end user request directed to one of a set of media servers in the server area. Provides a fault-tolerant delivery method for live media content, where is delivered from each splitter to each server area by a non-streaming media protocol, and a stream of data packets is output from a given media server by a given streaming protocol.</u>.. [0007] One type of processing algorithm performed by the concentrator is simply to send the first copy of each packet in the signal stream. A copy of the packet already sent is simply discarded. This algorithm has data with a first value (eg, "1") if the packet i in the stream is being forwarded, otherwise it has a second value (eg, "0"). It may be executed by maintaining the array f (i). When a copy of packet i is received from one of the input streams, it is forwarded only if f (i) is equal to the second value. This technique is convenient because it allows you to reconstruct a complete stream from two or more substreams. Therefore, the concentrator makes a copy of the original stream while the input copy of the stream as a whole contains all the packets of the original stream. [0008] Another type of processing algorithm that can be executed by the concentrator uses a buffering technique. This approach creates a buffer of a given size for each input stream to create an n-dimensional array. Where n is the number of input streams. At a given cycle rate, the concentrator sends the packet with the lowest index contained in any stream buffer (ie, the fastest packet in the stream sequence). As each packet is sent, the data in the array is updated so that future copies of the same packet can be discarded. This protocol allows the concentrator to rearrange the packets in the stream so that the packets are output in the correct order. [0009] One or more concentrators as described above enable the streaming of fault-tolerant media on computer networks such as the Internet, intranets, virtual dedicated networks, and the like. [0010] So far, some outlines of more appropriate purposes and features of the present invention have been described. These objectives should be considered as merely representing some of the more prominent features and applications of the present invention. Many other beneficial results can be obtained by applying the disclosed invention in another way or by modifying the invention as described below. Therefore, a more complete understanding of the invention and other objectives may be obtained by reference to the "Detailed Description of Preferred Examples" below. [0011] For a more complete understanding of the present invention and its advantages, a later "detailed description" should be referred to along with the accompanying figures. [0012] Streaming media is a type of internet content that has the important feature that it can be played while it is still in the process of being downloaded. The client can replay the first packet of the stream, decompress the second packet, and receive the third packet. Therefore, the user can start enjoying multimedia without waiting for the end of transmission. Streaming is very useful for delivering media. This is because media files tend to grow, especially as the duration of programming increases. To watch a non-streamed media file, the user first downloads the file to their local hard disk-which can take minutes or even hours-and then opens the file with player software that matches the file format. .. To watch the streaming media, the user's browser opens the player software, which buffers the file for a few seconds and then plays the file while simultaneously downloading the file. Unlike software downloads, streaming media files are not locally stored on the user's hard disk. When the content bits are used, the player discards those bits. [0013] The quality of streaming media varies widely depending on the type of media being delivered, the speed of the user's internet connection, network conditions, the bit rate at which the content is encoded, and the format used. These last two concepts will be explained in more detail later. In general, streaming audio can be FM quality, but streaming video is poor by TV standards, has a smaller screen, lower resolution, and fewer frames per second. Sources for streaming media can be media in almost any format, including VHS or beta tapes, audio cassettes, DAT, MPEG video, MP3 audio, AVI, and more. Before streaming the content, the content must first be encoded. This is the process of doing four things: That is, converting content from analog to digital format when needed, creating files in a format recognized by streaming media servers and players, and delivering in real-time, given limited bandwidth. File compression and media delivery bitrate settings to maximize the richness of the content you get. Streaming media uses "lossy compression". This means that some parts of the content will not be retained after decompression at the client end. For example, compression can reduce a VHS video clip from 30 frames per second to 15 frames per second. Generally, the media must be encoded at a specific bit rate, for example 28kbps, 56kbps, 100kbps, etc. Content owners typically choose to encode media at multiple rates. Therefore, users with fast connections will get the best possible experience, but users with slow connections will also have access to content. Obviously, the lower the code rate, the more original content must be discarded during compression. [0014] Non-in the sense that server and client software developed by different vendors-Apache, Microsoft's Internet Explorer (R), Netscape Communicator (R), etc.-work well together. Streaming content is standards-based. However, streaming media usually relies on the software of the owner server and client. Servers, clients, production and coding tools developed by streaming software vendors are collectively referred to as formats. Streaming media encoded in a particular format must be serviced by the media server in that format and played by clients in that format. Streaming media clients are often referred to as players and usually exist as plug-ins for web browsers. Streaming media clients can often also play non-streaming media files based on standards such as WAV or AVL. [0015] The three major streaming media formats used today are RealNetworks' RealSystem G2 (R), Microsoft's Windows Media Tschnologies-WMT (R), and Apple. (Apple) QuickTime (R). Real System G2 (R) handles all media types, including audio, video, animation, still images, and text, but does not support HTML. Real System G2 (R) supports XML-based SMIL, which allows content providers to time and position media in the player window. Real uses RTSP to deliver media in real time. In order to stream in WMT's Advanced Streaming Format, the content provider must have Microsoft's NT4 Server (R) installed. WMT does not support SMIL or RTSP, but it has its own protocol to call HTML + Time. Apple's QuickTime (R) recently added features to streaming media. QuickTime (R) can support a number of formats, including VR, 3D, Flash, and MP3. QuickTime (R) streaming uses RTSP to deliver movies in real time and requires a dedicated media server. [0016] As another background, RTSP, or Real Time Streaming Protocol, is a client-server multimedia representation protocol that enables controlled delivery of streamed multimedia over IP networks. RTSP provides "VCR-style" remote control capabilities for audio and video streams, such as stop, fast forward, rewind, and absolute positioning. Data sources include both live data feeds and stored clips. RTSP is RTP (Real Time Transport Protocol) and RAVP (Resource Reservation Protocol) Protocol) is an application-level protocol designed to work with lower-level protocols to provide full streaming services on the Internet. RTSP provides a means for selecting distribution channels (such as UDP, Multicast UDP, and Multicast TCP) and distribution mechanisms based on RTP. RTSP establishes and controls a continuous stream of audio and video media between the media server and the client. In RTSP, each presentation and media stream is represented by the RTSP URL. The entire presentation and properties of the media are defined in the presentation description file, which can contain encoding, language, RTSP URL, destination address, port, and other parameters. The presentation description file can be obtained by the client using HTTP, email or other means. RTSP differs from HTTP for several reasons. First, HTTP is a stateless protocol, but the RTSP server must maintain a "session" state to correlate RTSP requests with the stream. Second, HTTP is the basisIn essence, it is an asymmetric protocol in which the client makes a request and the server responds, but RTSP allows both the media server and the client to make a request. For example, the server can issue a request to set the playback parameters of the stream. [0017] The non-streaming content transport layer uses the transmission control protocol or TCP. This is a connection-oriented protocol. A connection-oriented protocol means that the connection between the server and the client is established and maintained until the content is fully received. One reason for this connection is that the client can report if any IP packet is not received, and then the IP packet is retransmitted by the server. As a result, a file that is successfully transmitted over TCP, such as a logo, is always the same as its source, but the time required for transmission can vary widely depending on the infrastructure. [0018] Conversely, the transport layer for non-streaming media uses the user datagram protocol, or UDP. UDP is a connectionless protocol, under which IP packets are sent from the server to the client without establishing a connection. This protocol allows real-time nature of streaming media without having to wait for dropped packets to be retransmitted. However, it also means that the content quality between the server and the client may be significantly reduced, or that two different users may have very different experiences. [0019] The present invention is designed to be used with any streaming media source, encoding method, media format, and streaming (or other transport) protocol. [0020] Next, as shown in FIG. 2, the packet switching network 200 in which the present invention is executed includes a signal source A, a set of splitters B1-Bn, and a set of end users D1-Dn. According to the present invention, the network also includes a set of so-called "concentrators" C1-Cn that facilitate the signal copying process of the present invention. This process ensures that each end user always receives a copy of the source signal, regardless of transmission interruptions due to, for example, equipment, equipment, or communication failures that can occur within other elements of the distribution system. [0021] [0021] Preferably, the concentrator C is located in one or both of the physical and logical layers between the splitter B and the end user D in the network. The physical configuration shown in Figure 2 is, of course, just an example. Of course, the end user is usually a client computer that includes a browser or other graphics viewer with plug-ins or native support for streaming signal content. In a preferred embodiment, Concentrator C is a software program, i.e., a set of computer instructions containing one or more processes that can be executed within a processor. As shown in FIG. 2, each concentrator C receives one or more copies of the source signal data stream as input. In a preferred embodiment of the invention, each concentrator C receives a copy of the source signal data stream from at least two (two) different splitters B. So, for example, in this example, the original signal is sent to several splitters B1, ...., B5. These splitters make copies of the signals and send them to concentrators C1, ..., C20. Splitter B1 sends a copy of the signal received from source A to each of concentrators C1, ..., C8. Splitter B2 sends a copy of the signal received from source A to each of the concentrators C9, ..., C16. Splitter B3 sends a copy to concentrators C17, ..., C20 and C1, ..., C4, while B4 sends a copy to C5, ..., C12 and B5 sends a copy to C13, .. ., Send to C20. Again, these examples should not be considered limiting the invention in any way. However, in each case, it can be seen that all concentrators receive exactly a copy of the source signal data stream from the two splitters. In other words, each concentrator receives two streams, UDP1 and UDP2, which represent a copy of the original source stream. [0022] In general, the function of the concentrator is to process the input stream, perform merging of the input stream, and then output a single, or synthetic copy, of the source signal data stream from the concentrator. The concentrator removes duplicate packets and preferably outputs a single stream feed. This process is quite convenient. In particular, given several copies of a stream, a single original stream can be created from the rest of the duplicate stream, even if all of them are lost. This technique is very robust and can take a number of failures before the end user's experience is compromised. [0023] The processing of the data stream can be done in many different ways. For example, FIG. 3 is a flowchart showing a first embodiment of a processing routine in which the concentrator sends only the first copy of each packet in the stream. A copy of the packet already sent is simply discarded. FIG. 4 shows a second embodiment of a processing routine in which multiple copies of a stream are buffered and out-of-order packets can be rearranged as output is produced. Next, each of the examples will be described in detail. [0024] Next, as shown in FIG. 3, the first embodiment of the processing routine utilizes an array f (i) for the source signal. The elements of the data array have a given first value, eg 1, if the stream packet i has been forwarded from the concentrator, and a second value, eg 0, otherwise. The routine begins at step 300. At step 302, an instance of the processing routine is typically invoked when the first packet of the stream reaches the concentrator. At step 304, the array is initialized. The processing routine is then continued in step 306 to test whether packet i was received from one of the input streams. However, if the result of the test in step 306 is positive and indicates that the packet has been received, a test is performed in step 308 to determine if f (i) = 0. If f (i) = 0 (since this is the first occurrence of packet i), the routine continues at step 310, forwarding the packet from the concentrator without delay. In step 312, the routine updates the array by setting the value of packet i in the array to 0. Control then returns to step 306. However, if the test result at step 308 shows that f (i) is not equal to 0, then the routine is continued at step 314 and the packet is dropped (because it has already been forwarded). [0025] Therefore, in effect, when the packet reaches the concentrator, the processing routine parses the packet. If the parser is already looking at the stream packet, the packet is dropped, otherwise the packet is forwarded. [0026] The processing routine of Figure 3 is convenient in that it is easy to implement and does not introduce any delay into the stream, which can be caused, for example, by waiting for a particular copy of the packet to arrive. This routine also has the desirable feature of being able to reconstruct a complete stream from two or more substreams. Therefore, the concentrator makes a copy of the original stream as long as the input copy of the stream contains all the packets of the original stream as an aggregate. [0027] For example, in Figure 2 again, if one of the splitters (eg B1) fails, each of the concentrators C1, ..., C4 still receives the stream from the splitter B3, and the concentrators C5, ..., Each of C8 still receives a stream from splitter B4. In the example of this description, the signal transmitted by any concentrator is never interrupted. This property is maintained regardless of which splitter is not functioning. In fact, even if two splitters (eg B1 and B3) suffer packet loss, each of the concentrators C1, ..., C4 still uses the above process (if the packet loss is less than 50%). , The original signal can be reconstructed. [0028] Next, FIG. 4 shows an alternative embodiment in which each input stream in the concentrator has a corresponding buffer. By buffering the stream packets, the concentrator can reorganize the packets in the stream before output. The routine begins at step 400. At step 402, the buffer is initialized. Then in step 404 the routine is continued and tested to see if the given cycle has passed. If not, the routine continues in step 406 (for each stream) to test if the given input packet (for that stream) has already been forwarded. If the result of the test at step 406 is positive, the routine discards the packet at step 408. If the given input packet has not been forwarded, the packet is buffered in step 410. Control then returns to step 404. Using the buffering scheme, for example, packets from stream UDP1 are buffered in the first buffer, packets from stream UDP2 are buffered in the second buffer, and so on. When the results of the test at step 404 indicate that a given cycle has passed, control branches to step 412 and the earliest packet in the stream sequence is identified. At step 414, a test is performed to determine if this packet is out of sequence. If this packet is out of sequence, the routine rearranges the packet as needed in step 416. Then, in step 418, the resulting stream is output from the concentrator. At step 420, the array is updated to reflect the forwarded packets. Step 418 is also reached if a negative result is obtained in step 414. [0029] Therefore, the routine of FIG. 4 keeps a buffer of the given size for each input stream copy. At each cycle, the concentrator sends a packet with the lowest index contained in any buffer. As each packet is transmitted, the data in the array is updated so that future copies of the same packet can be discarded when they reach the concentrator. As you can see, the protocol in Figure 4 is similar to the protocol in Figure 3, but with the additional desirable feature of being able to rearrange the packets in the stream so that they are output in the correct order. Is different. The larger the buffer size, the more likely it is that out-of-order packets can be output in order. In this way, packets slowed down on the network have the opportunity to catch up with the buffer. [0030] The output of the given concentrator can then be returned directly to the splitter or end user, regardless of which technique (FIG. 3 or 4) is used with the given concentrator C. When the concentrator is output to the splitter, the process can be repeated to make any number of copies of the source signal data stream. At the end of the copying process, the output of the splitter or concentrator (or any other device) is given directly to the viewer. The resulting copying process is completely fault tolerant. In particular, the end user's signal is uninterrupted, regardless of which signal is destroyed. [0031] The number of signals input to each concentrator determines the number of failed systems that the distributed system can tolerate. For example, if all concentrators receive signals from at least k different splitters, the system should tolerate any subset of k-1 signals without compromising the signals received by any end user. Can be done. If the signal (or system component) failure is random, the system can tolerate F failures before any end user's signal is interrupted. Where F is about N {1-1 / k} and N is the number of components in the system. If the packet loss rate experienced in each stream is p, then the post-concentration loss rate is p.^k× The number of streams. [0032] In a preferred embodiment, it is desirable to input two (two) input streams to a given concentrator. Of course, as the number of streams increases, the cost increases the network bandwidth for the distribution mechanism. When a multiple input stream is fed to the concentrator (ie output from the splitter), a variant of the invention is to transmit the multiple data stream by incorporating a given encoding scheme into the splitter / concentrator. Regain some of the bandwidth used for. In this variant, when a stream is output from a given device (eg, a splitter), it is encoded using a coding routine. When the stream enters the underlying concentrator, it is decrypted and processed as described above. When the coding technique is used, the copies of the data stream output from the splitter do not have to be identical. Rather, the copy can fluctuate as a result of the coding algorithm used in a given device. [0033] In the examples described, a useful coding scheme is the Rabin Information Distributed Algorithm (Rabin). Information Dispersal Algorithm). In information distribution, packets are broken down into sets of subpackets, and the subpackets are sent along the edge disjoint path to their common destination in a greedy like fashion. The advantage of information distribution is that distributing large packets into a large number of small subpackets tends to result in a very balanced communication load on the edge of the network. As a result, the maximum congestion of the network is likely to be very low, and there is a good chance that packets will not be delayed at all. Furthermore, if the packet content is redundantly encoded into a set of subpackets, the information distribution algorithm becomes more fault tolerant. This is because in order to reconstruct the original packet, only a part of the subpacket needs to be delivered to the destination. More detailed information about the information distribution algorithm can be found in the following literature: "Introduction to Parallel Algorithms and Architecture, Arrays, Trees, Hypercubes" by Layton, Morgan Kaufmann (Leighton,)<u style="single">Introduction To Parallel Algorithms and Architectures: Arrays, Trees, Hypercubes</u>, Morgan Kaufmann (1992), Section 3.4.8). This is incorporated herein by reference. Therefore, in the embodiments described, the Rabin information distribution algorithm is performed in a given splitter and given concentrator. [0034] As mentioned above, the concentrator for use in the present invention is a software program that can be run on a computer. FIG. 5 shows a representative concentrator 500 including a manager routine 502, an array manager process 504, and a set of stream concentration processes 506a-n. As described in the above modifications, one or more coding / decoding routines 508 may be provided. For operation, the manager routine 502 is initialized when the concentrator is started. When the input data stream is received, manager routine 502 initiates an instance of stream concentration process 506. Stream Concentration Process 506 manages to marge individual data streams into streams and then output them from the concentrator. The array manager process is called by manager routine 502 to establish an array (or other data structure or equivalent work area) for use by a given stream concentration process 506. By using the multiple stream concentration process, different content streams can be concentrated using a given concentrator under the control of the manager routine. [0035] The fault-tolerant distribution mechanism of the present invention may be realized in a conventional client-server distributed computing environment. Figure 6 shows a client-server environment in which a streaming framework can be implemented. In this example, multiple internet client machines 610 may be connected to computer network service provider 612 via a network such as telephone network 614. Service provider 612 interfaces the client machine 610 to the rest of network 618, and the rest of network 618 may include multiple web content server machines 620. Network 618 typically includes other servers (not shown) for domain name deduction, routing, and control of other control functions. Client machines typically include a set of known internet tools. Various known internet protocols are used for these services. [0036] A given client machine and server can communicate over the public internet, intranet, or any other computer network. If desired, the given communication may be carried out over a confidential connection. Thus, for example, the client may communicate with the server using a network security protocol such as Netscape's Secure Sockets Layer (SSL) Protocol (R). [0037] Typical clients are personal computers, laptops, internet devices, or popular arithmetic units based on x86- (R), Pentium (R)-, power PC (R), or RISC (eg PDAs or palm computers). ). Clients include operating systems such as Microsoft Windows 98 (R), Microsoft NT (R), Windows CE (R), or Palm OS (R). Clients include a set of internet tools, including web browsers such as Netscape Navigator (R) or Microsoft's Internet Explorer (R), with support for Java Virtual Machine (JVM) (R) and application plug-ins or helper applications. .. [0038] Typical web servers include a processor 622, an operating system 624 (eg, Linux, Windows NT (R), Unix (R), etc.), and a web server program 626. OS 624 and web server program 626 are supported with system memory 623 (eg RAM). Of course, any convenient server platform (eg Apache (R), WebSphere (R), etc.) may be supported. Even if the server includes an application programming interface (API) 628 that provides extensions that allow application developers to extend and customize core functionality through software programs including plugins, CGI programs, servlets, etc. Good. [0039] A typical concentrator is a computer or computer platform with support for operating system and network connectivity. So, for example, typical concentrators run computers: Windows NT (R) (Intel and DEC Alpha (R)), IBM AIX (R), HP-UX (R), Sun Solaris (R) (SPARC and). Includes Intel Editions), Novell's NetWare (R) or Windows 98 (R). [0040] FIG. 7 shows the realization of the present invention. System 700 includes, for example, a pair of relay servers 702 and 704 residing in Streaming Video Production Facility 706. Each of these servers has, for example, two (two) network cards. One set of them is wired on a common network together with the encoder machine 708, and the other set is connected to the Internet 710. The encoder machine 708 encodes the video and audio data and sends the encoded packets to the broadcast address of the network shared with the relay servers 702 and 704. The relay server big-ups the packets and resends them, for example, over two dedicated T-1 lines to two different data centers 712 and 714. From these two data centers, the content extends to two more data centers, 716, 718, 720, and 722. In this way, four copies of each data packet are created. Each of the four data centers sends a copy of each packet to each of a set of regions 724a-n. Each server area 724 contains a set of hosting servers 726a-n. Each region contains a concentrator 728, which deduplications and sends a single remaining stream to each server 726 within that region. By no means limiting, the server space may include part of a distributed content hosting system such as Akamai's FreeFlow (R), a high-performance, fault-tolerant web content delivery service. [0041] As described above, the present invention may be realized by software that can be executed in a processor, that is, as a set of instructions (program code) in a code module resident in a random access memory of a computer. Until the computer requires it, the set of instructions may be stored in another computer memory, for example, in hard disk drive or in removable memory, or downloaded via the internet or other computer networks. May be good. [0042] Moreover, while the various methods described above are conveniently implemented on general-purpose computers that are selectively booted or reconfigured by software, such methods are configured to perform hardware, firmware, or the required method steps. It will also be understood by those skilled in the art to the extent that it may be carried out on a more dedicated device. [0043] Although our invention has been described above, what is novel and what we want to secure is stated in the claims. [Simple explanation of drawings] FIG. 1 is a schematic representation of a known streaming architecture in which a source signal is transmitted to multiple end users or viewers using multiple splitters. FIG. 2 is a schematic diagram showing the inventional use of a concentrator according to the teachings of the present invention. FIG. 3 is a flow chart of the first type of processing routine that can be used in a concentrator. FIG. 4 is a flow chart of a second type of processing routine that can be used in a concentrator. FIG. 5 is a block diagram of a concentrator used in the present invention. FIG. 6 is a block diagram of a client-server computing environment in which the present invention can be executed. FIG. 7 is a block diagram showing the realization of the present invention.