WO2010102926A2 - Verfahren und system zum bereitstellen von medieninhalten für eine mehrzahl von knoten in einem datennetz - Google Patents

Verfahren und system zum bereitstellen von medieninhalten für eine mehrzahl von knoten in einem datennetz Download PDF

Info

Publication number
WO2010102926A2
WO2010102926A2 PCT/EP2010/052606 EP2010052606W WO2010102926A2 WO 2010102926 A2 WO2010102926 A2 WO 2010102926A2 EP 2010052606 W EP2010052606 W EP 2010052606W WO 2010102926 A2 WO2010102926 A2 WO 2010102926A2
Authority
WO
WIPO (PCT)
Prior art keywords
node
nodes
sections
media file
video
Prior art date
Application number
PCT/EP2010/052606
Other languages
English (en)
French (fr)
Other versions
WO2010102926A3 (de
Inventor
Alexander Lipfert
Quirin Hofstätter
Original Assignee
Technische Universität München
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Technische Universität München filed Critical Technische Universität München
Priority to US13/256,310 priority Critical patent/US20120084392A1/en
Publication of WO2010102926A2 publication Critical patent/WO2010102926A2/de
Publication of WO2010102926A3 publication Critical patent/WO2010102926A3/de

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks

Definitions

  • the invention relates to a method and system for providing media content to a plurality of nodes in a data network, wherein the media contents comprise one or more media files and the nodes are addressable via addresses in the data network.
  • VoD streaming Video on Demand
  • a distributed peer-to-peer network whereby all the videos to be provided are divided into sections and the sections are provided decentrally via the peer-to-peer network nodes, since a large number of videos are managed via the decentralized network , the search for a correspondingly streaming video file is complex and leads to delays in playing the video.
  • the object of the invention is to provide a method and a system for providing media contents for a plurality of nodes in a data network, which Without changing the structure of the data network, it will be possible to provide the media contents quickly and reliably.
  • a decentralized structure administered via one or more first nodes is formed by dividing the respective media file into a plurality of sections and comprising each of the sections with an identity value from an identity interval successive identity values are assigned, wherein the one or more first nodes are each responsible for a sub-interval from the identity interval and thereby for a subset of sections from the respective media file.
  • Second nodes are, in particular, those nodes in which, depending on certain criteria, it can be assumed that these second nodes actually contain the corresponding sections of the media file in their memory. Nevertheless, the availability of the sections in the second node need not be guaranteed.
  • the downloading of at least a portion of a respective media file via a corresponding receiving node is according to the invention by means of appropriate requests to the decentralized structure.
  • the corresponding receiving node calls the addresses of second nodes comprehensively by means of one or more requests to the first nodes in the decentralized structure of the respective media file. at least part of those second nodes that are provided for providing the portions of the at least part of the media file. Subsequently, portions including the portions of the at least a portion of the media file are downloaded by the receiving node from at least a portion of the second nodes whose addresses have been retrieved.
  • downloading a section does not necessarily mean that the total amount of information in a section needs to be downloaded, but rather only a certain portion of the section can be downloaded, for example, such that the content of the section in reduced quality is provided.
  • the inventive method is characterized in that for each media file a separate decentralized structure is formed, which takes over the management of the sections of the media file. It is thus formed for each media file a manageable distributed network, which allows a fast and efficient downloading of the media file by a corresponding receiving node.
  • a preferred application of the method according to the invention is its use in a packet-based data network, in particular the Internet.
  • the addresses of the nodes are in particular IP address.
  • the method is preferably implemented in the application layer of the OSI reference model as an application layer multicast (ALM) protocol.
  • ALM application layer multicast
  • a respective media file contains a playable media stream, in particular an audio and / or video stream.
  • the sections of the media file represent temporally successive sections of the media stream, wherein the identity values of the identity interval in the playback order of the media stream are assigned to the sections. That is, the larger the corresponding identity value, the later the playback time of the section in the media stream.
  • the method according to the invention is preferably used for the so-called streaming of the media stream, in which a receiving node plays the downloaded portions of the media stream in parallel with the download.
  • the decentralized structure provided according to the invention for managing sections of a single media file can be implemented, in particular, with known peer-to-peer protocols or as a ring structure in the data network.
  • the ring structure of the well-known from the prior art Chord ring is used.
  • the mechanisms of a chord-ring for providing and searching for resources can then be used in the method according to the invention.
  • a receiving node which downloads portions of a media file, also makes them available to other nodes. This is done by storing the receiving node with its address as the second node in the corresponding first node, which is responsible for the sections downloaded from the receiving node.
  • a mechanism for protection against failure of first nodes, thereby ensuring reliable downloading of media files even in the event of failure of a first node.
  • the number of second nodes stored in a respective first node is replicated in other first nodes, in particular at least in a neighboring node, which is responsible for a subinterval which follows the subinterval for which the respective first node is responsible.
  • the number of second nodes stored in a respective first node is stored in the form of one or more lists.
  • the list or lists comprise one respective first node one or more first and / or second lists. Both the first and second lists may be used to download portions corresponding to these lists at second nodes.
  • a first list contains second nodes with sections permanently available for download by other nodes, wherein the availability of the respective second node is checked by regular message exchange of the second node with the respective first node. This ensures the permanent availability of sections of a media file in the data network.
  • a second list comprises those nodes which have retrieved addresses from second nodes at the respective first node within a predetermined past period of time. A second list thus contains nodes which, with a certain probability, can be assumed to also contain correspondingly requested sections of a media file, since the nodes in the second list have themselves also requested these sections.
  • a receiving node in a preferred variant of the invention downloads sections of second nodes from the first and / or second list, wherein the sections to be downloaded are selected according to one or more predetermined criteria, in particular at random. That is, a receiving node, by means of a request, searches for a corresponding first node that manages a randomly selected portion and polls the first or second list from that first node. He then downloads the corresponding section from a second node from the first or second list. The section to be downloaded does not have to be a section that the receiving node is required to play the media file that it has just downloaded.
  • a distribution of further sections in the data network also takes place in the background, whereby permanently available sections are made available at several points in the network, so that a reliable download from various download sources in the network is made possible.
  • second nodes from the first list are more preferred for downloading a portion to be played the closer the section to be played is at the current playback time of the media file. In this way, it is ensured that sections of a media file to be played soon are downloaded from reliable sources which permanently make the corresponding sections available. This avoids delays when playing the media file.
  • a receiving node can participate not only in the distribution of portions of a media file but also in the management of the ring structure.
  • a receiving node is included as a first node in the decentralized structure of a respective media file as a function of one or more criteria by assigning the responsibility for a subinterval from the identity interval to the receiving node.
  • mechanisms known from the prior art for accommodating nodes in decentralized structures may be used. Such mechanisms are known, for example, for chord rings.
  • the criterion or criteria for receiving a receiving node into the decentralized structure are configured in such a way that a maximum number of times is sought for a receiving node after a subinterval of the identity interval whose responsibility can be assumed by a new node in the decentralized structure no sub-interval is found after the maximum number of times, the receiving node is not included as the first node in the decentralized structure. It is also possible that only those receiving nodes are included in the decentralized structure, which can provide a predetermined minimum size of resources. In this context, resources are to be understood as meaning in particular correspondingly available upload rates or storage capacities or computing capacities of the node. This ensures that only nodes with sufficient capacity participate in the management of the decentralized structure. to take. Thus, an overload of nodes is avoided and improves the reliability of the process.
  • the receiving node to be included in the decentralized structure is assigned a responsibility for a sub-interval at random or according to a predetermined pattern, wherein the predetermined pattern is configured such that more nodes are responsible for portions with smaller identity values than for sections with larger identity values.
  • the predetermined pattern is configured such that more nodes are responsible for portions with smaller identity values than for sections with larger identity values.
  • a respective first node knows the neighboring node, which is responsible for a subinterval which follows the subinterval for which the respective first node is responsible, in the direction of higher identity values the address of the neighboring node is transmitted by the respective first node in a retrieval of the addresses of the second node to the receiving node.
  • the number of requests is reduced because a receiving node already receives the information about the address of the corresponding neighboring node, the second node manages, of which sections to be subsequently played down can be downloaded.
  • the respective first node has further information about the adjacent node, which are transmitted to the receiving node in addition to the address of the neighboring node and from which the receiving node determines the sub-interval for which the neighboring node is responsible. This allows the receiving node all at once Querying addresses of the second nodes for all sections for which the neighboring node is responsible.
  • sections are downloaded by a receiving node in dependence on one or more priorities assigned to the sections, with sections with higher priorities being preferred during the download.
  • a receiving node When downloading a media stream to be played back, a receiving node is preferably given a first time interval, whereby the receiving node downloads from its current playback time of the media stream portions that are in the played media stream in the first time interval after the playback time with higher priority than other portions , In this way, a prioritized download takes place so that sections to be played soon are preferred for downloading. This ensures a continuous playback of the media stream.
  • sections within the first time interval which contain the current playback time are downloaded with a higher priority than the other sections in the first time interval.
  • a second time interval which is greater than the first time interval, is predetermined for a receiving node in addition to the first time interval, the receiving node starting from its current playback time of the media stream sections which in the played media stream in the second Time interval after the play time and outside of the first time interval are lower priority than the sections within the first time interval downloads down.
  • a receiving node downloads portions for provision as permanently available portions of lower priority than the portions of the first or second time interval after the current playback time. This takes into account that downloading sections for permanent Provisioning is completely time-critical because these sections are not needed to play the currently downloaded media file.
  • the sections of a media file are each divided into smaller sections.
  • the entire section but only a selection of sections from the section can be downloaded.
  • the subsections of all sections of a respective media file are grouped into multiple channels representing different quality levels of the media file. In this way, through targeted downloading of subsections of a channel, a quality-adapted reproduction of the media file, in particular a quality-adapted playback of a media stream, is made possible.
  • a receiving node for processing the subsections reads information about the subsections, in particular with regard to the assignment of subsections to quality levels, from an information file.
  • a receiving node can get the information, which quality or language and the like he can play and which sections he must select this.
  • information about a respective media file is provided in a meta-container, which can be downloaded from a receiving node.
  • the user of the receiving node can be provided with corresponding information about the media files provided, whereby the user can use this information to decide whether the downloading of the media file is interesting for him, which quality and possibly which language he wishes to select.
  • a plurality of media files via a searchable index in the data network provided, wherein for each index at least a part of the addresses of the first node of the formed for the respective media file decentralized structure is deposited. Consequently If a receiving node, which has found a media file determined via the index, immediately receives information about access points in the ring structure, so that the receiving node can immediately start the process of downloading the media file by addressing one of the access points.
  • the invention further relates to a system for providing media content to a plurality of nodes in a data network, wherein the media contents comprise one or more media files and the nodes are addressable via addresses in the data network.
  • the system manages the plurality of nodes such that each variant of the method described above can be carried out with the system.
  • the system is preferably implemented by appropriate software on the individual nodes, the software allows providing or downloading media files according to the inventive method.
  • the invention relates to a node for use in the method according to the invention, wherein the node is designed such that it operates as a first node or as a second node or as a receiving node when operating in the method.
  • FIG. 1 is a schematic representation of the provision of a video file via a ring structure according to an embodiment of the method according to the invention
  • FIG. 2 is a detailed view of the ring structure shown in FIG. 1, illustrating the lists managed in the ring structure;
  • FIG. 3 shows a schematic representation of a division of the sections of a video file into smaller sections according to an embodiment of the invention;
  • Fig. 4 is a flow chart illustrating the search of a node for portions of a video file in a ring structure of Fig. 1 and Fig. 2, respectively;
  • FIG. 5 is a schematic representation of the streaming of a video file in a corresponding node receiving the video file in accordance with an embodiment of the invention.
  • the data network represents a packet-based data network which uses the IP protocol on layer 3 of the OSI reference model.
  • the nodes of the data network are corresponding computers on the Internet, which can be addressed via IP addresses.
  • the peer-to-peer structure described below is implemented on the application layer of the OSI reference model in the form of an ALM protocol (Application Layer Multicast).
  • ALM protocol Application Layer Multicast
  • media content is provided in the form of media files, and in particular in the form of video files for download by nodes.
  • the media content is not limited to videos, but may include any other content, such as only pure audio files.
  • the media file is provided in the embodiment described below by a corresponding video provider who, via the Internet, makes free or, for a fee, videos for streaming to other radio stations. of the network.
  • a corresponding client software In order for a node to search for or download videos, a corresponding client software must be installed on the node.
  • the software is preferably provided by the video provider and is designed such that all the nodes using this software enable the distribution according to the invention and the downloading of videos according to the invention.
  • the method according to the invention can also be used by any other persons or institutions for providing media content.
  • companies may provide their self-produced material for their products based on the method of the invention and also individuals may exchange their own video material with other users.
  • a commercial video provider provides video files for download by users via a server SE.
  • the users are represented by corresponding nodes, which represent computers that are operated by a user and have an Internet connection, so that they can be addressed via a corresponding IP address.
  • a respective client software is installed on the nodes, via which the services of the video provider are used. So that the provided video material can also be found by other nodes, the video provider indexes the corresponding video files as part of an index process.
  • this index process runs as a central process on the server SE.
  • this process is also the possibility that this process is used as a distributed process, so that various powerful computer nodes are involved in this process.
  • the index process generates a corresponding table T in which each indexed video is assigned an index number is, in Fig. 1 by way of example the index numbers 1, 2 and 34 are indicated.
  • Each index is assigned a hash function generated file hash, on the basis of which the individual video files can be distinguished and after the search for video files can be searched.
  • the illustrated table T it is further indicated for each index which active nodes belong to a ring structure which is assigned to the file.
  • the ring structure will be explained in more detail below and is indicated in Fig. 1 by the reference symbol R.
  • a node can search for corresponding video files, with the node for a found video file also being given corresponding active nodes, which serve the searching node as entry points for downloading the video.
  • a decentrally managed ring structure R is formed for each video file, wherein the assignment of a video file to a ring structure is indicated schematically by the arrow P.
  • the corresponding video to be provided is divided into a plurality of sections, which are also referred to below as chunks.
  • Each chunk contains a temporal section of the video file being played.
  • the video file is divided into 32 chunks, which are indicated by correspondingly numbered squares 0, 1,..., 31 and at least partially designated by the reference character C.
  • Each section is thus assigned an identity value from a 5-bit interval of identity values, with a higher number of an identity value representing a later portion of the video.
  • the ring structure shown in Fig. 1 is provided in which each chunk is assigned a position on a 5-bit ring with 32 positions.
  • the chunks C are managed by corresponding nodes, which according to
  • Claim 1 are referred to as the first node. These nodes are those nodes that can also download corresponding video content from other nodes.
  • the nodes using the service of the video provider also participate managing appropriate videos.
  • the nodes using the service of the video provider also participate managing appropriate videos.
  • the node K1 occupies the position 0 of the ring, the node K2 the position 4, the node K3 the position 6, the node K4 the position 13, the node K5 the position 19, the node K6 the position 24, the node K7 Position 27 and node K8 the position 31.
  • Each of the nodes manages the chunks at the position at which he sits, and at all previous positions to the previous node.
  • the node Kl manages the chunk 0, the node K2 the chunks 1 to 4, the node K3 the chunks 5 and 6, the node K4 the chunks 7 to 13, the node K5 the chunks 14 to 19, the node K6 the chunks 20 to 24, the node K7 the chunks 25 to 27 and the node K8 the chunks 28 to 31.
  • the management by the ring structure R by means of the nodes K1 to K8 is preferably carried out based on known peer-to-peer protocols. Particularly preferred here is the known from the prior art Chord ring is used, which provides appropriate mechanisms for managing and searching for resources in the node participating in the ring. However, any other peer-to-peer protocols can also be used to search for nodes within a distribution network for intervals of responsibilities for identity values, and which further provide a mechanism by which new nodes can be included in the distribution network Also, nodes can leave the distribution network again.
  • Each of the individual nodes K1 to K8 in the ring structure R is assigned a number of further nodes of the data network which contain the corresponding chunks for which the respective nodes K1 to K8 of the ring R are responsible. These nodes containing the chunks correspond to the second node in the sense of claim 1 and are managed in corresponding lists, as illustrated in FIG.
  • some positions of identity values of chunks are indicated by means of vertical lines between the nodes K1 and K3, of which only a line with the reference number L is designated for reasons of clarity.
  • the node K2 thereby manages the identity values of the chunks 1 to 4, so that both a PeRL and a PaRL are stored in this node for each of the chunks.
  • the PeRL list for each chunk, all nodes with their node access points (i.e., address and port) are collected, which permanently provide the chunk. As will be explained in more detail below, appropriate mechanisms ensure that there are enough nodes to provide chunks for download permanently. Such nodes include, among others, those nodes that have a complete copy of the video. In this context, permanent means as long as the corresponding node is involved in the network for distributing the videos.
  • Fig. 2 the structure of a PeRL list is shown schematically.
  • the PeRL list contains an entry for each node that permanently provides the corresponding chunk. By way of example, an entry for a node K 'is highlighted. In each entry, the time t is specified at which the corresponding entry was last updated.
  • the corresponding IP address of the node is also specified.
  • the PeRL list also contains nodes which provide a complete copy of the video. These nodes are specially marked. For the constant updating of the entries from the PeRL list, so-called keep-alive messages, which are well known from peer-to-peer protocols, are exchanged between the individual nodes, as will be explained in more detail below.
  • a PARL list for a chunk is also shown schematically in FIG. In the example of Fig. 2, this list contains only one entry for a node K ".
  • nodes are entered which have requested the corresponding chunk to which the PaRL list belongs within a predefined period of time of the PaRL list besides the IP address of the corresponding node, the time t at which the chunk was requested.
  • This PaRL list is not updated with keep-alive messages. Rather, all nodes are entered in the list that have requested the Chunk and are deleted after a certain condition, at the latest after a predetermined period of time, again.
  • nodes from the PaRL list can also be used to download chunks.
  • the ring R according to FIG. 1 or FIG. 2 is used by corresponding streaming nodes SK (FIG. 4), which correspond to the receiving node according to claim 1, for downloading corresponding chunks in succession, the information via the nodes providing the chunks, are retrieved from the ring via the nodes K1 through K8 contained therein.
  • the streaming of the video provided by the ring R through a streaming node is indicated by a corresponding streaming window W in FIG.
  • This window represents a minimal buffering size for streaming nodes, which is filled with chunks to play the video and should remain as full as possible when the video is played.
  • the streaming window W comprises six chunks and the streaming node is just beginning to play the video at position 0.
  • the streaming node preferably always downloads those chunks which lie within the streaming window W, thereby ensuring a delay-free playback of the video.
  • the streaming node Before the actual downloading of a video by a streaming node is started, the streaming node first requires the corresponding download sources, which are contained in the previously explained PeRL or PaRL lists. For this reason, the streaming node makes search queries for the chunk numbers it requires in the ring R, whereby known mechanisms of the chord protocol can be used for this purpose. The search request is directed to one of the access points of the network, which are stored in the table T for the corresponding video to be downloaded.
  • the size of the streaming window indicates how far in advance the video should be downloaded in order to enable a specific playback and to compensate for possible download fluctuations. However, the streaming window should also not be too large, as this is always associated with a play delay until the window is filled.
  • the buffer time specified by the streaming window is directly connected to a corresponding buffer size to be provided in the streaming node.
  • the buffer size to be provided is the product of average playback rate and buffer time. From the buffer size it can then be determined directly how many chunks have to be downloaded in advance to fill this buffer. The number of chunks is in particular the quotient of buffer size and chunk size.
  • Responsibility for a chunk is deposited at a corresponding identity value in ring R, which is managed by a node there.
  • the actual video information is replicated to a great many different nodes, wherein the information which nodes contain the respective chunks is stored in the above-explained PeRL or PaRL lists in the node responsible for the respective chunk.
  • the video file Before a video file is initially put into the network by a node, some preparatory steps must be performed by the initial source node. In particular, the video file must first be checked for its streaming capability. If the file is capable of streaming, the entire file will be stored with an efficient and standardized coder, e.g. recoded based on MPEG-4 / AVC or H-264. Finally, the video is transformed into the selected file structure. To locate the video, a unique video hash value is then formed, and further, characterizing information of the video is collected and stored in a corresponding meta-information container. This container will be explained in more detail below.
  • a new entry is generated for the video in the index list, designated by reference T in FIG.
  • T the index list
  • the information and the metacontainer are filed and checked.
  • the video stream is made public and the list T of access points to the chord ring is created with their IP addresses. Initially, only the initial source node is entered in this list. At certain intervals the list is updated again and again and new, added to the Chord ring addresses added.
  • An Atonk designates a part of the corresponding chunk and is marked with a label. This division is illustrated again in FIG. 3.
  • the upper rectangle R1 shows the transcoding process of the original video file for forming chunks and atonks.
  • the video VF is separated into individual chunks C, of which the chunks with the numbers 0 to 6 are indicated in FIG.
  • Each individual Chunk C is then encoded, whereupon corresponding smaller Atonks AT with assigned Labein A, B, C, etc. are generated in the Chunk.
  • the coding is indicated in FIG. 3 for the chunk with the number 0.
  • Atonks For the formation of the Atonks a predetermined Atonk map is used, which is designated in Fig. 3 with AM.
  • the labels of the individual chunks continue throughout the video file, i. each chunk contains Atonk's AT with corresponding labels A, B, C, etc.
  • Channels can be formed by selecting the labels accordingly, whereby all the atonks of a label are assigned to one channel. Depending on the selected label, only the Atonks will be transferred according to the selected label when downloading a chunk.
  • a transmission in corresponding video streams Vl or V2 or V3 for Atonks with the Labein A or B or C is indicated.
  • the decoding of the correspondingly downloaded Atonks is reproduced with a decoder of the streaming node.
  • the individual downloaded streams can then be assigned to the corresponding Labein A, B, C, etc., based on the same Atonk map AM already used in coding.
  • the individual labels represent different quality levels of the video.
  • the label A is in the lowest quality level and by successively adding the chunks with the label B, C, etc., the video's playback quality is further increased. By multiplexing the chunks with the different lables, a quality-adapted playback of the video can thus be achieved.
  • I-frames which appear as still images. They consume the largest storage space and therefore occur in the coding only at predetermined intervals. Between individual I-frames are the much more lossy coded P-frames and B-frames. These can only be calculated using previous I frames or other P frames during playback. If you assign all frames of a sort within a chunk to an Atonk label, you get three video channels.
  • the I-frame channel is required when playing in any case and provides a kind of basic quality. By adding the channel with the P-frames and the channel with the B-frames, the quality of the video can be increased accordingly.
  • Another type of channeling based on atonks is the so-called description channeling.
  • This channeling allows the subdivision of the video material in any number of channels.
  • a method known from the prior art is used, which is referred to as "Multiple Description Coding.”
  • This method generates different descriptions of one and the same video material, wherein a layer coder creates a base layer and any number of extension layers
  • the basic layer is always required for playback - analogous to the image channeling of the I-frame channel - and any number of quality levels can then be introduced via the extension layers If a corresponding Atonk label is assigned, the option of introducing any number of channels and thus quality levels, as already indicated in FIG. 3, is obtained.
  • a so-called resolution channelization can be used in the generation of the A-tonks. This channeling creates a very large number of channels by dividing the video material. Repeated subsampling produces a reduced resolution of the video. After each sub-scan, the old resolution is restored for each frame of the video by interpolation. The resulting interpolation error continues to be used, the interpolated images are discarded, and the subsampling process is repeated based on the resolution level being used. These steps are repeated until the desired minimum resolution has been achieved.
  • the version of each image reflects the base channel. Each previously performed sub-sampling stage supplies the material for an extension channel. The respective interpolation errors of the individual images are transmitted via them.
  • error values have a very high degree of redundancy and can therefore be compressed very well.
  • the receiver in the form of the streaming node can reconstruct an almost error-free original image with the aid of the base image and the associated interpolation errors. In this way, you can generate many quality levels of the video.
  • Chunks and Atonks differ in several characteristics. Downloaded chunks can be played independently, this is only partially possible with Atonks. borrowed. Atonks can have very different sizes, while chunks are the same size. Depending on the encoding used, not all Atonks need to be downloaded to play a chunk. The video, however, comes to a halt if at least the most necessary parts of all chunks are not downloaded.
  • Atonk map which is stored at the beginning of a chunk and with each identity value in the Chord-Ring.
  • the Atonk map gives instructions on which Atonks need to be downloaded in order to maintain a certain quality or which Atonks are the most important ones.
  • Atonks can contain video or audio information and are labeled. The meaning of a label must be defined in the A-tonk map.
  • the separation of a video into chunks can take place before or after the coding and the conversion of the video into the desired file structure, depending on the coding used.
  • the file is then capable of streaming and suitable for distributed organization in the context of the ring structure R shown in FIG. 1 or FIG. 2.
  • a hash value is generated for the video to be provided. For this, characterizing values of the video, such as e.g. Setting date, video size, file structure or the like can be used.
  • Metacontainer represents an object in which several metadata are collected and stored for a video stream.
  • the metafiles themselves can not be changed, but new ones can be added to the metacontainer and sometimes metadata can be removed as well.
  • the metafiles store various characterizing information about the video file.
  • further audio tracks of a video may also be stored in a metacontainer.
  • the metacontainer is composed of a video metafile, a content metafile, an audio metafile, and optionally further audio tracks.
  • the video metafile collects information about the video file and the structure of the video stream. In particular, this information includes the hash of the video provided, the size of the entire video file without audio, the number and size of the video chunks, the structure and size of the atonks, chapter jump marks, quality level characteristics, and the video coders used.
  • the content metafile characterizing information about the video is collected. These also serve users as a clue to the video prior to playing the video.
  • the content metafile includes the hash of the video, a video brief description, information about the actors, the producer, the publisher, and the genre of the video, and, if appropriate, other characterizing information.
  • An audio metafile collects information about the soundtrack.
  • this file includes the hash value of the video, the size of the entire soundtrack, the number and size of the sound chunks, the audio encoders used for the soundtrack, and audio metadata such as voice, quality of the audio track, and the like.
  • the client software for carrying out the method according to the invention is started on the corresponding computer of the streaming node by a user.
  • the user can select a particular provider to download his video.
  • the software then contacts the previously known address of the provider server, which is designated in FIG. 1 by SE.
  • a current list of information about the existing video streams can be downloaded to the streaming node getting charged. If the user of the streaming node is looking for a particular video, he can also sort the video streams according to certain criteria such as genre, actor, language, and the like.
  • the search runs either locally on the straming node, in which case the complete list of available video streams must be downloaded. It is also possible to send a request to the provider's server, which will then provide a list of possible outcomes.
  • the information for this is extracted from the previously described MetaContainer, wherein in particular the content metafile is used by the user of the streaming node for decision making.
  • the selection of the currently available access points stored in the "Active Nodes" column for the corresponding video in the list T of Figure 1 is downloaded and before the actual streaming begins the streaming node first checks whether it can reach at least one of the access points, and whether the corresponding chord ring, which manages the chunks of the video, is available there, and then checks whether and with a compatibility check which restrictions the video stream can be played on the streaming node.
  • the streaming node queried in which language and quality the streaming should be considered. Only those variants are available that are deemed to be satisfiable after the compatibility check and are available according to the meta-container. Alternatively, the user of the streaming node, depending on the provider, if necessary, also select the complete recording, in which the stream is recorded and can be played only after complete download.
  • a streaming node that wants to download chunks from the corresponding chord ring is also part of the chord ring under certain conditions. That is, a streaming node is also involved in managing video chunks.
  • identity value and thus which identity interval of the streaming node is assigned.
  • the streaming node independently selects an identity value from the chord ring by random procedure and checks its assignment in the ring with a special search. If the corresponding identity value is already occupied by a node, this process repeats until a vacant location is found.
  • the process may be aborted after a predetermined number of requests, in which case the streaming node does not become part of the chord ring.
  • the identity value to be occupied by the streaming node is chosen according to a fixed pattern. It can be taken into account in particular that often only the first few minutes of a video are played by users. In many cases, a user already determines at the beginning of the video that he does not like this video and stops streaming. In this way, higher loads are created for ring positions with lower identity values than for ring positions with higher identity values. This fact can be taken into account by an appropriate entry pattern.
  • the streaming node knows the entry pattern in advance. If appropriate, this pattern could also be stored in the meta-container of the video. The pattern describes in which fixed order the positions in the corresponding chord ring are to be occupied.
  • the streaming node sends a special request to the first identity value of the pattern. Is this identity value occupied, The requested node forwards the request to the next identity value in the pattern. This repeats until the first free position is found where the streaming node then connects to the ring.
  • the search can also be aborted if a predetermined number of requests has not led to a vacant node.
  • the responsibility extends from the position at which the streaming node joins the ring up to the position of the node before it in the node.
  • the corresponding PeRL or PARL lists of the respective identity values must also be kept up to date and search queries must be answered or forwarded.
  • a redundant copy of the information collected in a node of the ring is created so as not to risk loss of information in the event of a node failure.
  • the collected information of a node is stored redundantly in the successor node and updated at regular intervals with the original. If a node fails out of the ring, the successor node can immediately take over the responsibility of the failing node. An approximately current he already has available a version of the PeRL or PaRL lists. The administration in the network is thus largely ensured even with frequent node failures.
  • the streaming node does not join the ring.
  • the attempt to enter the ring can be broken off if a certain number of attempts at entry due to occupied ring positions has failed.
  • Such nodes then take over no management function in the ring.
  • nodes must store a higher number of chunks to be permanently provided, wherein the permanent storage of the chunks takes place parallel to the streaming, as will be explained in more detail below.
  • the entry of a streaming node in a ring can also be tried again at regular intervals. If then the number of nodes in the ring has dropped, the entry of the node in the ring is possible.
  • the entry into the ring can also be made dependent on properties of the node. For example, only those streaming nodes can join in the ring, which exceed a certain resource size, the resources in particular relate to the available upload rate or computing capacity or the available memory of the node. All streaming nodes that have not joined the ring update at fixed intervals a list of access points in the ring, an updated list, for example, based on the list T of FIG. 1 can be downloaded from the video provider.
  • a streaming node should participate in the organization of the corresponding chord ring by joining the ring. However, it may also happen that the streaming node does not become part of the ring. In contrast, in the embodiment described here, it is ensured that, in any case, a streaming node participates in propagating the video by providing chunks permanently available to other nodes. This ensures that each streaming node is also forced to provide its upload capacity to other nodes. Nodes that permanently provide certain chunks are, on the one hand, the nodes that have a complete copy of the video, and thus permanently contain all the chunks. Furthermore, all the nodes that stream the video themselves assume replicating responsibility for a certain number of chunks as long as they are connected to the network. Thus, a replication of the chunks is achieved in a plurality of nodes, whereby the resilience of the network is increased.
  • a node fails in the network, only a small part of the chunk availability is lost if the chunk replicates accordingly. This leads to stability and reliability.
  • the permanent chunk replication will go through a predetermined number of times per replicated chunk.
  • the replication of a chunk performed by a streaming node runs according to a defined scheme.
  • the streaming node selects a chunk number from the ring from which it is currently streaming a video file. The selection can be done randomly.
  • the streaming node sends a request to the node found, with which the PeRL and PaRL lists of the corresponding chunk Number to be requested. Upon receiving these lists, the chunk will be downloaded complete with all audio tracks and the corresponding meta-container of the video.
  • a streaming node As soon as a streaming node has completely downloaded a new chunk to be replicated, it lets itself be entered in the PeRL list of the corresponding node, which is responsible for the chunk in the chord ring. In order to keep this list up to date, so-called keep-alive messages are exchanged at regular intervals. To do this, even after the streaming has finished, the streaming node sends a message to each chord node responsible for the identity value, telling them that the replication is still available. Since he already knows the address of the identity value node, the keep-alive mechanism usually consists of a simple message exchange. If the responsibilities in the Chord-Ring have not changed, the message will be sent back. Otherwise, a search for the chunk number must be made in the ring, and after the resolution, the keep-alive messages must be sent again to the new address.
  • a streaming node requests corresponding PeRL or PARL lists and downloads the chunks from the nodes listed therein.
  • a user of the streaming node wants to start the video to be streamed right from the beginning. none the despite this, in the method described here, a user may start the video at a point other than at the beginning, for example, if he has already seen the beginning of the video. In both cases, the user-selected starting point of the video is to be converted into a corresponding chunk number whose chunk is to be downloaded first.
  • a node that is brand new in the streaming network will start with chunk number 0.
  • the chunk numbers must be calculated directly after each selection. This can be achieved in a simple manner, since the number and size of the chunk as well as the length of the stream via the meta-container described above is known.
  • the streaming node After the chunk number of the chunk to be downloaded first has been determined via the meta-container, the streaming node searches the corresponding identity value in the chord ring.
  • the well-known Chord search mechanisms are used, the search query being appropriately passed between the Chord notes and processed until the Chord node is found.
  • the corresponding replication lists of the Chord node, the meta-container of the video, and the Atonk map are returned in response to the streaming node.
  • the responsible Chord-Rnoten adds further information about the current Chord-Ring structure.
  • the additional information insertion mechanism is hereafter referred to as "sucessor piggyback", with the following information appended to the response message: the own address of the responsible chord node, - the identity value or position, which is the responsible chord node.
  • Chord ring occupies itself; the address of the immediate successor node in the chord ring; the identity value or position occupied by the immediate descendant node in the chord ring.
  • the streaming node can identify which chord node is responsible for the next chunk number to be requested in the chord ring and which address that node possesses. In this way, it is achieved that a streaming node does not have to make another request for successor nodes in the chord ring for downloading new chunks, since it already knows the successor node in the chord ring. This reduces network traffic.
  • FIG. 4 once again shows in detail the download of the PeRL or PaRL lists according to the successor piggyback method.
  • the PeRL and PaRL lists are commonly referred to as replication lists.
  • the diagram of Fig. 4 is based on the chord ring R shown in Figs. 1 and 2, respectively. It is further assumed that the stream at the beginning of the video, i. at position 0, should begin.
  • step S1 the streaming node SK directs a search request to the chord ring R for finding the position 0.
  • the streaming node is returned with the address of the node K1 in step S2.
  • the streaming node then sends in step S3 a request for the replication lists for the chunk 0 to the node K1.
  • the node K1 answers this request in step S4 by sending the corresponding replication lists together with the information about the successor node K2 to the streaming node SK. Subsequently, the streaming node SK can then download the corresponding chunk 0 from one or more of the nodes from the replication lists.
  • the streaming node requests directly from the successor K2 the corresponding replication lists of the chunks for which the successor node K2 is responsible. These are the replication lists for chunks 1, 2, 3 and 4. For these chunks no further search queries in the chord-ring are necessary anymore.
  • the node K2 then sends back the corresponding replication lists and information about the successor node K3 in step S6, whereupon the downloads are also initiated for this purpose.
  • the method continues in that the streaming node SK in step S7 directs a corresponding request for replication lists for the chunks 5 and 6 to the successor node K3, whereupon in turn can be transmitted to the streaming node SK and the download of the next chunks can begin.
  • the permanent transmission of the address and the chunk position of the successor node makes it possible to dispense with multiple search requests to the chord ring, since it is always known to the streaming node which successor node the next chunk to be downloaded managed.
  • a streaming node views the video in sequence, it shifts in the chord ring of FIG. 1 or FIG. 2 clockwise from identity value to identity value without having to place another search in the chord ring ,
  • the node is also informed about current changes, such as changes to the responsibility in the Chord-Ring. Only when the node jumps in the stream or a connection to one of the chord nodes fails, a new search request must be put into the ring.
  • PeRL or PaRL lists do not grow to any particular size. It is not a problem in this case, these lists completely spread. From a certain number of nodes involved in the distribution of the video, it is no longer advisable to distribute the complete lists for continuous distribution. This is not necessary either, as a streaming node selects for download only a small number of sources from which it downloads the chunks.
  • the PeRL list is no longer completely propagated to entries from a certain size. Rather, the chord node from which the list is requested selects only a subset of random sources and sends their information to the streaming node. However, care should be taken that each request is served by other sources. For example, the Chord node might note in the PeRL list how often a source has already been sent. This ensures a good uniformity of the sources used for download. Unlike the PeRL list, for the PaRL The list in the embodiment described here requires that this list be transmitted in its entirety to each streaming node, as described in more detail below.
  • a streaming node always selects only the soundtrack and the video quality it desires, i. the corresponding Atonks, of the streamed video.
  • the streaming node is automatically entered as the source in the corresponding PaRL list of the requested chunk. For this the address and the time stamp are stored.
  • the corresponding chord node in whose PaRL list the streaming node is entered, has no information about which atonks and whether the currently registered node has downloaded anything at all.
  • no keep-alive messages are exchanged to check the sources, as is the case with the PeRL lists.
  • nodes are kept in which there is only a high probability that they can at least partially own and provide the chunk according to the PaRL list.
  • the PaRL list should always be distributed completely, it must not be too large. In order to achieve this and at the same time to increase the availability probability of the sources from the PaRL list, some limiting measures are used in the embodiment described here.
  • nodes from the PeRL list are not included in the PaRL list.
  • old entries in the PaRL list are deleted after a fixed time has expired.
  • a streaming node that encountered an unavailable node in the PaRL list during the download reports the lack of availability of the node to the appropriate chord node. This deletes the entry after having checked this yourself.
  • the PaRL list is still limited by a maximum size of entries, and if this value is exceeded, the oldest entries are deleted to make room for new entries in the PaRL list.
  • the above measures ensure that the PaRL list is always kept as small as possible. It also increases the likelihood that the nodes in the PaRL list really have the chunk, because old ones are deleted after a fixed time has expired and the unavailability of nodes is reported to the chord ring. Furthermore, limiting the PaRL list to a maximum size, even for large meshes, guarantees that the corresponding chord root in the ring will never be overloaded.
  • the use of PaRL lists offers some advantages, as explained below.
  • This can also be referred to as backward buffering, since the chunk moves backwards in relation to the playback time.
  • the backward buffer is used in the event that the user wants to play a scene again immediately after playing.
  • the chunk can be offered even longer via the PaRL list for downloading for other nodes.
  • the size of the backward buffer may correspond to the commonly used buffer represented by the streaming window W in FIG.
  • the backward buffer may even contain the entire previously played stream. This ultimately depends on the available space.
  • the use of the PaRL list in combination with the just-described backward buffering offers advantages, as illustrated by the following examples.
  • the streaming node X starts playing at the chunk number 0 which it has already downloaded.
  • the streaming node is in the buffer build phase with a buffer size of six chunks. So he downloads the chunks 1 to 5 and saves them in the buffer.
  • the node X is thus entered in the PaRL lists at the identity values 0 to 5. His playtime now moves from Chunk number 0 to Chunk number 1.
  • the video stream is served from the buffer.
  • Another node Y also enters the network and also starts streaming at the chunk number 0. Since X is in the PaRL list of the chunk number 0, the node Y can now down the chunk 0 from the node X. load and play.
  • node B may also load chunks 1 through 5 from node X for buffering.
  • node Y downloads all chunks 1 through 5 from node X.
  • the video quality of the chunks corresponds to the quality with which chunks were downloaded at node X.
  • the node Y has the information that the node X has the desired chunks 0 to 5.
  • Y takes chunk 0 from the backward buffer from node X and chunks 1 to 5 from the normal buffer. Without backward buffering, node Y would have to look for another source because chunk 0 would no longer be available to node Y.
  • the nodes in the PeRL list are relieved and on the other hand the entries in the PaRL list contain a sequential pattern.
  • the node X appears in the PaRL lists for the chunk numbers 0 to 5, which the node Y can find out by comparing these PaRL lists. If the node Y could successfully download the chunk 0 successfully, this will most likely also work with the subsequent chunks 1 to 5. In addition, a push service is also conceivable if the node Y also has the chunks following the chunk 5. Once node Y has successfully received chunks 1 through 5 from node X, X also automatically sends the following chunk 6 to Y. X then sends the chunks to node Y in turn until Y stops pushing or in the buffer X no more chunks are included.
  • Atonks with the same label from different nodes X knots down This is especially relevant against the background that the nodes from the PaRL list do not have the complete information content of the chunk, but only the language and image quality, which they themselves have chosen. If node Y at node X has thus found the searched atks for chunk 0, then this will probably also be the case for chunks 1 to 5. If this is not the case, or if X has generally considered a lower quality or different language, the missing Atonks must be downloaded from other sources in the corresponding PaRL list or PeRL list.
  • the streaming node quickly learns the nodes responsible for the replication lists by passing from successor to successor. From these, he can immediately download a whole set of PaRL lists for several consecutive identity values. He can then compare these PaRL lists to filter out the nodes from which he can download a whole package of chunks.
  • the PaRL lists must therefore always be completely available at the comparative node. If only a random selection is sent, it would not deliver as many hits in comparison.
  • Fig. 5 again illustrates the use of a buffer with backward buffering in a streaming node.
  • the stored chunks are shown in Fig. 5 by corresponding bars, which are only partially denoted by the reference C.
  • the node comprises a temporary buffer B 1 with a forward buffer BlOl and a backward buffer B 102.
  • the forward buffer essentially corresponds to the streaming window according to FIG. 2.
  • chunks of the stream that have already been played are used saved.
  • the playback direction is indicated by the arrow P ', and the current playback time is represented by the reference Z.
  • the temporary buffer is also used to provide the chunks for PaRL. Used lists.
  • a permanent memory B2 is also provided. If this memory is not yet filled, while the video is streaming, chunks are downloaded in parallel, which are permanently made available for downloading to other nodes. These chunks are provided for the corresponding PeRL lists.
  • a streaming node can verify that it may have stored the chunk to be downloaded locally. In doing so, he checks in particular his buffer (in particular also his backward buffer), the permanent replications stored with him, whether a complete copy of the video is stored with him or whether the chunk is already pushed sufficiently based on the above push mechanism.
  • the chunk is not stored locally, for example, you can first search for suitable sources in the PaRL lists.
  • the search can take place according to the locality, taking into account the IP prefx of the download source, whereby download sources with greater proximity to the streaming node are preferred.
  • download sources may be preferred in which one can access multiple chunks with one connection. This insight can be achieved by comparing the downloaded downlink PaRL lists of multiple identity values as described above. Also preferred are sources from which nodes have already been downloaded. Optionally, however, there is also the possibility that download sources from the PaRL lists are selected at random.
  • PeRL lists may, if appropriate, be followed by the selection of download sources from the PaRL lists, i. one
  • Download from the PeRL list will not be performed until a download Source in the PaRL list was not found or is not available. However, this is not absolutely necessary, and it may also be possible to use download sources from PeRL lists parallel to the PaRL lists, or at first only download sources from the PeRL lists may be used.
  • the location of the download source with respect to the streaming node can again be taken into account, taking into account the IP prefix of the download source, with closer download sources being preferred.
  • the download source may optionally also be randomly selected from the PeRL list.
  • Atonk map helps, telling the streaming node which Atonks it needs for a certain language or quality. For the missing Atonks, the node checks by request whether the source provides them. If so, he downloads the atonks. If the questions are not answered, he jumps to another source.
  • a streaming node After a streaming node has picked out suitable download sources, it initiates the data transfer by sending query messages to each of these sources. The messages are to check on the one hand, whether the required data are actually at the respective source. On the other hand, framework conditions must be created for the transfer. The following is a list of the information that should be included in this request message:
  • Hash value of the stream Chunk number (s); - Label of the desired Atonks;
  • Priority of the request Data types guideline; Address of the requesting node; Airtime temple.
  • the source can decide whether the message is still up-to-date. Old requests are simply discarded. If, due to many requests, not all can be serviced immediately, the queue will be processed after reception times.
  • the download source can accurately identify what data is being requested and whether it is available. By priority, the download source also recognizes the importance of the request. Dependent on this, the download source decides whether the transfer is made and how much data rate can be reserved for it.
  • the data rate guideline transmitted by the requesting node is intended to tell the download source what the approximate amount of workload will be for it. This value depends on the playback rate or the urgency with which the Atonks are needed. For the source, this guideline is, in addition to the priority, a decision criterion as to whether or not to accept the request becomes. If the source is already on the verge of utilization, it will refuse requests with high benchmarks.
  • the different answer options of a download source to the request can be:
  • the chunks to be downloaded to the streaming nodes are provided with different priority numbers and thus divided into different priority classes.
  • Priority classes provide a prioritized download based on specific criteria to ensure that much-needed chunks, such as chunks close to the video's current playing time, are processed faster and at higher data rates than less-urgent chunks, such as chunks which are downloaded for permanent provision to other nodes. In order to service requests for higher-priority chunks, even low-priority data transfers can be paused or canceled altogether.
  • the quality of the chunks to be downloaded can also be adapted if necessary.
  • chunks can be downloaded and played down much faster at the time of playback in lower quality and thus much faster than chunks with a greater time interval from the time of play.
  • a quality adjustment should be made, in particular, if no buffer has been set up by the streaming node. As the buffer increases, the quality of the chunk to be downloaded can be slowly increased and the replay rate maximized.
  • the chunks are divided into priority classes with priorities 1 to 5 and by which properties and meanings these priorities are distinguished. The priority numbers were chosen such that the priority of a chunk is higher, the smaller the corresponding priority number.
  • This priority applies to the entire chunk, which matches the current playing time of the video, but has not yet been downloaded and is required for immediate play. That is, the playback is currently interrupted. The time to download this chunk is therefore the playback delay and must be as small as possible.
  • the number of chunks with priority 1 is limited to exactly one chunk per streaming node. If necessary, the chunk can be split into several parallel downloads. The maximum possible data rates of source and sink are exhausted.
  • This priority applies to the chunks immediately after the playback time, up to the chunk marking the end of the download window W, which is illustrated in FIG.
  • the size of the buffer corresponding to this download window is derived from test and empirical values and should fulfill the following criteria: A node with a buffer of the size of the streaming window should stream without errors if it only worked with priority 1 and 2. However, these two priorities should only be used to guarantee a fast start and then a stable streaming of the stream. Chunks with priority 1 or 2 occur in particular during a restart or a jump in the stream, in which the buffer must be completely rebuilt. These situations are caused by the user of the streaming node and therefore can not be foreseen. So that these high priorities are not used non-stop and thus they lose their effectiveness, there must be other priorities for the normal data transfer, which are explained below.
  • Priority 3 is derived from test and empirical values and should fulfill the following criteria: A node with a buffer of the size of the streaming window should stream without errors if it only worked with priority 1 and 2. However, these
  • This priority is the default priority of the nodes where the buffer is completely filled according to the streaming window W of FIG. It is used for the chunks needed to populate the buffer from the minimum size specified by the streaming window to a maximum size.
  • the maximum size is suitably determined in such a way that priority 3 chunks are delivered in step with the same data rate as the playback takes.
  • the nodes can vary the data rates very variably and thus effectively exploit the buffer up to the maximum size. It is desirable to get into this class as quickly as possible after starting the stream and to stay there. The download speed is maximized as much as possible, but there should still be room for further data transfers.
  • This priority is used to download the chunks that are permanently available for download to other nodes.
  • the priority is correspondingly lower because downloading the chunks for permanent replication is completely time-critical.
  • it is even more important than a normal file transfer, as the replication should be able to access nodes again as quickly as possible.
  • the rates are determined by the currently available capacities, so fluctuate very heavily with the load and are often interrupted.
  • This priority corresponds to a normal file transfer. This is to make it possible that a video file is not immediately played as a stream, but only recorded. The download is therefore also completely non-time critical here.
  • the chunks are therefore not selected in sequence via a streaming window, but arbitrarily selected according to the available capacities. If the user of the streaming node still decides to use the Stream early, he is informed that there is no guarantee of error-free play in this case.
  • the data rates for Priority 5 are determined solely by the remaining free capacities of the various nodes. So the streaming node sends its requests to the various download sources of all chunks. These answer, but wait with the file transfer until they have free unused capacity available.
  • the playback delay of a video can be shortened and the buffer construction speeded up. This ensures that a user who wants to download a video does not have to wait very long to play the video. For this he accepts a poorer quality, which reaches its optimum very quickly after the start.
  • the quality of the video is preferably influenced by the priority as follows:
  • the quality of the chunk depends on the average download rate. This in turn depends on the possible rates of the sources and the recipient. Since today's Internet connections are very strongly asynchronous, the upload, ie the data rate of the source, is likely to be the quality determining criterion.
  • the priorities also influence the choice of sources.
  • very time-critical requests are increasingly made to those nodes that have the chunks with certainty, i. which are deposited as entries in the PeRL list of the corresponding chord note.
  • download sources are selected depending on the priorities set out above:
  • Requests for Priority 1 chunks first ask the nodes from the PeRL list. If these are overloaded, you can still switch to the nodes from the PaRL list. Normally this will enable shorter response times. Since the desired Atonks are certainly present, they can also be accepted with certainty. Since they also have the highest priority, they will most likely be serviced immediately. The node therefore does not have to send the requests again to other source nodes and thus saves time. The same applies to the download of chunks with priority 2. Here, however, first tried to get as many Atonks from the PaRL list. Only after a certain period of time have the nodes from the PeRL list been used for the missing Atonks. - The less important priorities will try to relieve the PeRL nodes as much as possible.
  • a request for a chunk is transmitted in the embodiment of the inventive method described here redundantly to various download sources simultaneously. That is, depending on priority, multiple requests for one and the same Atonk can be sent to several different sources. In the case of singular downloads, only the source that promises the highest capacity is used per chunk. In the case of multiple downloads, all sources that have accepted the request are used per chunk and type. Priorities 3, 4, and 5 do not necessarily require redundant requests because there is enough time for the node to wait.
  • the download can be initiated.
  • the download depends on the circumstances of the nodes involved in the download in different ways.
  • the preferred application of the method described herein is to stream the video, i. playing the video in parallel to download.
  • To play back the corresponding chunk, which is completely downloaded, decoded, for this purpose first a copy of the chunk is created, because the original serves other nodes as a source.
  • the decoded file is then played back using a suitable media player, with the media player being specified as the source of the locally stored media file.
  • the media player is not aware of how the data comes to this point. For the player, it seems like the media file already contains the entire stream at this point. In this way, all video-on-demand functions such as fast forward or jumping can be realized.
  • a corresponding request from the media player is intercepted beforehand and converted into the desired chunk number, which is then downloaded from the network as quickly as possible, locally decoded and integrated into the media file to be played so that the media player can play them.
  • the media player waits so long. He then fills a streaming buffer, which he needs for liquid play.
  • the method just described has a number of advantages.
  • the process creates a distribution platform for media content for a wide range of providers, in particular enabling video-on-demand streaming.
  • the method is based on the implementation of a decentralized structure for each video, whereby individual sections of a video are distributed to different nodes of the structure, so that they can be downloaded from different computers in the network.
  • the system cares in the background that a media file can be played while streaming without stopping.
  • the Method allows implementation of both video-on-demand and video recorder functions. There is no longer a central unit necessary to organize the management or provision of the video interchange.
  • every node that downloads media content also participates in the distribution of media content in the network or, if necessary, in the management of the video in a decentralized structure.
  • the erfmdungswashe method can be used in a variety of applications.
  • the process may offer free or paid video services, and companies may also provide self-produced media material for distribution on the market for free, as appropriate.
  • the process can also be used by private users who wish to stream their own video material into the data network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Bereitstellen von Medieninhalten für eine Mehrzahl von Knoten (K1,..., K8, K', K") in einem Datennetz, wobei die Medieninhalte eine oder mehrere Mediendateien (VF) umfassen und die Knoten (K1,..., K8, K', K") über Adressen in dem Datennetz adressierbar sind. In dem erfindungsgemäßen Verfahren wird für jede im Datennetz bereitzustellende Mediendatei (VF) eine dezentrale, über einen oder mehrere erste Knoten (K1,..., K8) verwaltete Struktur (R) dadurch gebildet, dass die jeweilige Mediendatei (VF) in eine Mehrzahl von Abschnitten (C) aufgeteilt wird und den Abschnitten (C) jeweils ein Identitätswert (0,..., 31) aus einem Identitätsintervall umfassend aufeinander folgende Identitätswerte (0,..., 31) zugeordnet wird, wobei der oder die ersten Knoten (K1,..., K8) jeweils für ein Teilintervall aus dem Identitätsintervall und hierdurch für eine Teilmenge an Abschnitten (C) aus der jeweiligen Mediendatei (VF) zuständig sind. In einem jeweiligen ersten Knoten (K1,..., K8) der dezentralen Struktur (R) wird eine Anzahl von zweiten Knoten (K', K") mit deren Adressen hinterlegt, wobei der oder die zweiten Knoten (K', K") zum Bereitstellen der Abschnitte (C) gemäß dem Teilintervall, für das der jeweilige erste Knoten (K1,..., K8) zuständig ist, vorgesehen sind. Ein Empfangsknoten (SK), der zum Herunterladen zumindest eines Teils einer jeweiligen Mediendatei (VF) vorgesehen ist, ruft mittels einer oder mehrerer Anfragen an die ersten Knoten (K1,..., K8) in der dezentralen Struktur (R) der jeweiligen Mediendatei (VF) die Adressen von zweiten Knoten (K', K") umfassend zumindest einen Teil derjenigen zweiten Knoten (K', K") ab, welche zum Bereitstellen der Abschnitte des zumindest einen Teils der Mediendatei vorgesehen sind, und lädt Abschnitte (C) umfassend die Abschnitte (C) des zumindest einen Teils der Mediendaten (VF) von zumindest einem Teil der zweiten Knoten (K', K"), deren Adressen abgerufen wurden, herunter.

Description

Verfahren und System zum Bereitstellen von Medieninhalten für eine Mehrzahl von Knoten in einem Datennetz
Beschreibung
Die Erfindung betrifft ein Verfahren und ein System zum Bereitstellen von Medieninhalten für eine Mehrzahl von Knoten in einem Datennetz, wobei die Medieninhalte eine oder mehrere Mediendateien umfassen und die Knoten über Adressen in dem Datennetz adressierbar sind.
Aus dem Stand der Technik sind verschiedene Verfahren bekannt, wie in einem Datennetz aus einer Mehrzahl von Knoten Medieninhalte anderen Knoten bereitgestellt werden können. Bekannte Lösungen ermöglichen dabei auch das Streamen von Me- diendateien, d.h. das parallele Abspielen der Mediendatei während des Herunterladens.
Zum Bereitstellen von Mediendateien gibt es sog. Client-Server-Lösungen, bei denen eine Mediendatei zentral von einem Server bereitgestellt wird und anschließend von verschiedenen Client-Knoten herunter geladen werden kann. Diese Lösung hat den
Nachteil, dass die gesamte Datenmenge der Datei für jeden Client-Knoten über das Datennetz angefordert und herunter geladen wird, so dass es hierdurch zu einer hohen Netzbelastung kommt.
Um einen Medienstrom in dem Datennetz zu verteilen und hierdurch das Herunterla- den des gesamten Stroms für jeden anfragenden Knoten zu vermeiden, ist es aus dem Stand der Technik für paketbasierte Netze bekannt, ein sog. IP-Multicast zu verwenden, bei dem in dem Netz spezielle Streaming-Router zur Weiterleitung von Datenströmen eingesetzt werden. Diese Lösung hat den Nachteil, dass in einem bestehenden paketbasierten Netz, beispielsweise im Internet, Veränderungen durch die Imp- lementierung von Streaming-Routern vorgenommen werden müssen.
Aus dem Stand der Technik sind zum Herunterladen von Medieninhalten ferner sog. Content-Distribution-Netzwerke bekannt, welche spezielle Proxy-Rechner verwenden, welche Medienströme aus dem Netz von einem Medienserver anfordern und sie an entsprechende Client-Knoten weiterleiten. Auch bei dieser Lösung muss die Netz- Infrastruktur durch die Implementierung geeigneter Proxys angepasst werden.
Ein weiterer Ansatz zur Verteilung von Mediendateien in einem Datennetz ist in der Druckschrift W.-P. K. Yiu, X. Jin und S.-H. G. Chan, „Distributed Storage to Sup- port User Interactivity in Peer-to-Peer Video Streaming", IEEE ICC '06, 2006, beschrieben. Gemäß dem dort vorgestellten Verfahren wird ein VoD-Streaming (VoD = Video on Demand) in einem verteilten Peer-to-Peer-Netz ermöglicht, wobei alle bereitzustellenden Videos in Abschnitte aufgeteilt werden und die Abschnitte dezentral über die Knoten des Peer-to-Peer-Netzes bereitgestellt werden. Da über das de- zentrale Netz eine Vielzahl von Videos verwaltet wird, ist die Suche nach einer entsprechend zu streamenden Videodatei aufwändig und führt zu Verzögerungen beim Abspielen des Videos.
Aufgabe der Erfindung ist es, ein Verfahren und ein System zum Bereitstellen von Medieninhalten für eine Mehrzahl von Knoten in einem Datennetz zu schaffen, wel- che ohne Veränderung der Struktur des Datennetzes eine schnelle und zuverlässige Bereitstellung der Medieninhalte ermöglichen.
Diese Aufgabe wird durch das Verfahren gemäß Patentanspruch 1 bzw. das System gemäß Patentanspruch 28 gelöst. Weiterbildungen der Erfindung sind in den abhängigen Ansprüchen definiert.
In dem erfmdungsgemäßen Verfahren wird für jede, im Datennetz bereitzustellende Mediendatei separat eine dezentrale, über einen oder mehrere erste Knoten verwalte- te Struktur dadurch gebildet, dass die jeweilige Mediendatei in eine Mehrzahl von Abschnitten aufgeteilt wird und den Abschnitten jeweils ein Identitätswert aus einem Identitätsintervall umfassend aufeinander folgende Identitätswerte zugeordnet wird, wobei der oder die ersten Knoten jeweils für ein Teilintervall aus dem Identitätsintervall und hierdurch für eine Teilmenge an Abschnitten aus der jeweiligen Medien- datei zuständig sind.
Zur Bereitstellung der Abschnitte über die dezentrale Struktur wird in dem erfindungsgemäßen Verfahren in einem jeweiligen ersten Knoten der dezentralen Struktur eine Anzahl von zweiten Knoten mit deren Adressen hinterlegt, wobei der oder die zweiten Knoten zum Bereitstellen der Abschnitte gemäß dem Teilintervall, für das der jeweilige erste Knoten zuständig ist, vorgesehen sind. Zweite Knoten sind dabei insbesondere solche Knoten, bei denen in Abhängigkeit von bestimmten Kriterien davon ausgegangen werden kann, dass diese zweiten Knoten in ihrem Speicher tatsächlich die entsprechenden Abschnitte der Mediendatei enthalten. Nichtsdestotrotz muss die Verfügbarkeit der Abschnitte in den zweiten Knoten nicht garantiert sein.
Das Herunterladen zumindest eines Teils einer jeweiligen Mediendatei über einen entsprechenden Empfangsknoten läuft erfindungsgemäß mittels entsprechender Anfragen an die dezentrale Struktur ab. Dabei ruft der entsprechende Empfangsknoten mittels einer oder mehrerer Anfragen an die ersten Knoten in der dezentralen Struktur der jeweiligen Mediendatei die Adressen von zweiten Knoten umfassend zumin- dest einen Teil derjenigen zweiten Knoten ab, welche zum Bereitstellen der Abschnitte des zumindest einen Teils der Mediendatei vorgesehen sind. Anschließend werden Abschnitte umfassend die Abschnitte des zumindest einen Teils der Mediendatei von zumindest einem Teil der zweiten Knoten, deren Adressen abgerufen wur- den, durch den Empfangsknoten herunter geladen.
Hier und im Folgenden bedeutet „Herunterladen eines Abschnitts" nicht zwangsläufig, dass die Gesamtmenge an Informationen eines Abschnitts herunter geladen werden muss. Vielmehr kann gegebenenfalls auch nur ein bestimmter Anteil des Ab- Schnitts herunter geladen werden, beispielsweise derart, dass der Inhalt des Abschnitts in verringerter Qualität bereitgestellt wird.
Das erfindungsgemäße Verfahren zeichnet sich dadurch aus, dass für jede einzelne Mediendatei eine separate dezentrale Struktur gebildet wird, welche die Verwaltung der Abschnitte der Mediendatei übernimmt. Es wird somit für jede Mediendatei ein überschaubares dezentrales Netz gebildet, welches ein schnelles und effizientes Herunterladen der Mediendatei durch einen entsprechenden Empfangsknoten ermöglicht.
Ein bevorzugter Anwendungsfall des erfindungsgemäßen Verfahrens ist dessen Verwendung in einem paketbasierten Datennetz, insbesondere dem Internet. Die Adressen der Knoten sind dabei insbesondere IP-Adresse. Das Verfahren wird vorzugsweise in der Anwendungsschicht des OSI-Referenzmodells als ALM-Protokoll (ALM = Application Layer Multicast) implementiert.
In einer bevorzugten Ausführungsform enthält eine jeweilige Mediendatei einen abspielbaren Medienstrom, insbesondere einen Audio- und/oder Videostrom. Die Abschnitte der Mediendatei stellen dabei zeitlich aufeinander folgende Abschnitte des Medienstroms dar, wobei die Identitätswerte des Identitätsintervalls in Abspiel- reihenfolge des Medienstroms den Abschnitten zugeordnet werden. Das heißt, je größer der entsprechende Identitätswert ist, desto später ist auch der Abspielzeitpunkt des Abschnitts im Medienstrom. Vorzugsweise wird das erfindungsgemäße Verfahren dabei zum sog. Streamen des Medienstroms eingesetzt, bei dem ein Empfangsknoten parallel zum Herunterladen die herunter geladenen Abschnitte des Medienstroms abspielt.
Die erfindungsgemäß bereitgestellte dezentrale Struktur zum Verwalten von Abschnitten einer einzelnen Mediendatei kann dabei insbesondere mit bekannten Peer- to-Peer-Protokollen bzw. als Ringstruktur in dem Datennetz implementiert werden. Vorzugsweise wird dabei als Ringstruktur der hinlänglich aus dem Stand der Technik bekannte Chord-Ring verwendet. Die Mechanismen eines Chord-Rings zum Bereitstellen und zur Suche nach Ressourcen können dann in dem erfindungsgemäßen Verfahren genutzt werden.
In einer besonders bevorzugten Ausführungsform des erfindungsgemäßen Verfah- rens stellt ein Empfangsknoten, der Abschnitte einer Mediendatei herunter lädt, diese auch anderen Knoten zur Verfügung. Dies erfolgt dadurch, dass der Empfangsknoten mit seiner Adresse als zweiter Knoten in den entsprechenden ersten Knoten, welche für die vom Empfangsknoten herunter geladenen Abschnitte zuständig sind, hinterlegt wird.
In einer weiteren Ausführungsform der Erfindung wird ein Mechanismus zum Schutz vor dem Ausfall von ersten Knoten bereitgestellt, wodurch ein zuverlässiges Herunterladen von Mediendateien auch bei Ausfall eines ersten Knotens sichergestellt wird. Hierzu wird die Anzahl von in einem jeweiligen ersten Knoten hinterleg- ten zweiten Knoten in anderen ersten Knoten repliziert, insbesondere zumindest in einem Nachbarknoten, welcher für ein Teilintervall zuständig ist, das sich an das Teilintervall anschließt, für das der jeweilige erste Knoten zuständig ist.
In einer weiteren, bevorzugten Variante der Erfindung wird die Anzahl von in einem jeweiligen ersten Knoten hinterlegten zweiten Knoten in der Form von einer oder mehreren Listen hinterlegt. Vorzugsweise umfassen das oder die Listen in einem jeweiligen ersten Knoten eine oder mehrere erste und/oder zweite Listen. Sowohl die ersten als auch die zweiten Listen können dazu verwendet werden, um von diesen Listen entsprechende Abschnitte bei zweiten Knoten herunter zu laden. Eine erste Liste enthält dabei zweite Knoten mit permanent zum Herunterladen durch andere Knoten verfügbaren Abschnitten, wobei die Verfügbarkeit des jeweiligen zweiten Knotens durch regelmäßigen Nachrichtenaustausch des zweiten Knotens mit dem jeweiligen ersten Knoten überprüft wird. Hierdurch wird die dauerhafte Verfügbarkeit von Abschnitten einer Mediendatei in dem Datennetz gewährleistet. Im Gegensatz zu der ersten Liste umfasst eine zweite Liste diejenigen Knoten, welche bei dem jeweiligen ersten Knoten innerhalb eines vorbestimmten zurückliegenden Zeitraums Adressen von zweiten Knoten abgerufen haben. Eine zweite Liste enthält somit Knoten, von denen mit einer gewissen Wahrscheinlichkeit davon ausgegangen werden kann, dass sie auch entsprechend angefragte Abschnitte einer Mediendatei enthalten, da die Knoten in der zweiten Liste auch selbst diese Abschnitte angefragt haben.
Zur Verbreitung der permanent verfügbaren Abschnitte lädt ein Empfangsknoten in einer bevorzugten Variante der Erfindung Abschnitte von zweiten Knoten aus der ersten und/oder zweiten Liste herunter, wobei die herunter zu ladenden Abschnitte nach einem oder mehreren vorbestimmten Kriterien, insbesondere zufällig, ausge- wählt werden. Das heißt, ein Empfangsknoten sucht mittels einer Anfrage nach einem entsprechenden ersten Knoten, der einen zufällig ausgewählten Abschnitt verwaltet und fragt von diesem ersten Knoten die erste oder zweite Liste ab. Er lädt dann den entsprechenden Abschnitt von einem zweiten Knoten aus der ersten oder zweiten Liste herunter. Der herunter zu ladenden Abschnitt muss dabei kein Ab- schnitt sein, den der Empfangsknoten für das Abspielen der von ihm gerade herunter geladenen Mediendatei benötigt wird. Somit läuft im Hintergrund neben einem Laden von Abschnitten aus einer Mediendatei auch eine Verteilung von weiteren Abschnitten in dem Datennetz ab, wodurch an mehreren Stellen im Netz permanent verfügbare Abschnitte bereitgestellt werden, so dass ein zuverlässiger Download von verschiedenen Download-Quellen im Netz ermöglicht wird. In einer weiteren Ausgestaltung des erfϊndungsgemäßen Verfahrens, bei dem die herunter geladene Mediendatei gestreamt wird, werden zweite Knoten aus der ersten Liste umso stärker zum Herunterladen eines abzuspielenden Abschnitts bevorzugt, je näher der abzuspielende Abschnitt am aktuellen Abspielzeitpunkt der Mediendatei liegt. Auf diese Weise wird sichergestellt, dass demnächst abzuspielende Abschnitte einer Mediendatei von zuverlässigen Quellen, welche die entsprechenden Abschnitte permanent zur Verfügung stellen, herunter geladen werden. Hierdurch werden Verzögerungen beim Abspielen der Mediendatei vermieden.
In einer besonders bevorzugten Ausführungsform der Erfindung kann sich ein Empfangsknoten nicht nur an der Verteilung von Abschnitten einer Mediendatei, sondern auch an der Verwaltung der Ringstruktur beteiligen. Dabei wird ein Empfangsknoten in Abhängigkeit von einem oder mehreren Kriterien als erster Knoten in die dezentrale Struktur einer jeweiligen Mediendatei dadurch aufgenommen, dass dem Emp- fangsknoten die Zuständigkeit für ein Teilintervall aus dem Identitätsintervall zugewiesen wird. Insbesondere können aus dem Stand der Technik bekannte Mechanismen zur Aufnahme von Knoten in dezentrale Strukturen verwendet werden. Solche Mechanismen sind beispielsweise für Chord-Ringe bekannt.
Vorzugsweise sind das oder die Kriterien zur Aufnahme eines Empfangsknotens in die dezentrale Struktur derart ausgestaltet, dass für einen Empfangsknoten eine Maximalanzahl von Malen nach einem Teilintervall des Identitätsintervalls gesucht wird, dessen Zuständigkeit ein neuer Knoten in der dezentralen Struktur übernehmen kann, wobei im Falle, dass kein Teilintervall nach der Maximalanzahl von Malen gefunden wird, der Empfangsknoten nicht als erster Knoten in die dezentrale Struktur aufgenommen wird. Ebenso besteht die Möglichkeit, dass nur solche Empfangsknoten in die dezentrale Struktur aufgenommen werden, welche eine vorbestimmte Mindestgröße an Ressourcen bereitstellen können. Unter Ressourcen sind dabei insbesondere entsprechend verfügbare Uploadraten bzw. Speicherkapazitäten bzw. Re- chenkapazitäten des Knotens zu verstehen. Hierdurch wird sichergestellt, dass nur Knoten mit ausreichender Kapazität an der Verwaltung der dezentralen Struktur teil- nehmen. Somit wird eine Überlastung von Knoten vermieden und die Ausfallsicherheit des Verfahrens verbessert.
In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens wird dem in die dezentrale Struktur aufzunehmenden Empfangsknoten zufällig oder nach einem vorbestimmten Muster eine Zuständigkeit für ein Teilintervall zugewiesen, wobei das vorbestimmte Muster insbesondere derart ausgestaltet ist, dass für Abschnitte mit kleineren Identitätswerten mehr Knoten zuständig sind als für Abschnitte mit größeren Identitätswerten. Für Mediendateien in der Form von abzuspielenden Medien- strömen wird hierdurch die Erkenntnis berücksichtigt, dass ein Nutzer in der Regel bereits am Anfang des Abspielens eines Medienstroms entscheidet, ob er den Medienstrom weiter anschauen möchte oder nicht. Somit unterliegen Knoten, welche Abschnitte mit kleinen Identitätswerten verwalten, einer höheren Belastung als Knoten mit größeren Identitätswerten, so dass eine dichtere Knoten-Besetzung für Ab- schnitte mit kleinen Identitätswerten sinnvoll ist.
In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens kennt in der dezentralen Struktur ein jeweiliger erster Knoten den Nachbarknoten, welcher für ein Teilintervall zuständig ist, das sich an das Teilintervall, für das der jeweilige erste Knoten zuständig ist, in Richtung hin zu höheren Identitätswerten anschließt, wobei die Adresse des Nachbarknotens durch den jeweiligen ersten Knoten bei einem Abruf der Adressen der zweiten Knoten an den Empfangsknoten übermittelt wird. Bei einem abzuspielenden Medienstrom wird dabei die Anzahl der Anfragen reduziert, da ein Empfangsknoten bereits die Information über die Adresse des entsprechenden Nachbarknotens erhält, der zweite Knoten verwaltet, von denen nachfolgend abzuspielende Abschnitte herunter geladen werden können. Insbesondere verfügt der jeweilige erste Knoten dabei über weitere Informationen über den Nachbarknoten, welche neben der Adresse des Nachbarknotens an den Empfangsknoten übermittelt werden und aus denen der Empfangsknoten das Teilintervall ermittelt, für das der Nachbarknoten zuständig ist. Hierdurch kann der Empfangsknoten auf einmal die Adressen der zweiten Knoten für alle Abschnitte abfragen, für welche der Nachbarknoten zuständig ist.
In einer weiteren Ausführungsform des erfmdungsgemäßen Verfahrens werden Ab- schnitte durch einen Empfangsknoten in Abhängigkeit von einem oder mehreren, für die Abschnitte vergebenen Prioritäten herunter geladen, wobei Abschnitte mit höheren Prioritäten beim Herunterladen bevorzugt werden. Beim Herunterladen eines abzuspielenden Medienstroms ist für einen Empfangsknoten vorzugsweise ein erstes Zeitintervall vorgegeben, wobei der Empfangsknoten ausgehend von seinem aktuel- len Abspielzeitpunkt des Medienstroms Abschnitte, welche im abgespielten Medienstrom in dem ersten Zeitintervall nach dem Abspielzeitpunkt liegen, mit höherer Priorität als andere Abschnitte herunter lädt. Auf diese Weise erfolgt ein priorisierter Download dahingehend, dass demnächst abzuspielende Abschnitte beim Herunterladen bevorzugt werden. Hierdurch wird ein kontinuierliches Abspielen des Medien- Stroms sichergestellt. Insbesondere werden dabei Abschnitte innerhalb des ersten Zeitintervalls, welche den aktuellen Abspielzeitpunkt enthalten, mit höherer Priorität als die anderen Abschnitte im ersten Zeitintervall herunter geladen.
In einer weiteren Variante des erfmdungsgemäßen Verfahrens ist für einen Emp- fangsknoten neben dem ersten Zeitintervall auch ein zweites Zeitintervall vorgegeben, welches größer als das erste Zeitintervall ist, wobei der Empfangsknoten ausgehend von seinem aktuellen Abspielzeitpunkt des Medienstroms Abschnitte, welche im abgespielten Medienstrom in dem zweiten Zeitintervall nach dem Abspielzeitpunkt und außerhalb des ersten zeitlichen Intervalls liegen, mit niedrigerer Priorität als die Abschnitte innerhalb des ersten Zeitintervalls herunter lädt.
Vorzugsweise lädt ein Empfangsknoten Abschnitte zur Bereitstellung als permanent verfügbare Abschnitte mit niedrigerer Priorität als die Abschnitte aus dem ersten oder zweiten Zeitintervall nach dem aktuellen Abspielzeitpunkt herunter. Hierdurch wird berücksichtigt, dass das Herunterladen von Abschnitten zur permanenten Be- reitstellung vollkommen zeitunkritisch ist, da diese Abschnitte nicht zum Abspielen der aktuell herunter geladenen Mediendatei benötigt werden.
In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens werden die Ab- schnitte einer Mediendatei jeweils in kleinere Teilabschnitte aufgeteilt. Dabei kann beim Herunterladen eines Abschnitts der gesamte Abschnitt, jedoch auch nur eine Auswahl von Teilabschnitten aus dem Abschnitt herunter geladen werden. Vorzugsweise sind die Teilabschnitte aller Abschnitte einer jeweiligen Mediendatei in mehrere Kanäle gruppiert, welche verschiedene Qualitätsstufen der Mediendatei repräsen- tieren. Auf diese Weise wird durch gezieltes Herunterladen von Teilabschnitten eines Kanals eine qualitätsangepasste Wiedergabe der Mediendatei, insbesondere ein qua- litätsangepasstes Abspielen eines Medienstroms, ermöglicht.
Vorzugsweise liest ein Empfangsknoten zur Verarbeitung der Teilabschnitte Infor- mationen über die Teilabschnitte, insbesondere hinsichtlich der Zuordnung der Teilabschnitte zu Qualitätsstufen, aus einer Informationsdatei aus. Auf diese Weise kann sich ein Empfangsknoten die Informationen holen, welche Qualität bzw. Sprache und dergleichen er abspielen kann und welche Teilabschnitte er hierzu auswählen muss.
In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens werden Informationen zu einer jeweiligen Mediendatei in einem Meta-Container bereitgestellt, welcher von einem Empfangsknoten herunter geladen werden kann. Hierdurch können dem Nutzer des Empfangsknotens entsprechende Informationen über die bereitgestellten Mediendateien bereitgestellt werden, wobei der Nutzer anhand dieser Infor- mationen entscheiden kann, ob das Herunterladen der Mediendatei für ihn interessant ist, welche Qualität und eventuell welche Sprache er auswählen möchte.
In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens werden eine
Mehrzahl von Mediendateien über einen suchbaren Index im Datennetz bereitge- stellt, wobei für jeden Index zumindest ein Teil der Adressen der ersten Knoten der für die jeweilige Mediendatei gebildeten dezentralen Struktur hinterlegt ist. Somit erhält ein Empfangsknoten, der eine über den Index ermittelte Mediendatei gefunden hat, sogleich eine Information über Zugangspunkte in die Ringstruktur, so dass der Empfangsknoten unmittelbar durch Adressierung eines der Zugangspunkte den Pro- zess des Herunterladens der Mediendatei beginnen kann.
Neben dem oben beschriebenen Verfahren betrifft die Erfindung ferner ein System zum Bereitstellen von Medieninhalten für eine Mehrzahl von Knoten in einem Datennetz, wobei die Medieninhalte eine oder mehrere Mediendateien umfassen und die Knoten über Adressen in dem Datennetz adressierbar sind. Das System verwaltet die Mehrzahl von Knoten dabei derart, dass jede Variante des oben beschriebenen Verfahrens mit dem System durchführbar ist. Das System wird dabei vorzugsweise durch entsprechende Software auf den einzelnen Knoten implementiert, wobei die Software ein Bereitstellen bzw. Herunterladen von Mediendateien gemäß dem erfindungsgemäßen Verfahren ermöglicht.
Darüber hinaus betrifft die Erfindung einen Knoten zur Verwendung in dem erfindungsgemäßen Verfahren, wobei der Knoten derart ausgestaltet ist, dass er bei Betrieb in dem Verfahren als erster Knoten oder als zweiter Knoten oder als Empfangsknoten fungiert.
Ausführungsbeispiele der Erfindung werden nachfolgend anhand der beigefügten Figuren detailliert beschrieben.
Es zeigen:
Fig. 1 eine schematische Darstellung der Bereitstellung einer Videodatei über eine Ringstruktur gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens;
Fig. 2 eine Detaildarstellung der in Fig. 1 gezeigten Ringstruktur, wobei die in der Ringstruktur verwalteten Listen verdeutlicht sind; Fig. 3 eine schematische Darstellung einer Aufteilung der Abschnitte einer Videodatei in kleinere Teilabschnitte gemäß einer Ausfuhrungsform der Erfindung;
Fig. 4 ein Ablaufdiagramm, welches die Suche eines Knotens nach Abschnitten einer Videodatei in einer Ringstruktur gemäß Fig. 1 bzw. Fig. 2 verdeutlicht; und
Fig. 5 eine schematische Darstellung des Streamens einer Videodatei in einem ent- sprechenden, die Videodatei empfangenden Knoten gemäß einer Ausführungsform der Erfindung.
Durch die nachfolgend beschriebenen Ausführungsformen des erfmdungsgemäßen Verfahrens werden Mediendateien in entsprechenden Knoten eines Datennetzes zur Verfügung gestellt. Das Datennetz stellt dabei ein paketbasiertes Datennetz dar, welches auf der Schicht 3 des OSI-Referenzmodells das IP-Protokoll verwendet. Bei den Knoten des Datennetzes handelt es sich um entsprechende Rechner im Internet, welche über IP -Adressen angesprochen werden können. Die nachfolgend beschriebene Peer-to-Peer-Struktur wird dabei auf der Anwendungsschicht des OSI-Referenz- modells in der Form eines ALM-Protokolls (ALM = Application Layer Multicast) umgesetzt. Die nachfolgenden Prinzipien sind jedoch nicht auf bestimmte Arten von Datennetzen bzw. Protokollen beschränkt, sondern können auch in anderen Netzen und über andere Protokolle implementiert werden.
Basierend auf dem nachfolgend erläuterten Verfahren werden Medieninhalte in der Form von Mediendateien und insbesondere in der Form von Videodateien zum Herunterladen durch Knoten bereitgestellt. Die Medieninhalte sind dabei nicht auf Videos beschränkt, sondern können beliebige andere Inhalte umfassen, wie z.B. nur reine Audiodateien. Die Bereitstellung der Mediendatei erfolgt in der nachfolgend be- schriebenen Ausführungsform durch einen entsprechenden Videoanbieter, der über das Internet kostenlos bzw. gegen Bezahlung Videos zum Streamen für andere Rno- ten des Netzes bereitstellt. Damit ein Knoten nach Videos suchen kann bzw. diese herunter laden kann, muss eine entsprechende Client-Software auf dem Knoten installiert sein. Die Software wird vorzugsweise von dem Videoanbieter bereitgestellt und ist derart ausgestaltet, dass mit allen Knoten, welche diese Software verwenden, die erfmdungsgemäße Verteilung und das erfindungsgemäße Herunterladen von Videos ermöglicht werden.
Neben dem soeben beschriebenen Szenario des Anbietens von Videoinhalten durch einen kommerziellen Anbieter kann das erfindungsgemäße Verfahren auch von be- liebigen anderen Personen bzw. Institutionen zum Bereitstellen von Medieninhalten genutzt werden. Beispielsweise können Firmen ihr selbstproduziertes Material bezüglich ihrer Produkte basierend auf dem erfindungsgemäßen Verfahren bereitstellen und ebenso können Privatpersonen eigenes Videomaterial mit anderen Benutzern austauschen.
In dem in Fig. 1 gezeigten Szenario stellt ein kommerzieller Videoanbieter über einen Server SE Videodateien zum Herunterladen durch Nutzer bereit. Die Nutzer sind dabei repräsentiert durch entsprechende Knoten, welche Rechner darstellen, die von einem Nutzer bedient werden und über eine Internetverbindung verfügen, so dass sie über eine entsprechende IP -Adresse angesprochen werden können. Auf den Knoten, über welche die Dienste des Videoanbieters genutzt werden, ist jeweils eine entsprechende Client-Software installiert. Damit das bereitgestellte Videomaterial auch durch andere Knoten gefunden werden kann, werden durch den Videoanbieter die entsprechenden Videodateien im Rahmen eines Index-Prozesses indiziert. In der Ausführungsform der Fig. 1 läuft dieser Index-Prozess als zentraler Prozess auf dem Server SE ab. Es besteht jedoch auch die Möglichkeit, dass dieser Prozess als verteilter Prozess zum Einsatz kommt, so dass an diesem Prozess diverse leistungsfähige Rechnerknoten beteiligt sind.
Wie in Fig. 1 angedeutet ist, wird durch den Index-Prozess eine entsprechende Tabelle T generiert, in der jedem bereitgestellten Video eine Index-Nummer zugeordnet ist, wobei in Fig. 1 beispielhaft die Index-Nummern 1, 2 und 34 angedeutet sind. Jedem Index ist dabei ein über eine Hash-Funktion erzeugter Datei-Hash zugeordnet, anhand dem die einzelnen Videodateien unterschieden werden können und nach dem zum Auffinden von Videodateien gesucht werden kann. In der dargestellten Tabelle T ist ferner für jeden Index angegeben, welche aktiven Knoten zu einer Ringstruktur gehören, welche der Datei zugeordnet ist. Die Ringstruktur wird im Folgenden noch näher erläutert und ist in Fig. 1 durch das Bezugszeichen R angedeutet. Basierend auf dem bereitgestellten Index kann somit ein Knoten nach entsprechenden Videodateien suchen, wobei dem Knoten für eine aufgefundene Videodatei auch entsprechende aktive Knoten angegeben werden, welche dem suchenden Knoten als Einstiegspunk- te zum Herunterladen des Videos dienen.
Ein wesentlicher Aspekt des nachfolgend erläuterten Verfahrens zur Bereitstellung von Videoinhalten besteht darin, dass für jede Videodatei eine dezentral verwaltete Ringstruktur R gebildet ist, wobei die Zuweisung einer Videodatei zu einer Ringstruktur schematisch durch den Pfeil P angedeutet ist. Zur Generierung dieser Ringstruktur R wird das entsprechende bereitzustellende Video in eine Vielzahl von Abschnitten eingeteilt, welche im Folgenden auch als Chunks bezeichnet sind. Jeder Chunk enthält dabei einen zeitlichen Abschnitt der abgespielten Videodatei. In dem Szenario der Fig. 1 wird die Videodatei in 32 Chunks eingeteilt, welche durch entsprechend nummerierte Quadrate 0, 1 , ..., 31 angedeutet sind und zumindest teilweise mit dem Bezugszeichen C bezeichnet sind. Jedem Abschnitt wird somit ein Identitätswert aus einem 5 -Bit-Intervall von Identitätswerten zugewiesen, wobei eine höhere Nummer eines Identitätswerts einen späteren zeitlichen Abschnitt des Videos rep- räsentiert. Hierdurch wird die in Fig. 1 gezeigte Ringstruktur geschaffen, bei der jedem Chunk eine Position auf einem 5-Bit-Ring mit 32 Positionen zugeordnet ist.
Die Chunks C werden dabei durch entsprechende Knoten verwaltet, welche gemäß
Anspruch 1 als erste Knoten bezeichnet werden. Diese Knoten sind solche Knoten, welche auch entsprechende Videoinhalte von anderen Knoten herunter laden können.
Somit beteiligen sich die den Dienst des Videoanbieters nutzenden Knoten auch an der Verwaltung entsprechender Videos. In dem Szenario der Fig. 1 ist dabei nicht jede Position des Rings mit einem Knoten besetzt. Vielmehr existieren insgesamt acht Knoten Kl bis K8. Der Knoten Kl besetzt dabei die Position 0 des Rings, der Knoten K2 die Position 4, der Knoten K3 die Position 6, der Knoten K4 die Position 13, der Knoten K5 die Position 19, der Knoten K6 die Position 24, der Knoten K7 die Position 27 und der Knoten K8 die Position 31. Jeder der Knoten verwaltet dabei die Chunks an der Position, an der er sitzt, sowie an allen vorhergehenden Positionen bis zum vorhergehenden Knoten. Das heißt, der Knoten Kl verwaltet den Chunk 0, der Knoten K2 die Chunks 1 bis 4, Der Knoten K3 die Chunks 5 und 6, der Knoten K4 die Chunks 7 bis 13, der Knoten K5 die Chunks 14 bis 19, der Knoten K6 die Chunks 20 bis 24, der Knoten K7 die Chunks 25 bis 27 und der Knoten K8 die Chunks 28 bis 31.
Die Verwaltung durch die Ringstruktur R mit Hilfe der Knoten Kl bis K8 erfolgt vorzugsweise basierend auf bekannten Peer-to-Peer-Protokollen. Besonders bevorzugt wird hierbei der aus dem Stand der Technik bekannte Chord-Ring verwendet, der entsprechende Mechanismen zur Verwaltung und Suche nach Ressourcen in dem am Ring beteiligten Knoten bereitstellt. Es können jedoch auch beliebige andere Peer-to-Peer-Protokolle verwendet werden, mit denen innerhalb eines Verteilnetzes nach Knoten mit Zuständigkeiten für Intervalle an Identitätswerten gesucht werden kann und welche ferner einen Mechanismus bereitstellen, mit dem neue Knoten in das Verteilernetz aufgenommen werden können bzw. auch Knoten das Verteilernetz wieder verlassen können.
Jedem der einzelnen Knoten Kl bis K8 in der Ringstruktur R ist eine Anzahl von weiteren Knoten des Datennetzes zugeordnet, welche die entsprechenden Chunks enthalten, für welche die jeweiligen Knoten Kl bis K8 des Rings R zuständig sind. Diese, die Chunks enthaltenden Knoten entsprechen dabei den zweiten Knoten im Sinne von Anspruch 1 und werden in entsprechenden Listen verwaltet, wie in Fig. 2 verdeutlicht ist. Es existiert dabei für jeden Identitätswert eines Chunks in der Ringstruktur R sowohl eine permanente Replikationsliste, welche als PeRL bezeichnet wird, sowie eine momentane Replikationsliste, welche als PaRL bezeichnet wird. In Fig. 2 sind beispielhaft zwischen den Knoten Kl und K3 einige Positionen von Identitätswerten von Chunks durch vertikale Linien angedeutet, von denen aus Übersichtlichkeitsgründen lediglich eine Linie mit dem Bezugszeichen L bezeichnet ist. Der Knoten K2 verwaltet dabei die Identitätswerte der Chunks 1 bis 4, so dass in diesem Knoten für jeden der Chunks sowohl eine PeRL als auch eine PaRL hinterlegt ist.
In der PeRL-Liste werden für einen jeweiligen Chunk alle Knoten mit deren Knoten- zugangspunkten (d.h. Adresse und Port) gesammelt, die den Chunk permanent be- reitstellen. Wie weiter unten noch näher erläutert wird, ist mit entsprechenden Mechanismen dafür gesorgt, dass es ausreichend viele Knoten gibt, welche Chunks dauerhaft zum Download bereitstellen. Zu solchen Knoten zählen unter anderem auch diejenigen Knoten, die eine komplette Kopie des Videos besitzen. Dauerhaft bedeutet in diesem Zusammenhang, solange der entsprechende Knoten am Netz zur Vertei- lung der Videos beteiligt ist. In Fig. 2 ist schematisch der Aufbau einer PeRL-Liste wiedergegeben. Die PeRL-Liste enthält für jeden Knoten, der dauerhaft den entsprechenden Chunk bereitstellt, einen Eintrag. Beispielhaft ist ein Eintrag für einen Knoten K' hervorgehoben. In jedem Eintrag wird der Zeitpunkt t spezifiziert, zu dem der entsprechende Eintrag zum letzten Mal aktualisiert wurde. Ebenso ist die entspre- chende IP -Adresse des Knotens angegeben. In der PeRL-Liste sind insbesondere auch Knoten enthalten, welche eine komplette Kopie des Videos bereitstellen. Diese Knoten sind speziell markiert. Zur ständigen Aktualisierung der Einträge aus der PeRL-Liste werden dabei sog. Keep-Alive-Nachrichten, welche hinlänglich aus Peer-to-Peer-Protokollen bekannt sind, zwischen den einzelnen Knoten ausgetauscht, wie weiter unten noch näher erläutert wird.
Neben der PeRL-Liste ist in Fig. 2 auch schematisch eine PaRL-Liste für einen Chunk wiedergegeben. In dem Beispiel der Fig. 2 enthält diese Liste nur einen Eintrag für einen Knoten K". In dieser Liste werden Knoten eingetragen, welche den entsprechenden Chunk, zu dem die PaRL-Liste gehört, innerhalb eines vorgegebenen zurückliegenden Zeitraums angefragt haben. Jeder Eintrag in der PaRL-Liste gibt dabei neben der IP-Adresse des entsprechenden Knotens auch den Zeitpunkt t wieder, zu dem der Chunk angefragt wurde. Diese PaRL-Liste wird nicht mit Keep- Alive-Nachrichten aktualisiert. Vielmehr werden in der Liste alle Knoten eingetragen, die den Chunk angefragt haben und die nach Eintritt einer gewissen Bedingung, spätestens nach Ablauf einer vorbestimmten Zeitperiode, wieder herausgelöscht werden. Auf diese Weise wird es ermöglicht, zeitlich starke Schwankungen bei der Nachfrage nach einem Chunk auszugleichen, denn es kann davon ausgegangen werden, dass ein Knoten, welcher einen entsprechenden Chunk angefragt hat, diesen auch herunter geladen hat und somit bereitstellen kann. Somit können neben den Knoten aus der PeRL-Liste auch Knoten aus der PaRL-Liste zum Herunterladen von Chunks genutzt werden.
Der Ring R gemäß Fig. 1 bzw. Fig. 2 wird von entsprechenden Streaming-Knoten SK (Fig. 4), welche den Empfangsknoten im Sinne von Anspruch 1 entsprechen, dazu genutzt, um aufeinander folgend entsprechende Chunks herunter zu laden, wobei die Informationen über die Knoten, welche die Chunks bereitstellen, aus dem Ring über die darin enthaltenen Knoten Kl bis K8 abgerufen werden. Das Streamen des durch den Ring R bereitgestellten Videos durch einen Streaming-Knoten wird in Fig. 2 durch ein entsprechendes Streaming-Fenster W angedeutet. Dieses Fenster stellt eine minimale Puffergröße bei Streaming-Knoten dar, der zum Abspielen des Videos mit Chunks gefüllt wird und der beim Abspielen des Videos möglichst gefüllt bleiben sollte. In dem Szenario der Fig. 2 umfasst das Streaming-Fenster W sechs Chunks und der Streaming-Knoten beginnt gerade mit dem Abspielen des Videos an der Position 0. Bei fortschreitender Abspielzeit bewegt sich das Streaming-Fenster mit dem sich im Uhrzeigersinn verschiebenden Abspielzeitpunkt fort. Durch entsprechende Mechanismen, welche weiter unten noch näher erläutert werden, wird sichergestellt, dass der Streaming-Knoten bevorzugt immer solche Chunks herunter lädt, welche innerhalb des Streaming-Fensters W liegen, um hierdurch ein verzögerungsfreies Abspielen des Videos zu gewährleisten. Bevor der eigentliche Download eines Videos durch einen Streaming-Knoten gestartet wird, benötigt der Streaming-Knoten zunächst die entsprechenden Download- Quellen, welche in den zuvor erläuterten PeRL- bzw. PaRL-Listen enthalten sind. Deshalb werden durch den Streaming-Knoten Suchanfragen nach dem von ihm be- nötigten Chunk-Nummern in den Ring R gestellt, wobei hierzu bekannte Mechanismen des Chord-Protokolls genutzt werden können. Die Suchanfrage wird dabei an einen der Zugangspunkte des Netzes gerichtet, welche in der Tabelle T für das entsprechend herunter zu ladende Video hinterlegt sind. Es ist dabei egal, über welchen Zugangspunkt eine entsprechende Anfrage in den Ring gestellt wird, da anhand des Chord-Routings die Anfrage sicher direkt ihr Ziel erreicht. Jede Anfrage, die ihr Ziel erreicht hat, wird vom zuständigen Knoten im Ring mit der Übersendung der entsprechenden PeRL- und PaRL-Listen für den entsprechend angefragten Chunk beantwortet.
Anders als beim herkömmlichen File-Sharing werden verschiedene Teile des Videos nicht zufällig oder nach Verfügbarkeit herunter geladen, sondern abhängig vom aktuellen Abspielzeitpunkt. Dies wurde bereits im Vorangegangenen basierend auf dem verwendeten Streaming-Fenster W erläutert. Die Größe des Streaming-Fensters gibt dabei an, wie weit im Voraus das Video herunter geladen sein sollte, um ein be- stimmtes Abspielen zu ermöglichen und eventuelle Download-Schwankungen auszugleichen. Das Streaming-Fenster sollte jedoch auch nicht zu groß sein, da dies immer mit einer Abspielverzögerung bis zur Füllung des Fensters verbunden ist. Die durch das Streaming-Fenster vorgegebene Pufferzeit ist dabei direkt mit einer entsprechenden bereitzustellenden Puffergröße im Streaming-Knoten verbunden. Insbe- sondere ist die bereitzustellende Puffergröße das Produkt aus durchschnittlicher Abspielrate und Pufferzeit. Aus der Puffergröße kann dann direkt bestimmt werden, wie viele Chunks im Voraus herunter geladen werden müssen, um diesen Puffer zu füllen. Die Anzahl der Chunks ist insbesondere der Quotient aus Puffergröße und Chunk-Größe. Bevor im Detail der Vorgang des Bereitstellens und Herunterladens eines Videos basierend auf einem entsprechenden Ring beschrieben wird, werden zunächst die in der nachfolgend beschriebenen Ausführungsform verwendeten Strukturen der herunter zu ladenden Videodateien erläutert.
Die Unterteilung einer entsprechenden Videodatei in kleinere Chunks dient der leichteren Organisation der normalerweise sehr großen Streaming-Dateien. Die Verantwortung für einen Chunk wird an einem entsprechenden Identitätswerts im Ring R abgelegt, der dort von einem Knoten verwaltet wird. Die eigentliche Videoinformati- on wird an sehr vielen verschiedenen Knoten repliziert, wobei die Information, welche Knoten die jeweiligen Chunks enthalten, in den oben erläuterten PeRL- bzw. PaRL-Listen in dem für den jeweiligen Chunk zuständigen Knoten abgespeichert ist.
Bevor initial durch einen Knoten eine Videodatei in das Netz gestellt wird, müssen einige vorbereitende Schritte durch den initialen Quellknoten durchgeführt werden. Insbesondere muss die Videodatei zunächst auf ihre Streaming-Tauglichkeit überprüft werden. Ist die Datei streamingtauglich, wird die gesamte Datei mit einem effizienten und standardisierten Coder, z.B. basierend auf MPEG-4/AVC bzw. H-264 umcodiert. Schließlich wird das Video in die gewählte Dateistruktur umgeformt. Zum Auffinden des Videos wird anschließend ein eindeutiger Video-Hashwert gebildet und ferner werden charakterisierende Informationen des Videos in einem entsprechenden Container für Metainformationen gesammelt und gespeichert. Dieser Container wird weiter unten noch näher erläutert.
Nach Abschluss dieser vorbereitenden Schritte wird ein neuer Eintrag für das Video in der Index-Liste generiert, welche in Fig. 1 mit dem Bezugszeichen T bezeichnet ist. Dort werden die Angaben und der Metacontainer abgelegt und geprüft. Nach erfolgreicher Prüfung wird der Videostream öffentlich gemacht und die Liste T von Zugangspunkten zum Chord-Ring mit deren IP-Adressen angelegt. In dieser Liste wird zunächst nur der initiale Quellknoten eingetragen. In bestimmten Abständen wird die Liste immer wieder aktualisiert und um neue, zum Chord-Ring hinzukommenden Adressen ergänzt.
In der hier beschriebenen Ausfuhrungsform des erfindungsgemäßen Verfahrens wird ein Videostrom nicht nur in kleinere Chunks eingeteilt, sondern die Chunks werden nochmals in kleinere Teilabschnitte aufgeteilt, welche im Folgenden als Atonks (A- tonk = Atomic Chunk) bezeichnet werden. Ein Atonk bezeichnet dabei einen Teil des entsprechenden Chunks und wird mit einem Label markiert. Diese Aufteilung ist nochmals in Fig. 3 verdeutlicht. Im oberen Rechteck Rl ist dabei der Transcodier- Vorgang der ursprünglichen Videodatei zur Bildung von Chunks und Atonks dargestellt. Zunächst erfolgt die Separation des Videos VF in einzelne Chunks C, von denen in Fig. 3 die Chunks mit den Nummern 0 bis 6 angedeutet sind. Jeder einzelne Chunk C wird dann codiert, woraufhin in dem Chunk entsprechende kleinere Atonks AT mit zugewiesenen Labein A, B, C, usw. generiert werden. Die Codierung ist in Fig. 3 dabei für den Chunk mit der Nummer 0 angedeutet.
Zur Bildung der Atonks wird eine vorgegebene Atonk-Map verwendet, welche in Fig. 3 mit AM bezeichnet ist. Die Labels der einzelnen Chunks setzen sich über die gesamte Videodatei fort, d.h. jeder Chunk enthält Atonks AT mit entsprechenden Labels A, B, C, usw. Durch entsprechende Wahl der Labels können Kanäle gebildet werden, wobei einem Kanal alle Atonks eines Labels zugewiesen sind. Je nach gewähltem Label werden dann beim Herunterladen eines Chunks nur die Atonks gemäß dem gewählten Label übertragen. In Fig. 3 ist eine Transmission in entsprechenden Videoströmen Vl bzw. V2 bzw. V3 für Atonks mit den Labein A bzw. B bzw. C angedeutet.
Innerhalb des unteren Rechtecks R2 der Fig. 3 ist die Decodierung der entsprechend herunter geladenen Atonks mit einem Decoder des Streaming-Knotens wiedergegeben. Die einzelnen herunter geladenen Streams können dann basierend auf der glei- chen Atonk-Map AM, die bereits beim Codieren verwendet wurde, den entsprechenden Labein A, B, C, usw. zugeordnet werden. In dem in Fig. 3 dargestellten Ausfüh- rungsbeispiel stellen die einzelnen Labels verschiedene Qualitätsstufen des Videos dar. Der Label A ist in die niedrigste Qualitätsstufe und durch sukzessives Hinzunehmen der Chunks mit dem Label B, C, usw. wird die Wiedergabequalität des Videos weiter erhöht. Durch Multiplexing der Chunks mit den unterschiedlichen La- beln kann somit ein qualitätsangepasstes Abspielen des Videos erreicht werden.
Es gibt verschiedene Möglichkeiten, wie unterschiedliche Kanäle durch Kennzeichnung der Atonks mit Labein gebildet werden können. Im Folgenden werden einige Beispiele für eine entsprechende Kanalisierung des Videostroms mittels Atonks ge- geben. Im einfachsten Fall werden die Video- und Audioinformationen der Videodatei zwar komprimiert, aber untereinander trennbar in die Atonks abgelegt. Die Ablage erfolgt sequentiell und ist damit sehr einfach wieder zu decodieren. Unterschiedliche Qualitätsstufen, wie sie im Vorangegangenen erwähnt wurden, sind dabei jedoch nicht möglich.
Eine weitere Variante ist eine Bild-Kanalisierung, bei der das Videomaterial in drei Kanäle unterteilt wird. Basiert das Material auf den MPEG-Standards, gibt es in einem codierten Video drei unterschiedlich wichtige Arten von Bilderframes. Die wichtigsten sind die sog. I-Frames, welche als Standbilder vorkommen. Sie verbrau- chen den größten Speicherplatz und kommen in der Codierung deshalb nur in vorbestimmten Abständen vor. Zwischen einzelnen I-Frames liegen die wesentlich verlustreicher codierten P-Frames und B-Frames. Diese lassen sich beim Abspielen nur noch mit Hilfe vorangegangener I-Frames oder anderer P-Frames berechnen. Wenn man alle Frames einer Sorte innerhalb eines Chunks einem Atonk-Label zuordnet, so erhält man drei Videokanäle. Der I-Frame-Kanal ist beim Abspielen in jedem Fall erforderlich und liefert eine Art Basis-Qualität. Durch Hinzufügen des Kanals mit den P-Frames und des Kanals mit den B-Frames kann die Qualität des Videos entsprechend gesteigert werden.
Eine weitere Art der Kanalisierung basierend auf Atonks ist die sog. Beschreibungs- Kanalisierung. Diese Kanalisierung ermöglicht die Unterteilung des Videomaterials in beliebig viele Kanäle. Dabei kommt ein aus dem Stand der Technik bekanntes Verfahren zum Einsatz, welches als „Multiple Description Coding" bezeichnet wird. Dieses Verfahren erzeugt verschiedene Beschreibungen von ein und demselben Videomaterial. Ein Schicht-Codierer erstellt dabei eine Basis-Schicht und beliebig viele Erweiterungs-Schichten aus dem Original. Die Basis-Schicht wird - analog wie bei der Bild-Kanalisierung des I-Frame -Kanals - zum Abspielen immer benötigt. Über die Erweiterungs-Schichten können anschließend beliebig viele Qualitätsstufen eingeführt werden. Weist man jeder dieser Schichten bzw. Beschreibungen ein entsprechendes Atonk-Label zu, erhält man die Möglichkeit, beliebig viele Kanäle und da- mit Qualitätsstufen einzuführen, wie dies auch bereits in Fig. 3 angedeutet ist.
Des Weiteren kann eine sog. Auflösungs-Kanalisierung bei der Erzeugung der A- tonks verwendet werden. Diese Kanalisierung erzeugt durch Unterteilung des Videomaterials eine sehr große Anzahl an Kanälen. Dabei wird durch wiederholte Un- ter- Abtastung eine reduzierte Auflösung des Videos erzeugt. Nach jeder UnterAbtastung wird für jedes Bild des Videos durch Interpolation wieder die alte Auflösung erzeugt. Der dabei entstandene Interpolations-Fehler wird weiterverwendet, die interpolierten Bilder werden verworfen und der Unterabtastungs-Prozess wiederholt sich aufsetzend auf der gerade verwendeten Auflösungsstufe. Diese Schritte wieder- holen sich, bis die gewünschte kleinste Auflösung erreicht wurde. Die Version eines jeden Bildes spiegelt den Basis-Kanal wieder. Jede zuvor durchgeführte Unter- Abtastungs- Stufe liefert das Material für einen Erweiterungs-Kanal. Über sie werden die jeweiligen Interpolations-Fehler der Einzelbilder übertragen. Diese Fehlerwerte weisen eine sehr hohe Redundanz auf und lassen sich deswegen sehr gut komprimie- ren. Der Empfänger in der Form des Streaming-Knotens kann mit Hilfe des Basisbilds und den dazugehörigen Interpolations-Fehlern ein fast fehlerfreies Originalbild rekonstruieren. Auf diese Weise lassen sich sehr viele Qualitätsstufen des Videos erzeugen.
Chunks und Atonks unterscheiden sich in mehreren Merkmalen. Herunter geladene Chunks können eigenständig abgespielt werden, dies ist bei Atonks nur bedingt mög- lieh. Atonks können ganz unterschiedliche Größen besitzen, während Chunks gleich groß sind. Je nach verwendeter Codierung müssen nicht alle Atonks zum Abspielen eines Chunks herunter geladen werden. Das Video kommt jedoch ins Stocken, wenn nicht zumindest die notwendigsten Teile aller Chunks herunter geladen werden.
Vorraussetzung für die Einteilung der Chunks in Atonks ist die bereits oben erwähnte Atonk-Map, welche am Anfang eines Chunks und bei jedem Identitätswert im Chord-Ring abgelegt wird. Die Atonk-Map gibt dabei eine Anleitung, welche Atonks herunter geladen wird müssen, um eine gewisse Qualität zu erhalten oder welche Atonks die wichtigsten sind. Atonks können Video- oder Audioinformationen enthalten und sind mit einem Label markiert. Die Bedeutung eines Labels muss in der A- tonk-Map definiert werden. Die Separation eines Videos in Chunks kann je nach verwendeter Codierung vor oder nach der Codierung und der Umformung des Videos in die erwünschte Dateistruktur erfolgen. Die Datei ist dann streamingfähig und für eine verteilte Organisation im Rahmen der in Fig. 1 bzw. Fig. 2 gezeigten Ringstruktur R geeignet. Mit einer der bekannten Hash-Funktionen wird ein Hashwert für das bereitzustellende Video erzeugt. Dazu können charakterisierende Werte des Videos, wie z.B. Einstellungsdatum, Videogröße, Dateistruktur oder ähnliches herangezogen werden.
In der hier beschriebenen Ausführungsform des erfindungsgemäßen Verfahrens werden zur Organisation der Videoverbreitung Metadateien verwendet, welche wichtige Informationen über das entsprechende Video in einem Metacontainer enthalten. Ein Metacontainer stellt dabei ein Objekt dar, in dem mehrere Metadateien zu einem Vi- deostrom gesammelt und gespeichert werden. Die Metadateien an sich sind nicht veränderbar, es können aber neue in den Metacontainer hinzugefügt werden und e- ventuell auch Metadateien entfernt werden. In den Metadateien werden verschiedene charakterisierende Informationen zu der Videodatei gespeichert. Insbesondere können in einem Metacontainer gegebenenfalls auch weitere Tonspuren eines Videos abgelegt werden. In einer besonders bevorzugten Ausfuhrungsform setzt sich der Metacontainer aus einer Video-Metadatei, einer Inhalts-Metadatei, einer Audio-Metadatei sowie gegebenenfalls weiteren Audiospuren zusammen. In der Video-Metadatei werden Informationen zu der Videodatei und dem Aufbau des Videostreams gesammelt. Diese Informationen umfassen insbesondere den Hashwert des bereitgestellten Videos, die Größe der gesamten Videodatei ohne Audio, die Anzahl und Größe der Video- Chunks, den Aufbau und die Größe der Atonks, Kapitelsprungmarken, Qualitätsstufenmerkmale sowie die verwendeten Video-Coder.
In der Inhalts-Metadatei werden charakterisierende Informationen zum Video gesammelt. Diese dienen den Benutzern auch vor dem Abspielen des Videos als Anhaltspunkt, um welches Video es sich handelt. Die Inhalts-Metadatei umfasst insbesondere den Hashwert des Videos, eine Video-Kurzbeschreibung, Informationen zu den Darstellern, dem Produzenten, dem Veröffentlicher und das Genre des Videos sowie gegebennenfalls weitere charakterisierenden Informationen.
In einer Audio-Metadatei werden Informationen zur jeweiligen Tonspur gesammelt. Insbesondere umfasst diese Datei den Hashwert des Videos, die Größe der gesamten Tonspur, die Anzahl und Größe der Ton-Chunks, die verwendeten Audio-Codierer für die Tonspur sowie Audio-Metadaten, wie Sprache, Qualität der Audiospur und dergleichen.
Im Folgenden wird detailliert das Herunterladen eines Videos durch einen entsprechenden Streaming-Knoten basierend auf einer Ausführungsform des erfmdungsge- mäßen Verfahrens erläutert. Zunächst wird auf dem entsprechenden Rechner des Streaming-Knotens durch einen Benutzer die Client-Software zur Durchführung des erfindungsgemäßen Verfahrens gestartet. Im Rahmen der Software kann der Nutzer einen bestimmten Anbieter zum Herunterladen seines Videos auswählen. Die Software kontaktiert dann die ihr vorher bekannte Adresse des Anbieter-Servers, der in Fig. 1 mit SE bezeichnet ist. Nach einem Login kann dann eine aktuelle Liste mit Informationen zu den vorhandenen Videostreams auf den Streaming-Knoten herunter geladen werden. Wenn der Nutzer des Streaming-Knotens ein bestimmtes Video sucht, kann er auch die Videostreams nach bestimmten Kriterien wie Genre, Schauspieler, Sprache und dergleichen, sortieren. Die Suche läuft entweder lokal auf dem Straming-Rnoten ab, wobei in diesem Fall die komplette Liste verfügbarer Video- streams herunter geladen werden muss. Es besteht auch die Möglichkeit, eine Anfrage an den Server des Anbieters zu senden, der dann eine Liste von möglichen Ergebnissen liefert. Die Informationen hierzu werden aus dem zuvor beschriebenen MetaContainer extrahiert, wobei insbesondere die Inhalts-Metadatei dem Nutzer des Streaming-Knotens zur Entscheidungsfmdung dient.
Nach Auswahl eines bestimmten Videostreams über einen Streaming-Knoten wird die Auswahl der aktuell verfügbaren Zugangspunkte herunter geladen, die in der Liste T der Fig. 1 in der Spalte „aktive Knoten" für das entsprechende Video hinterlegt ist. Bevor das eigentliche Streaming beginnt, wird durch den Streaming-Knoten zunächst überprüft, ob er zumindest einen der Zugangspunkte erreichen kann und ob an dieser Stelle der entsprechende Chord-Ring, über den die Chunks des Videos verwaltet werden, zur Verfügung steht. Anschließend wird anhand einer Kompatibilitätsprüfung sichergestellt, ob und mit welchen Einschränkungen der Videostream auf dem Streaming-Knoten abgespielt werden kann.
Erst wenn die obigen Bedingungen ausreichend erfüllt sind, wird von dem Streaming-Knoten erfragt, in welcher Sprache und Qualität das Streaming betrachtet werden soll. Es stehen dabei nur diejenigen Varianten zur Verfügung, die nach der Kompatibilitätsprüfung für erfüllbar eingeschätzt werden und laut dem Meta- Container verfügbar sind. Alternativ kann der Benutzer des Streaming-Knotens, abhängig vom Anbieter, gegebenenfalls auch die Komplettaufnahme auswählen, bei der der Stream aufgenommen wird und erst nach vollständigem Herunterladen abgespielt werden kann.
Während der soeben beschriebenen Abfrage von Informationen durch den Streaming-Knoten werden bereits Prozesse für das Video-Streaming, das Herunterladen von permanent verfügbaren Chunks auf den Streaming-Knoten sowie den Eintritt des Streaming-Knotens in den Chord-Ring gestartet. Diese Prozesse werden im Folgenden erläutert.
In der hier beschriebenen Ausführungsform wird ein Streaming-Knoten, der Chunks aus dem entsprechenden Chord-Ring herunter laden möchte, unter bestimmten Bedingungen auch Teil des Chord-Rings. Das heißt, ein Streaming-Knoten wird auf diese Weise auch an der Verwaltung von Chunks eines Videos beteiligt. Es bestehen dabei verschiedene Möglichkeiten, welchem Identitätswert und damit welchem Iden- titätsintervall der Streaming-Knoten zugewiesen wird. In einer Variante wählt der Streaming-Knoten selbständig einen Identitätswert aus dem Chord-Ring per Zufallsverfahren aus und überprüft dessen Belegung im Ring mit einer speziellen Suche. Falls der entsprechende Identitätswert bereits durch einen Knoten besetzt ist, wiederholt sich dieser Vorgang, bis eine freie Position gefunden wurde. Gegebenenfalls kann der Vorgang auch nach einer vorbestimmten Anzahl von Anfragen abgebrochen werden, wobei in diesem Fall der Streaming-Knoten nicht Teil des Chord-Rings wird.
In einer weiteren Variante wird der Identitätswert, der durch den Streaming-Knoten zu besetzen ist, nach einem festen Muster gewählt. Dabei kann insbesondere berücksichtigt werden, dass häufig nur die ersten Minuten eines Videos durch Benutzer abgespielt werden. In vielen Fällen stellt ein Nutzer nämlich bereits am Anfang des Videos fest, dass er dieses Video nicht mag und bricht das Streaming ab. Auf diese Weise entstehen höhere Belastungen für Ringpositionen mit niedrigeren Identitäts- werten als für Ringpositionen mit höheren Identitätswerten. Diese Tatsache kann durch ein entsprechendes Eintritts-Muster berücksichtigt werden. Der Streaming- Knoten kennt dabei im Vorhinein das Eintrittsmuster. Dieses Muster könnte gegebenenfalls auch in dem Meta-Container des Videos abgelegt sein. Das Muster beschreibt, in welcher festen Reihenfolge die Positionen im entsprechenden Chord- Ring besetzt werden sollen. Demzufolge sendet der Streaming-Knoten eine spezielle Anfrage an den ersten Identitätswert des Musters. Ist dieser Identitätswert besetzt, leitet der angefragte Knoten die Anfrage an den nächsten Identitätswert im Muster weiter. Das wiederholt sich, bis die erste freie Position gefunden wurde, an der sich der Streaming-Knoten dann mit dem Ring verbindet. Gegebenenfalls kann die Suche auch abgebrochen werden, wenn eine vorbestimmte Anzahl an Anfragen nicht zu einem freien Knoten geführt hat.
Unter Umständen kann die Suche nach einem freien Knoten bei einem nahezu vollbesetzten Chord-Ring lange dauern. Da jedoch das eigentliche Abspielen des Vide- ostreams nicht an den endgültigen Eintritt des Streaming-Knotens in den Ring ge- bunden ist, tritt hierdurch jedoch keine Verzögerung beim Streaming auf. Hat der Streaming-Knoten schließlich eine Position im Chord-Ring gefunden, an der er dem Chord-Ring beitreten wird, werden die vom Chord-Protokoll spezifizierten Mechanismen zum Eintritt in den Ring ausgeführt. Diese Mechanismen sind hinlänglich aus dem Stand der Technik bekannt und werden deshalb nicht im Detail erläutert. Von dem neu zu dem Ring hinzukommenden Streaming-Knoten müssen dabei sämtliche Verwaltungsaufgaben zum Erhalt des Rings übernommen werden, die Routing- Tabelle erzeugt und aktuell gehalten werden und die Verantwortung bzw. Zuständigkeit für den zugewiesenen Teil des Rings übernommen werden. Die Zuständigkeit erstreckt sich dabei von der Position, an welcher der Streaming-Knoten dem Ring beitritt, bis zu der Position des im Knoten davor liegenden Knotens. Durch den hinzukommenden Streaming-Knoten müssen ferner auch die entsprechenden PeRL- bzw. PaRL-Listen der jeweiligen Identitätswerte aktuell gehalten werden und Suchanfragen beantwortet bzw. weitergeleitet werden.
In der hier beschriebenen Ausführungsform der Erfindung wird darüber hinaus eine redundante Kopie der in einem Knoten des Rings gesammelten Informationen erstellt, um im Falle des Ausfalls eines Knotens keinen Informationsverlust zu riskieren. Dabei werden die gesammelten Informationen eines Knotens redundant in dem Nachfolgeknoten gespeichert und in regelmäßigen Abständen mit dem Original aktu- alisiert. Falls ein Knoten aus dem Ring ausfällt, kann der Nachfolgeknoten sofort den Zuständigkeitsbereich des ausfallenden Knotens übernehmen. Eine annähernd aktu- eile Version der PeRL- bzw. PaRL-Listen hat er dabei bereits verfugbar. Die Verwaltung im Netz ist somit auch bei häufigen Knotenausfällen weitestgehend sichergestellt.
Sollte der Fall auftreten, dass der Streaming-Knoten den Chord-Ring nicht beitreten kann, weil bereits jede Position im Ring mit einem Knoten besetzt ist, sind verschiedenen Varianten möglich. In einer ersten Variante tritt der Streaming-Knoten dem Ring nicht bei. Dabei kann, wie bereits oben erwähnt wurde, der Versuch des Eintritts in den Ring abgebrochen werden, wenn eine gewisse Anzahl an Eintrittsversu- chen aufgrund von besetzten Ringpositionen gescheitert ist. Solche Knoten übernehmen dann keine Verwaltungsfunktion im Ring. Gegebenenfalls besteht auch die Möglichkeit, dass solche Knoten eine höhere Anzahl von permanent bereitzustellenden Chunks speichern müssen, wobei die permanente Speicherung der Chunks parallel zum Streaming erfolgt, wie weiter unten noch näher erläutert wird. Gegebenen- falls kann der Eintritt eines Streaming-Knotens in einem Ring in regelmäßigen Abständen auch erneut versucht werden. Sollte dann die Anzahl der Knoten im Ring gesunken sein, ist der Eintritt des Knotens in den Ring möglich.
In einer weiteren Variante kann der Eintritt in den Ring auch von Eigenschaften des Knotens abhängig gemacht werden. Beispielsweise können nur solche Streaming- Knoten in den Ring beitreten, welche eine gewisse Ressourcengröße überschreiten, wobei die Ressourcen insbesondere die verfügbare Uploadrate bzw. Rechenkapazität bzw. den verfügbaren Speicher des Knotens betreffen. Alle Streaming-Knoten, die dem Ring nicht beigetreten sind, aktualisieren in festen Abständen eine Liste mit Zugangspunkten in den Ring, wobei eine aktualisierte Liste beispielsweise basierend auf der Liste T gemäß Fig. 1 von dem Videoanbieter herunter geladen werden kann.
Mit der soeben geschilderten Variante, bei der nur Knoten mit ausreichenden Ressourcen dem Ring beitreten, wird verhindert, dass schwache Knoten im Ring überlas- tet werden. Natürlich kann es auch in dieser Variante zu einem vollbesetzten Ring kommen. In diesem Fall wird dann auf die zuvor beschriebene Variante zurückgegriffen, d.h. der Knoten tritt nicht dem Ring bei.
Gemäß den obigen Ausführungsformen sollte sich ein Streaming-Knoten an der Or- ganisation des entsprechenden Chord-Rings beteiligen, indem er dem Ring beitritt. Es kann jedoch auch der Fall auftreten, dass der Streaming-Knoten nicht Teil des Rings wird. Im Unterschied dazu wird in der hier beschriebenen Ausführungsform sichergestellt, dass sich ein Streaming-Knoten jedoch auf jeden Fall an der Verbreitung des Videos dadurch beteiligt, dass er permanent für andere Knoten verfügbare Chunks bereitstellt. Es wird hiermit erreicht, dass jeder Streaming-Knoten auch dazu gezwungen wird, seine Upload-Kapazität für andere Knoten bereitzustellen. Knoten, welche gewisse Chunks permanent zur Verfügung stellen, sind zum einen die Knoten, die eine komplette Kopie des Videos besitzen, und damit alle Chunks permanent enthalten. Ferner übernehmen all die Knoten, welche das Video selbst nur streamen, die Replizierverantwortung für eine gewisse Anzahl an Chunks, solange sie mit dem Netz verbunden sind. Es wird somit eine Replikation der Chunks in einer Mehrzahl von Knoten erreicht, wodurch die Ausfallsicherheit des Netzes erhöht wird.
Fällt beispielsweise ein Knoten im Netz aus, geht bei entsprechend hoher Replikation des Chunks nur ein kleiner Teil der Chunk- Verfügbarkeit verloren. Dies führt zu Stabilität und Ausfallsicherheit. Je höher die Chunk-Replikation ist, desto mehr Quellen hat ein Streaming-Knoten, aus denen er Chunks zum Herunterladen auswählen kann. Wenn während des Herunterladens eines Chunks ein Quellknoten ausfällt, werden die Atonks von dieser Quelle nicht mehr vollständig beim Empfänger an- kommen. Da es jedoch auch genügend andere Quellen gibt, bei denen Atonks erfolgreich herunter geladen werden konnten, wirkt sich der Ausfall nicht durch Unterbrechungen, sondern nur in einer schlechteren Qualität aus. Dabei ist zu berücksichtigen, dass in der hier beschriebenen Ausführungsform des erfmdungsgemäßen Verfahrens sowohl Mehrfach-Downloads für den gleichen Chunk als auch unterschiedli- che Qualitätsabstufungen bei der Codierung des Videos ermöglicht werden. Die permanente Chunk-Replikation wird pro repliziertem Chunk eine vorbestimmte Anzahl an Malen durchlaufen. Die durch einen Streaming-Knoten durchgeführte Replikation eines Chunks läuft dabei nach einem festgelegten Schema ab. Zunächst wählt der Streaming-Knoten eine Chunk-Nummer aus dem Ring aus, aus dem er eine Videodatei gerade streamt. Die Auswahl kann dabei zufällig erfolgen. Nachdem ein entsprechender Identitätswert gewählt wurde und der für diesen Identitätswert zuständige Knoten im Chord-Ring basierend auf einer entsprechenden Suche gefunden wurde, sendet der Streaming-Knoten eine Anfrage an den gefundenen Knoten, mit der die PeRL- und PaRL-Listen der entsprechenden Chunk-Nummer angefordert werden. Nach Erhalt dieser Listen wird der Chunk komplett mit allen Tonspuren und dem entsprechenden Meta-Container des Videos herunter geladen.
Sobald ein Streaming-Knoten einen neuen, zu replizierenden Chunk vollständig herunter geladen hat, lässt er sich selbst in die PeRL-Liste des entsprechenden Knotens eintragen, der in dem Chord-Ring für den Chunk zuständig ist. Um diese Liste immer aktuell zu halten, werden in regelmäßigen Abständen sog. Keep-Alive-Nachrichten ausgetauscht. Dazu sendet der Streaming-Knoten auch nach Abschluss des Streamings für jeden replizierten Chunk eine Nachricht an den für den jeweiligen Identitätswert verantwortlichen Chord-Rnoten und teilt ihm mit, dass die Replikation noch verfügbar ist. Da er die Adresse des für den Identitätswert zuständigen Knotens bereits kennt, besteht der Keep-Alive-Mechanismus normalerweise aus einem einfachen Nachrichtenaustausch. Wenn sich an den Zuständigkeiten im Chord-Ring nichts geändert hat, wird die Meldung quittiert zurückgesendet. Im anderen Fall muss eine Suche nach der Chunk-Nummer in den Ring gestellt werden und nach der Auflösung müssen die Keep-Alive-Nachrichten erneut an die neue Adresse geschickt werden.
Nachfolgend wird nunmehr das eigentliche Video-Streaming durch den Streaming- Knoten erläutert. Dabei wird genau geregelt, auf welche Weise ein Streaming- Knoten entsprechende PeRL- bzw. PaRL-Listen anfordert und von den darin aufge- listeten Knoten die Chunks herunter lädt. Im Regelfall möchte ein Nutzer des Streaming-Knotens das zu streamende Video ganz von Anfang an beginnen. Nichtsdesto- trotz kann ein Nutzer in dem hier beschriebenen Verfahren das Video auch an einem anderen Punkt als am Anfang beginnen, wenn er den Anfang des Videos beispielsweise bereits gesehen hat. In beiden Fällen ist der vom Nutzer gewählte Startpunkt des Videos in eine entsprechende Chunk-Nummer umzusetzen, deren Chunk als ers- tes herunter geladen werden soll. Ein Knoten, der ganz neu im Streaming-Netz ist, wird mit der Chunk-Nummer 0 beginnen. Für springende Teilnehmer müssen die Chunk-Nummern direkt nach der jeweiligen Auswahl berechnet werden. Dies lässt sich in einfacher Weise realisieren, da die Anzahl und Größe der Chunks sowie die Länge des Streams über den oben beschriebenen Meta-Container bekannt ist.
Nachdem über den Meta-Container die Chunk-Nummer des zuerst herunter zu ladenden Chunks bestimmt wurde, wird durch den Streaming-Knoten eine Suche nach dem korrespondierenden Identitätswert in den Chord-Ring gestellt. Es werden dabei die hinlänglich bekannten Suchmechanismen aus Chord verwendet, wobei die Such- abfrage in geeigneter Weise zwischen den Chord-Rnoten weitergeleitet und verarbeitet wird, bis der zuständige Chord-Knoten gefunden ist. Nach Auffinden des zuständigen Chord-Knotens werden als Antwort an den Streaming-Knoten die entsprechenden Replikationslisten des Chord-Knotens, der Meta-Container des Videos sowie die Atonk-Map zurückgesendet. Zusätzlich fügt der zuständige Chord-Rnoten noch weitere Informationen über den aktuellen Chord-Ring- Aufbau an. Der Mechanismus des zusätzlichen Einfügens von Informationen wird im Folgenden als „Suc- cessor Piggyback" bezeichnet. Dabei werden folgende Informationen an die Antwortnachricht angehängt. die eigene Adresse des zuständigen Chord-Knotens; - der Identitätswert bzw. die Position, die der zuständige Chord-Knoten im
Chord-Ring selbst einnimmt; die Adresse des unmittelbaren Nachfolgeknotens im Chord-Ring; der Identitätswert bzw. die Position, die der unmittelbare Nachfolgeknoten im Chord-Ring einnimmt. Anhand der obigen Informationen kann der Streaming-Knoten erkennen, welcher Chord-Knoten für die nächste anzufordernde Chunk-Nummer im Chord-Ring zuständig ist und welche Adresse dieser Knoten besitzt. Auf diese Weise wird erreicht, dass ein Streaming-Knoten keine erneute Anfrage nach Nachfolgeknoten im Chord- Ring zum Herunterladen von neuen Chunks stellen muss, da ihm der Nachfolgeknoten im Chord-Ring bereits bekannt ist. Hierdurch wird der Netzverkehr reduziert.
Fig. 4 zeigt nochmals ausschnittsweise das Herunterladen der PeRL- bzw. PaRL- Listen gemäß dem Successor-Piggyback- Verfahren. Die PeRL- und PaRL-Listen werden dabei allgemein als Replikationslisten bezeichnet. Das Diagramm der Fig. 4 beruht auf dem in Fig. 1 bzw. Fig. 2 dargestellten Chord-Ring R. Ferner wird davon ausgegangen, dass der Stream am Anfang des Videos, d.h. an der Position 0, beginnen soll. Zunächst richtet der Streaming-Knoten SK in Schritt Sl eine Suchanfrage an den Chord-Ring R zum Auffinden der Position 0. Nach Auflösen der Suche wird dem Streaming-Knoten in Schritt S2 die Adresse des Knotens Kl zurückgegeben. Der Streaming-Knoten sendet dann in Schritt S3 eine Anfrage nach den Replikationslisten für den Chunk 0 an den Knoten Kl . Der Knoten Kl beantwortet diese Anfrage in Schritt S4 durch Übersenden der entsprechenden Replikationslisten samt den Informationen über den Nachfolgeknoten K2 an den Streaming-Knoten SK. An- schließend kann der Streaming-Knoten SK dann den entsprechenden Chunk 0 von einem oder mehreren der Knoten aus den Replikationslisten herunter laden.
Im nächsten Schritt S5 fragt der Streaming-Knoten direkt beim Nachfolger K2 die entsprechenden Replikationslisten der Chunks ab, für welche der Nachfolgeknoten K2 zuständig ist. Dies sind die Replikationslisten für die Chunks 1, 2, 3 und 4. Für diese Chunks sind also keine weiteren Suchanfragen im Chord-Ring mehr notwendig. Der Knoten K2 sendet dann in Schritt S6 die entsprechenden Replikationslisten sowie Informationen über den Nachfolgeknoten K3 zurück, woraufhin auch hierfür die Downloads initiiert werden. Das Verfahren setzt sich fort, indem der Streaming- Knoten SK in Schritt S7 eine entsprechende Anfrage nach Replikationslisten für die Chunks 5 und 6 an den Nachfolgeknoten K3 richtet, woraufhin wiederum die ent- sprechenden Replikationslisten an den Streaming-Knoten SK übermittelt werden und der Download der nächsten Chunks beginnen kann.
Wie sich aus Fig. 4 ergibt, kann durch die permanente Übermittlung der Adresse und der Chunk-Position des Nachfolgeknotens auf mehrfache Suchanfragen an den Chord-Ring verzichtet werden, da dem Streaming-Knoten immer bekannt ist, welcher Nachfolgeknoten die nächsten herunter zu ladenden Chunks verwaltet. Wenn ein Streaming-Knoten das Video in Reihenfolge ansieht, hangelt er sich somit in dem Chord-Ring gemäß Fig. 1 bzw. Fig. 2 im Uhrzeigersinn von Identitätswert zu Identi- tätswert, ohne eine weitere Suche in den Chord-Ring stellen zu müssen. Nach jeder Anfrage werden dem Knoten zudem aktuelle Veränderungen, beispielsweise Änderungen an der Zuständigkeit im Chord-Ring, mitgeteilt. Erst wenn der Knoten im Stream springt oder eine Verbindung zu einem der Chord-Knoten fehlschlägt, muss eine erneute Suchanfrage in den Ring gestellt werden.
In kleinen Netzen mit wenigen daran beteiligten Knoten wachsen die PeRL- bzw. PaRL-Listen zu keiner sonderlichen Größe heran. Es ist in diesem Fall unproblematisch, diese Listen komplett zu verbreiten. Ab einer gewissen Anzahl von an der Verteilung des Videos beteiligten Knoten ist es nicht mehr ratsam, die kompletten Listen zur ständigen Verbreitung zu verteilen. Dies ist auch nicht erforderlich, da ein Streaming-Knoten sich zum Download nur eine kleine Anzahl an Quellen heraussucht, von denen er die Chunks herunter lädt.
Demzufolge wird die PeRL-Liste ab einer bestimmten Größe an Einträgen nicht mehr komplett verbreitet. Vielmehr wählt der Chord-Knoten, von dem die Liste angefragt wird, lediglich eine gewisse Untermenge zufälliger Quellen aus und sendet deren Information an den Streaming-Knoten. Es sollte dabei jedoch darauf geachtet werden, dass jede Anfrage mit anderen Quellen bedient wird. Der Chord-Knoten könnte beispielsweise in der PeRL-Liste vermerken, wie oft eine Quelle schon ver- sendet wurde. Dadurch lässt sich eine gute Gleichmäßigkeit der zum Download verwendeten Quellen erreichen. Im Unterschied zu der PeRL-Liste ist es für die PaRL- Liste in der hier beschriebenen Ausfuhrungsform erforderlich, dass diese Liste komplett zu jedem Streaming-Knoten übermittelt wird, wie weiter unten noch näher beschrieben wird.
Ein Streaming-Knoten wählt immer nur die Tonspur und die von ihm gewünschte Videoqualität, d.h. die entsprechenden Atonks, des gerade gestreamten Videos herunter. Mit jeder Anfrage nach den Replikationslisten wird der Streaming-Knoten automatisch als Quelle in die entsprechende PaRL-Liste des angefragten Chunks eingetragen. Dazu werden die Adresse und der Zeitstempel abgelegt. Der entspre- chende Chord-Rnoten, in dessen PaRL-Liste der Streaming-Knoten eingetragen wird, hat allerdings keine Informationen darüber, welche Atonks und ob der gerade eingetragene Knoten überhaupt etwas herunter geladen hat. Außerdem werden für die Einträge der PaRL-Liste keine Keep-Alive-Nachrichten zur Überprüfung der Quellen ausgetauscht, wie dies bei den PeRL-Listen der Fall ist. Somit werden in den PaRL-Listen Knoten geführt, bei denen lediglich die Wahrscheinlichkeit hoch ist, dass sie den Chunk gemäß der PaRL-Liste zumindest teilweise besitzen und zur Verfügung stellen können. Anders als für PeRL-Einträge gibt es somit für die PaRL- Einträge keine Garantien für die Verfügbarkeit der Quellen.
Da die PaRL-Liste immer ganz verteilt werden soll, darf sie nicht zu groß werden. Um dies zu erreichen und gleichzeitig die Verfügbarkeitswahrscheinlichkeit der Quellen aus der PaRL-Liste zu steigern, werden in der hier beschriebenen Ausführungsform einige begrenzende Maßnahmen eingesetzt. Insbesondere werden Knoten aus der PeRL-Liste nicht in die PaRL-Liste aufgenommen. Ferner werden nach Ab- lauf einer festen Zeit alte Einträge in der PaRL-Liste gelöscht. Darüber hinaus meldet ein Streaming-Knoten, der beim Download auf einen nicht verfügbaren Knoten in der PaRL-Liste gestoßen ist, die mangelnde Verfügbarkeit des Knotens an den zuständigen Chord-Rnoten. Dieser löscht den Eintrag, nachdem er dies selbst überprüft hat. Schließlich wird die PaRL-Liste noch durch eine maximale Größe an Einträgen begrenzt, und wenn dieser Wert überschritten wird, werden die ältesten Einträge gelöscht, um für neue Einträge in der PaRL-Liste Platz zu machen. Die obigen Maßnahmen stellen sicher, dass die PaRL-Liste immer so klein wie möglich gehalten wird. Zudem wird die Wahrscheinlichkeit erhöht, dass die Knoten in der PaRL-Liste wirklich den Chunk besitzen, da nach Ablauf einer festen Zeit alte Einträge gelöscht werden und die Nichtverfügbarkeit von Knoten dem Chord-Ring mitgeteilt wird. Ferner wird durch die Beschränkung der PaRL-Liste auf eine maximale Größe auch für große Netze garantiert, dass der entsprechende Chord-Rnoten im Ring nie überlastet wird. Die Verwendung von PaRL-Listen bietet einige Vorteile, wie nachfolgend erläutert wird.
Ein streamender Knoten, der einen Chunk herunter geladen hat, hält diesen zunächst in einem Puffer vor, bis der Chunk tatsächlich abgespielt wird. Anstatt die Datei nach dem Abspielen sofort zu löschen, belässt der Knoten den Chunk in der hier beschriebenen Ausführungsform der Erfindung noch eine Weile in seinem Speicher. Das kann man auch als Rückwärts-Pufferung bezeichnen, da der Chunk sich in Relation zum Abspielzeitpunkt rückwärts bewegt. Zum einen dient der Rückwärtspuffer für den Fall, dass der Nutzer eine Szene sofort nach dem Abspielen noch einmal abspielen möchte. Zum anderen kann der Chunk noch länger über die PaRL-Liste zum Download für andere Knoten angeboten werden. Die Größe des Rückwärts-Puffers kann dem üblicherweise verwendeten Puffer entsprechen, der in Fig. 2 durch das Streaming-Fenster W repräsentiert wird. Gegebenenfalls kann der Rückwärts-Puffer sogar den gesamten bisher abgespielten Stream beinhalten. Dies hängt letztendlich vom verfügbaren Speicherplatz ab. Die Verwendung der PaRL-Liste in Kombination mit der soeben beschriebenen Rückwärts-Pufferung bietet Vorteile, wie anhand der nachfolgenden Beispiele erläutert wird.
Es wird angenommen, dass der streamende Knoten X das Abspielen bei der Chunk- Nummer 0 beginnt, den er bereits herunter geladen hat. Gleichzeitig befindet sich der Streaming-Knoten in der Phase des Pufferaufbaus mit einer Puffergröße von sechs Chunks. Er lädt also die Chunks 1 bis 5 herunter und speichert sie im Puffer. Der Knoten X ist somit in den PaRL-Listen bei den Identitätswerten 0 bis 5 eingetragen. Sein Abspielzeitpunkt wandert nun von Chunk-Nummer 0 auf Chunk-Nummer 1 über. Der Videostream wird aus dem Puffer bedient. Ein anderer Knoten Y tritt auch in das Netz ein und beginnt ebenfalls mit dem Streaming bei der Chunk-Nummer 0. Da X in der PaRL-Liste der Chunk-Nummer 0 steht, kann der Knoten Y nunmehr den Chunk 0 von dem Knoten X herunter laden und abspielen. Auf gleiche Weise kann der Knoten Y zum Pufferaufbau auch die Chunks 1 bis 5 vom Knoten X herunter laden.
Somit lädt in diesem Beispiel der Knoten Y vom Knoten X alle Chunks 1 bis 5 her- unter. Die Videoqualität der Chunks entspricht dabei der Qualität, mit der Chunks beim Knoten X herunter geladen wurden. Über die PaRL-Liste hat der Knoten Y die Informationen, dass der Knoten X die gewünschten Chunks 0 bis 5 besitzt. Dabei bezieht Y den Chunk 0 aus dem Rückwärts-Puffer vom Knoten X und die Chunks 1 bis 5 aus dem normalen Puffer. Ohne Rückwärts-Pufferung müsste sich der Knoten Y eine andere Quelle suchen, da der Chunk 0 dem Knoten Y nicht mehr zur Verfügung stehen würde. Mit Hilfe der PaRL-Liste werden somit zum einen die Knoten in der PeRL-Liste entlastet und zum anderen enthalten die Einträge in der PaRL-Liste ein sequentielles Muster. Gemäß dem obigen Beispiel taucht der Knoten X in den PaRL-Listen für die Chunk-Nummern 0 bis 5 auf, was der Knoten Y durch Vergleich dieser PaRL-Listen herausfinden kann. Wenn der Knoten Y somit den Chunk 0 erfolgreich herunter laden konnte, funktioniert dies mit hoher Wahrscheinlichkeit auch mit den darauffolgenden Chunks 1 bis 5. Zusätzlich ist auch ein Push-Service denkbar, falls der Knoten Y die auf den Chunk 5 folgenden Chunks ebenfalls besitzt. Sobald der Knoten Y die Chunks 1 bis 5 erfolgreich vom Knoten X empfangen hat, sendet X automatisch auch den folgenden Chunk 6 an Y. X sendet die Chunks dabei der Reihe nach solange an den Knoten Y, bis Y den Push stoppt oder in dem Puffer von X keine Chunks mehr enthalten sind.
Insgesamt können somit aufeinander folgend mehrere Chunks von einem Knoten herunter geladen werden. Gemäß dem obigen Beispiel lädt der Knoten Y dabei die
Atonks mit dem gleichen Label aus verschiedenen Chunks des Knotens X herunter. Dies ist vor allem vor dem Hintergrund relevant, dass die Knoten aus der PaRL-Liste nicht den kompletten Informationsinhalt des Chunks besitzen, sondern nur die Sprache und Bildqualität, welche sie selbst gewählt haben. Wenn der Knoten Y bei dem Knoten X somit die gesuchten Atonks für Chunk 0 gefunden hat, dann wird das vor- aussichtlich auch für die Chunks 1 bis 5 so sein. Sollte das tatsächlich nicht der Fall sein, oder sollte X generell eine niedrigere Qualität bzw. andere Sprache betrachtet haben, müssen die fehlenden Atonks von anderen Quellen aus der entsprechenden PaRL-Liste bzw. PeRL-Liste herunter geladen werden.
Basierend auf dem soeben erläuterten Beispiel wird nunmehr auch ersichtlich, warum die PaRL-Listen bei der Verwendung des Successor-Piggyback- Verfahrens immer komplett verteilt werden sollten. Bei dem Successor-Piggyback- Verfahren lernt der Streaming-Knoten durch Weiterreichen von Nachfolger zu Nachfolger sehr schnell die für die Replikationslisten zuständigen Knoten kennen. Von diesen kann er sich sofort einen ganzen Satz von PaRL-Listen für mehrere aufeinander folgende Identitätswerte herunter laden. Diese PaRL-Listen kann er dann miteinander vergleichen, um die Knoten herauszufiltern, von denen er ein ganzes Paket an Chunks herunter laden kann. Die PaRL-Listen müssen deshalb immer komplett bei dem vergleichenden Knoten vorliegen. Wenn nur eine zufällige Auswahl verschickt wird, würde diese im Vergleich nicht mehr so viele Treffer liefern.
Fig. 5 verdeutlicht nochmals die Verwendung eines Puffers mit Rückwärts-Pufferung in einem Streaming-Knoten. Die gespeicherten Chunks sind dabei in Fig. 5 durch entsprechende Balken wiedergegeben, welche nur zum Teil mit dem Bezugszeichen C bezeichnet sind. Der Knoten umfasst dabei einen temporären Puffer B 1 mit einem Vorwärts-Puffer BlOl und einem Rückwärts-Puffer B 102. Der Vorwärts-Puffer entspricht dabei im Wesentlichen dem Streaming-Fenster gemäß Fig. 2. Im Rückwärts- Puffer werden bereits abgespielte Chunks des Streams gespeichert. Die Abspielrichtung ist dabei durch den Pfeil P' angedeutet, und der aktuelle Abspielzeitpunkt ist durch das Bezugszeichen Z wiedergegeben. Wie sich aus Fig. 5 ergibt, wird der temporäre Puffer neben dem Streamen auch zur Bereitstellung der Chunks für PaRL- Listen genutzt. Neben dem temporären Puffer Bl ist ferner ein permanenter Speicher B2 vorgesehen. Sofern dieser Speicher noch nicht gefüllt ist, werden während des Streamens des Videos parallel Chunks herunter geladen, welche permanent zum Download für andere Knoten zur Verfügung gestellt werden. Diese Chunks werden für die entsprechenden PeRL-Listen bereitgestellt.
Im Folgenden wird erläutert, nach welchen Kriterien ein Streaming-Knoten entsprechende Download-Quellen aus den ihm bereitgestellten PeRL- bzw. PaRL-Listen auswählen kann. Es können dabei beliebige Kriterien verwendet werden, wobei im Folgenden nur Beispiele von möglichen Download-Reihenfolgen gegeben werden. Zunächst kann ein Streaming-Knoten überprüfen, ob er den herunter zu ladenden Chunk möglicherweise lokal gespeichert hat. Dabei überprüft er insbesondere seinen Puffer (insbesondere auch seinen Rückwärts-Puffer), die bei ihm hinterlegten permanenten Replikationen, ob eine komplette Kopie des Videos bei ihm gespeichert wird oder ob der Chunk basierend auf dem obigen Push-Mechanismus bereits im ausreichenden Maße gepusht wird.
Sollte der Chunk nicht lokal gespeichert sein, kann beispielsweise zuerst in den PaRL-Listen nach passenden Quellen gesucht werden. Die Suche kann dabei nach der Lokalität unter Berücksichtigung des IP-Prefϊxes der Download-Quelle ablaufen, wobei Download-Quellen mit größerer Nähe zum Streaming-Knoten bevorzugt werden. Ferner können Download-Quellen bevorzugt werden, bei denen man mit einer Verbindung auf mehrere Chunks zugreifen kann. Diese Erkenntnis kann durch den oben beschriebenen Vergleich der herunter geladenen PaRL-Listen von mehreren Identitätswerten erreicht werden. Bevorzugt werden ferner Quellen, von denen Knoten bereits herunter geladen wurden. Gegebenenfalls besteht jedoch auch die Möglichkeit, dass Download-Quellen aus den PaRL-Listen zufällig ausgewählt werden.
Die Auswahl von Download-Quellen aus PeRL-Listen kann gegebenenfalls der Auswahl von Download-Quellen aus den PaRL-Listen nachgeschaltet sein, d.h. ein
Download aus der PeRL-Liste wird erst dann durchgeführt, wenn eine Download- Quelle in der PaRL-Liste nicht gefunden wurde bzw. nicht verfügbar ist. Dies ist jedoch nicht zwingend erforderlich, und es können gegebenenfalls auch parallel zu den PaRL-Listen Download-Quellen aus PeRL-Listen verwendet werden oder auch zunächst nur Download-Quellen aus den PeRL-Listen verwendet werden.
Beim Download aus den PeRL-Listen kann wiederum die Lokalität der Download- Quelle in Bezug auf den Streaming-Knoten unter Berücksichtigung des IP-Prefixes der Download-Quelle berücksichtigt werden, wobei wiederum nähere Download- Quellen bevorzugt werden. Ebenso kann die Download-Quelle gegebenenfalls auch zufällig aus der PeRL-Liste ausgewählt werden.
Bei der Wahl der Download-Quellen ist vor allem die Atonk-Map behilflich, die dem Streaming-Knoten mitteilt, welche Atonks er für eine gewissen Sprache oder Qualität benötigt. Für die noch fehlenden Atonks überprüft der Knoten per Anfrage, ob die Quelle sie zur Verfügung stellt. Ist das der Fall, lädt er die Atonks herunter. Wird auf die Anfragen nicht geantwortet, springt er zu einer anderen Quelle.
Weitere Kriterien bei der Wahl der Download-Quellen können beispielsweise wie folgt sein:
i) Beim Download werden möglichst verschiedene Download-Quellen für einen jeweiligen Chunk berücksichtigt, um die Auswirkungen eines Rnotenaus falls möglichst gering zu halten; ii) es werden Download-Quellen mit der geringsten Latenz zum Streaming- Knoten zur schnelleren Datenübertragung verwendet; iii) für Chunks, die nahe am Abspielzeitpunkt des beim Streaming-Knoten abgespielten Videos liegen, werden Download-Quellen aus der PeRL-Liste gegenüber der PaRL-Liste bevorzugt, um einen zuverlässigen Download sicherzustellen. Nachdem sich ein Streaming-Knoten geeignete Download-Quellen herausgesucht hat, leitet er den Datentransfer durch das Senden von Anfragenachrichten an jede dieser Quellen ein. Die Nachrichten sollen dabei zum einen überprüfen, ob die benötigten Daten tatsächlich an der jeweiligen Quelle liegen. Zum anderen müssen Rah- menbedingungen für den Transfer geschaffen werden. Im Folgenden werden die Informationen aufgelistet, die in dieser Anfragenachricht enthalten sein sollten:
Hashwert des Streams; Chunk-Nummer(n); - Label der gewünschten Atonks;
Priorität der Anfrage; Datenartenrichtwert; Adresse des anfragenden Knotens; Sendezeitstempel.
Anhand des Sendezeitstempels und der Empfangszeit kann die Quelle entscheiden, ob die Nachricht noch aktuell ist. Alte Anfragen werden einfach verworfen. Wenn aufgrund von vielen Anfragen nicht alle sofort bedient werden können, wird die Warteschlange nach Empfangszeiten abgearbeitet.
Anhand der ersten drei der oben aufgelisteten Punkte kann die Download-Quelle genau identifizieren, welche Daten angefordert werden und ob sie verfügbar sind. Über die Priorität erkennt die Download-Quelle außerdem, wie wichtig die Anfrage ist. Davon abhängig entscheidet die Download-Quelle, ob der Transfer zustande kommt und wie viel Datenrate dafür reserviert werden kann.
Der vom anfragenden Knoten übermittelte Datenratenrichtwert soll der Download- Quelle mitteilen, in welchem ungefähren Umfang sich die Belastung für sie einpendeln wird. Dieser Wert richtet sich nach der Abspielrate oder ebenfalls nach der Dringlichkeit, mit der die Atonks benötigt werden. Für die Quelle ist dieser Richtwert neben der Priorität ein Entscheidungskriterium, ob sie die Anfrage annehmen wird. Sollte die Quelle sich bereits am Rande der Auslastung befinden, wird sie Anfragen mit hohen Richtwerten ablehnen.
Die verschiedenen Antwortmöglichkeiten einer Download-Quelle auf die Anfrage können demnach sein:
Ablehnung mit Grund (beispielsweise Überlastung); Nichtverfügbarkeit der Daten; Teilverfügbarkeit der Daten und welche das sind; - Akzeptieren der gesamten Anfrage.
Neben einer geeigneten Auswahl von Download-Quellen werden in der hier beschriebenen Ausführungsform des Verfahrens die auf den Streaming-Knoten herunter zu ladenden Chunks mit verschiedenen Prioritätsnummern versehen und somit in verschiedene Prioritätsklassen eingeteilt. Durch die Prioritätsklassen wird ein priori- sierter Download nach bestimmten Kriterien geschaffen, durch den sichergestellt wird, dass dringend benötigte Chunks, beispielsweise Chunks nahe am aktuellen Abspielzeitpunkt des Videos, schneller und mit höheren Datenraten bearbeitet werden als nicht so dringend benötigte Chunks, beispielsweise solche Chunks, welche zur permanenten Bereitstellung für andere Knoten herunter geladen werden. Um Anfragen nach höher priorisierten Chunks zu bedienen, können auch bereits laufende Datentransfers mit niedriger Priorität pausiert oder ganz abgebrochen werden.
Um die Abspielverzögerung so klein wie möglich zu halten, kann gegebenenfalls auch die Qualität der herunter zu ladenden Chunks adaptiert werden. Insbesondere können Chunks nahe am Abspielzeitpunkt in niedriger Qualität und damit deutlich schneller herunter geladen und abgespielt werden als Chunks mit größerem zeitlichem Abstand zum Abspielzeitpunkt. Eine Qualitätsanpassung sollte insbesondere dann vorgenommen werden, wenn durch den Streaming-Knoten noch kein Puffer aufgebaut wurde. Mit steigendem Puffer kann dann die Qualität der herunter zu ladenden Chunks langsam erhöht und die Abspielrate maximiert werden. Im Folgen- den wird dargelegt, wie in der hier beschriebenen Ausfuhrungsform der Erfindung die Chunks in Prioritätsklassen mit Prioritäten 1 bis 5 eingeteilt werden und durch welche Eigenschaften und Bedeutungen sich diese Prioritäten auszeichnen. Die Prioritätsnummern wurden dabei derart gewählt, dass die Priorität eines Chunks umso höher ist, je kleiner die entsprechende Prioritätsnummer ist.
Priorität 1 :
Diese Priorität gilt für den gesamten Chunk, der mit dem aktuellen Abspielzeitpunkt des Videos übereinstimmt, jedoch noch nicht herunter geladen wurde und zum un- mittelbaren Abspielen benötigt wird. Das heißt, das Abspielen ist momentan unterbrochen. Die Zeit zum Herunterladen dieses Chunks entspricht also der Abspielverzögerung und muss so klein wie möglich sein. Die Anzahl der Chunks mit Priorität 1 ist pro Streaming-Knoten auf genau einen Chunk limitiert. Gegebenenfalls kann der Chunk auf mehrere parallele Downloads aufgeteilt werden. Es werden dabei die ma- ximal möglichen Datenraten von Quelle und Senke ausgeschöpft.
Priorität 2:
Diese Priorität gilt für die Chunks direkt hinter dem Abspielzeitpunkt, und zwar bis zu demjenigen Chunk, der das Ende des Download-Fensters W markiert, welches in Fig. 2 verdeutlicht ist. Die Größe des diesem Download-Fenster entsprechenden Puffers wird dabei aus Test- und Erfahrungswerten abgeleitet und sollte folgende Kriterien erfüllen: Ein Knoten mit einem Puffer der Größe des Streaming-Fensters sollte fehlerfrei streamen, wenn er nur mit Priorität 1 und 2 arbeiten würde. Diese beiden Prioritäten dürfen jedoch nur verwendet werden, um einen schnellen Beginn und danach ein stabiles Abspielen des Streams zu garantieren. Chunks mit Priorität 1 oder 2 treten insbesondere beim Neustart oder bei einem Sprung im Stream auf, bei dem der Puffer komplett neu aufgebaut werden muss. Diese Situationen sind durch den Nutzer des Streaming-Knotens hervorgerufen und können deshalb auch nicht vorhergesehen werden. Damit nicht pausenlos diese hohen Prioritäten verwendet werden und sie damit ihre Wirksamkeit verlieren, muss es noch weitere Prioritäten für den normalen Datentransfer geben, welche im Folgenden erläutert werden. Priorität 3 :
Diese Priorität ist die Standardpriorität der Knoten, bei denen der Puffer gemäß dem Streaming-Fenster W der Fig. 2 komplett gefüllt ist. Sie wird für die Chunks ver- wendet, die zum Auffüllen des Puffers von der minimalen, durch das Streaming- Fenster vorgegebenen Größe bis zu einer maximalen Größe notwendig sind. Die maximale Größe wird dabei in geeigneter Weise derart festgelegt, dass Chunks mit der Priorität 3 im Schritt mit genauso viel Datenrate geliefert werden wie das Abspielen in Anspruch nimmt. Dabei können die Knoten sehr variabel je nach Auslastung die Datenraten variieren lassen und damit den Puffer bis zur maximalen Größe effektiv ausnutzen. Es ist wünschenswert, nach dem Starten des Streams möglichst schnell in diese Klasse zu gelangen und dort zu bleiben. Die Download-Geschwindigkeit wird dabei möglichst maximiert, es sollte jedoch noch Platz für weitere Datentransfers vorhanden sein.
Priorität 4:
Diese Priorität wird zum Herunterladen der permanent zum Download für andere Knoten zur Verfügung stehenden Chunks eingesetzt. Die Priorität ist entsprechend niedriger, da das Herunterladen der Chunks zur permanenten Replikation komplett zeitunkritisch ist. Sie ist jedoch noch wichtiger als ein normaler Dateitransfer, da auf die permanente Replikation möglichst schnell wieder Knoten zugreifen können sollen. Die Raten bestimmen sich aus den im Moment frei verfügbaren Kapazitäten, schwanken also sehr stark mit der Auslastung und werden häufig unterbrochen.
Priorität 5:
Diese Priorität entspricht einem normalen Dateitransfer. Hierdurch soll ermöglicht werden, dass eine Videodatei nicht sofort als Stream abgespielt wird, sondern lediglich aufgenommen wird. Der Download ist also hier ebenfalls komplett zeitunkritisch. Die Chunks werden demnach nicht der Reihenfolge nach über ein Streaming- Fenster ausgewählt, sondern beliebig nach den verfügbaren Kapazitäten gewählt. Wenn sich der Nutzer des Streaming-Knotens doch noch dazu entschließt, den Stream frühzeitig zu starten, wird ihm mitgeteilt, dass es in diesem Fall keine Garantie des fehlerfreien Abspielens gibt. Die Datenraten für die Priorität 5 bestimmen sich einzig und allein aus den noch freien Kapazitäten der verschiedenen Knoten. Der Streaming-Knoten sendet also seine Wünsche an die verschiedenen Download- Quellen aller Chunks. Diese antworten zwar, warten mit dem Dateitransfer jedoch solange, bis sie freie ungenutzte Kapazitäten zur Verfügung haben. Damit keine Nachrichtenflut entsteht, wird die erlaubte Anzahl an Anfragen zum Herunterladen von Chunks mit Priorität 5 zeitlich begrenzt. Es werden mit dieser Methode freie Kapazitäten nutzbar gemacht, denn der aufnehmende Knoten stellt die komplett ge- ladenen Chunks später selbst zur Verfügung. Dann kann man auch mit höheren Prioritäten darauf zugreifen. Nach der Aufnahme des Chunks gehört dieser Knoten zu denen, die das Video komplett besitzen. Der Download von Chunks mit der Priorität 5 sollte also zur Stabilisierung des Netzes beitragen, da Knoten, welche eine Videodatei mit Priorität 5 herunter laden, in der Regel mehr zum Netz beitragen als sie Last verursachen. Außerdem wird es hierdurch auch Knoten mit geringen Ressourcen und Datenraten ermöglicht, sich ein entsprechendes Video aus dem Netz herunterzuladen.
Durch eine Verminderung der Qualität von herunter zu ladenden Chunks mit hoher Priorität, insbesondere mit Priorität 1 und 2, kann die Abspielverzögerung eines Videos verkürzt werden und der Pufferaufbau beschleunigt werden. Hierdurch wird erreicht, dass ein Nutzer, der ein Video herunter laden möchte, nicht sehr lange auf das Abspielen des Videos warten muss. Dafür nimmt er zwar eine schlechtere Qualität in Kauf, die jedoch sehr schnell nach dem Start ihr Optimum erreicht. Die Quali- tat des Videos wird vorzugsweise durch die Priorität folgendermaßen beeinflusst:
Alle Knoten, die einen Chunk mit Priorität 1 herunter laden, wählen nur A- tonks aus dem Chunk aus, die für eine minimale Qualität nötig sind. Dadurch wird der Chunk schneller abspielbar, die Qualität ist jedoch niedriger als beim Herunterladen aller Atonks aus dem Chunk. Ähnliches gilt für Chunks mit der Priorität 2. Allerdings entscheidet hierbei der Zeitpunkt, zu dem der Chunk benötigt wird, darüber, welche Qualität benutzt wird. An dem Chunk wird solange geladen, bis er entweder komplettiert wurde oder die Priorität auf 1 übergeht. Im zweiten Fall wird der Chunk so- fort abgespielt, vorausgesetzt, dass die Atonks für die minimale Qualität verfügbar sind.
Bei der Priorität 3 hängt die Qualität der Chunks von der durchschnittlichen Downloadrate ab. Diese wiederum hängt von den möglichen Raten der Quellen und des Empfängers ab. Da die heutigen Internetanbindungen sehr stark asynchron sind, wird voraussichtlich der Upload, also die Datenrate der Quelle, das die Qualität bestimmende Kriterium sein.
Bei Downloads mit Priorität 4 und 5 werden die Chunks in voller Größe herunter geladen. Es wird solange gewartet, bis alle Atonks komplett herunter geladen sind.
Weiterhin beeinflussen die Prioritäten auch die Wahl der Quellen. Vorzugsweise werden deshalb sehr zeitkritische Anfragen verstärkt an diejenigen Knoten gestellt, welche die Chunks mit Sicherheit besitzen, d.h. welche als Einträge in der PeRL- Liste des entsprechenden Chord-Rnotens hinterlegt sind. Es sind hierbei folgende Kriterien denkbar, wie die Download-Quellen in Abhängigkeit von den oben dargelegten Prioritäten ausgewählt werden:
Bei Anfragen nach Chunks mit Priorität 1 werden zuerst die Knoten aus der PeRL-Liste befragt. Sollten diese überlastet sein, kann man immer noch auf die Knoten aus der PaRL-Liste wechseln. Im Normalfall werden dadurch kürzere Antwortzeiten ermöglicht. Da die gewünschten Atonks mit Sicherheit vorhanden sind, können sie auch mit Sicherheit akzeptiert werden. Da sie ferner die höchste Priorität besitzen, werden sie mit hoher Wahrscheinlichkeit auch sofort bedient werden. Der Knoten muss die Anfragen somit nicht er- neut an andere Quellknoten versenden und spart somit Zeit. Ähnliches gilt für den Download von Chunks mit Priorität 2. Hier wird jedoch zunächst versucht, möglichst viele Atonks aus der PaRL-Liste zu holen. Erst nach Ablauf einer gewissen Zeit werden für die noch fehlenden Atonks die Knoten aus der PeRL-Liste verwendet. - Bei den weniger wichtigen Prioritäten wird versucht, die PeRL-Knoten so gut wie möglich zu entlasten.
Eine Anfrage nach einem Chunk wird in der hier beschriebenen Ausführungsform des erfindungsgemäßen Verfahrens redundant an verschiedene Download-Quellen gleichzeitig ausgesendet. Das heißt, je nach Priorität können auch mehrere Anfragen nach ein und demselben Atonk an mehrere unterschiedliche Quellen gesendet werden. Für den Fall von singulären Downloads wird dann pro Chunk nur diejenige Quelle verwendet, welche die höchste Kapazität verspricht. Im Falle von multiplen Downloads werden pro Chunk und Typ alle Quellen verwendet, welche die Anfrage akzeptiert haben. Bei den Prioritäten 3, 4 und 5 benötigt man nicht unbedingt redundante Anfragen, da dem Knoten genug Zeit zum Warten bleibt.
Nachdem eine Quelle zum Herunterladen eines Atonks gefunden wurde und die Quelle eine Anfrage des Streaming-Knotens für einen Download akzeptiert hat, kann der Download initiiert werden. Der Download erfolgt abhängig von den Gegebenheiten der am Download beteiligten Knoten auf unterschiedliche Weise.
Im Normalfall werden die Daten des Videos von der Quelle zum Empfänger ohne „Hand-Shake" über UDP übertragen. Wenn der Empfänger hinter einer Fire- wall/NAT agiert, wird der Transfer mit TCP gelöst. Das heißt, der Streaming-Knoten öffnet dann die Datenverbindung und damit einen Port in der Firewall. Kommt auf eine Download-Anfrage keine Antwort zurück, wird nach Ablauf eines Timers erneut nach einer anderen Quelle gesucht. Das Problem, Verbindungen in Peer-to- Peer-Netzen auch mit Knoten zu ermöglichen, die sich hinter Barrieren befinden, ist inzwischen durch bekannte Mechanismen sehr gut gelöst. Diese Mechanismen kön- nen auch in der hier beschriebenen Ausfuhrungsform zum Download von Knoten hinter Firewalls eingesetzt werden.
Der bevorzugte Anwendungsfall des hier beschriebenen Verfahrens ist das Streamen des Videos, d.h. das Abspielen des Videos parallel zum Herunterladen. Zum Abspielen wird dabei der entsprechende Chunk, der komplett herunter geladen wird, decodiert, wobei hierzu zunächst eine Kopie des Chunks erstellt wird, denn das Original dient anderen Knoten weiterhin als Quelle. Mit einem geeigneten Medienplayer wird dann die decodierte Datei abgespielt, wobei dem Medienplayer als Quelle die lokal gespeicherte Mediendatei angegeben wird. Dem Medienplayer ist dabei nicht bekannt, wie die Daten an diese Stelle kommen. Für den Player scheint es so, als enthielte die Mediendatei an dieser Stelle bereits den gesamten Stream. Auf diese Weise lassen sich alle Video-on-Demand-Funktionen wie Vorspulen oder Springen realisieren. Ist der gewünschte Teil des Videos noch nicht vorhanden, wird eine entspre- chende Anfrage des Medienplayers zuvor abgefangen und in die gewünschte Chunk- Nummer umgesetzt, welche dann aus dem Netz so schnell wie möglich herunter geladen, lokal decodiert und in die abzuspielende Mediendatei integriert wird, so dass der Medienplayer sie dann abspielen kann. Der Medienplayer wartet solange. Anschließend füllt er seinerseits einen Streaming-Puffer, den er zum flüssigen Abspie- len benötigt. Der soeben beschriebene Mechanismus erlaubt den Einsatz von verbreiteten Medienplayern zum Abspielen von mit dem erfmdungsgemäßen Verfahren gestreamten Mediendateien.
Das soeben beschriebene Verfahren weist eine Reihe von Vorteilen auf. Mit dem Verfahren wird eine Verteilplattform von Medieninhalten für verschiedenste Anbieter geschaffen, wobei insbesondere ein Video-on-Demand-Streaming ermöglicht wird. Das Verfahren basiert dabei auf der Implementierung einer dezentralen Struktur für jedes Video, wobei einzelne Abschnitte eines Videos auf verschiedene Knoten der Struktur verteilt werden, so dass sie von verschiedenen Rechnern im Netz herun- ter geladen werden können. Das System kümmert sich dabei im Hintergrund darum, dass eine Mediendatei beim Streamen ohne Stoppen abgespielt werden kann. Das Verfahren ermöglicht die Implementierung sowohl von Video-on-Demand als auch von Videorecorder-Funktionen. Es ist dabei keine zentrale Einheit mehr notwendig, um die Verwaltung oder Bereitstellung des Videoaustausches zu organisieren. Darüber hinaus beteiligt sich jeder Knoten, der Medieninhalte herunter lädt, gleichzeitig auch an der Verteilung der Medieninhalte im Netz bzw. gegebenenfalls auch an der Verwaltung des Videos in einer dezentralen Struktur.
Das erfmdungsgemäße Verfahren kann in verschiedensten Anwendungsbereichen eingesetzt werden. Beispielsweise können mit dem Verfahren kostenlose oder Be- zahl- Video-Dienste angeboten werden und Unternehmen können gegebenenfalls auch kostenlos selbst produziertes Medienmaterial zur Verbreitung im Markt bereitstellen. Ebenso kann das Verfahren gegebenenfalls auch durch Privatanwender genutzt werden, welche eigenes Videomaterial per Streaming in das Datennetz stellen möchten.

Claims

Patentansprüche
1. Verfahren zum Bereitstellen von Medieninhalten für eine Mehrzahl von Knoten (Kl, ..., K8, K', K") in einem Datennetz, wobei die Medieninhalte eine oder mehrere Mediendateien (VF) umfassen und die Knoten (Kl, ..., K8, K', K") über Adressen in dem Datennetz adressierbar sind, bei dem: für jede im Datennetz bereitzustellende Mediendatei (VF) eine dezentrale, über einen oder mehrere erste Knoten (Kl, ..., K8) verwaltete Struktur (R) dadurch gebildet wird, dass die jeweilige Mediendatei (VF) in eine Mehr- zahl von Abschnitten (C) aufgeteilt wird und den Abschnitten (C) jeweils ein Identitätswert (0, ..., 31) aus einem Identitätsintervall umfassend aufeinander folgende Identitätswerte (0, ..., 31) zugeordnet wird, wobei der oder die ersten Knoten (Kl, ..., K8) jeweils für ein Teilintervall aus dem Identitätsintervall und hierdurch für eine Teilmenge an Abschnitten (C) aus der jeweiligen Mediendatei (VF) zuständig sind; in einem jeweiligen ersten Knoten (Kl, ..., K8) der dezentralen Struktur (R) eine Anzahl von zweiten Knoten (K', K") mit deren Adressen hinterlegt wird, wobei der oder die zweiten Knoten (K', K") zum Bereitstellen der Abschnitte (C) gemäß dem Teilintervall, für das der jeweilige erste Knoten (Kl , ... , K8) zuständig ist, vorgesehen sind; ein Empfangsknoten (SK), der zum Herunterladen zumindest eines Teils einer jeweiligen Mediendatei (VF) vorgesehen ist, mittels einer oder mehrerer Anfragen an die ersten Knoten (Kl, ..., K8) in der dezentralen Struktur (R) der Mediendatei (VF) die Adressen von zweiten Knoten (K', K") um- fassend zumindest einen Teil derjenigen zweiten Knoten (K', K") abruft, welche zum Bereitstellen der Abschnitte (C) des zumindest einen Teils der Mediendatei (VF) vorgesehen sind, und Abschnitte (C) umfassend die Abschnitte (C) des zumindest einen Teils der Mediendatei (VF) von zumindest einem Teil der zweiten Knoten (K', K"), deren Adressen abgerufen wur- den, herunter lädt.
2. Verfahren nach Anspruch 1, bei dem eine jeweilige Mediendatei (VF) einen abspielbaren Medienstrom, insbesondere einen Audio- und/oder Videostrom, enthält und die Abschnitte (C) der Mediendatei (VF) zeitlich aufeinander folgende Abschnitte (C) des Medienstroms sind, wobei die Identitätswerte (0, ..., 31) des Identitätsintervalls in Abspielreihenfolge des Medienstroms den Abschnitten (C) zugeordnet werden, so dass ein höherer Identitätswert (0, ..., 31) einem später abgespielten Abschnitt (C) im Medienstrom entspricht.
3. Verfahren nach Anspruch 2, bei dem ein Empfangsknoten (SK) parallel zum Herunterladen die herunter geladenen Abschnitte (C) des Medienstroms abspielt.
4. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die dezentrale Struktur (R) eine Ringstruktur ist und/oder über ein Peer-To-Peer-Protokoll verwaltet wird, wobei für die jeweilige Mediendatei (VF) insbesondere ein
Chord-Ring gebildet wird.
5. Verfahren nach einem der vorhergehenden Ansprüche, bei dem ein Empfangsknoten (SK) ein oder mehrere der von ihm herunter geladenen Abschnitte (C) anderen Knoten dadurch bereitstellt, dass er mit seiner Adresse als zweiter
Knoten (K', K") in den entsprechenden ersten Knoten (Kl, ..., K8), welche für die vom Empfangsknoten (SK) herunter geladenen Abschnitte (C) zuständig sind, hinterlegt wird.
6. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Anzahl von in einem jeweiligen ersten Knoten (Kl, ..., K8) hinterlegten zweiten Knoten (K', K") in anderen ersten Knoten (Kl, ..., K8) repliziert wird, insbesondere zumindest in einem Nachbarknoten, welcher für ein Teilintervall zuständig ist, das sich an das Teilintervall anschließt, für das der jeweilige erste Knoten (Kl, ... , K8) zuständig ist.
7. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Anzahl von in einem jeweiligen ersten Knoten (Kl, ..., K8) hinterlegten zweiten Knoten (K', K") in der Form von einer oder mehreren Listen (PeRL, PaRL) hinterlegt wird.
8. Verfahren nach Anspruch 7, bei dem das oder die Listen in einem jeweiligen ersten Knoten (Kl, ..., K8) eine oder mehrere erste und/oder zweite Listen (PeRL, PaRL) umfassen, wobei eine erste Liste (PeRL) zweite Knoten (K') mit permanent zum Herunterla- den durch andere Knoten verfügbaren Abschnitten enthält, wobei die Verfügbarkeit des jeweiligen zweiten Knotens (K') durch regelmäßigen Nachrichtenaustausch des zweiten Knotens (K') mit dem jeweiligen ersten Knoten (Kl , ... , K8) überprüft wird; eine zweite Liste (PaRL) diejenigen Knoten (K") umfasst, welche bei dem jeweiligen ersten Knoten (Kl, ..., K8) innerhalb eines vorbestimmten zurückliegenden Zeitraums Adressen von zweiten Knoten (K', K") abgerufen haben.
9. Verfahren nach Anspruch 8, bei dem ein Empfangsknoten (SK) Abschnitte (C) von zweiten Knoten (K', K") aus der ersten und/oder zweiten Liste (PeRL,
PaRL) zur Bereitstellung als permanent verfügbare Abschnitte (C) herunter lädt, wobei die herunter zu ladenden Abschnitte (C) nach einem oder mehreren vorbestimmte Kriterien, insbesondere zufällig, ausgewählt werden.
10. Verfahren nach Anspruch 8 oder 9, wenn abhängig von Anspruch 3, bei dem zweite Knoten (K', K") aus der ersten Liste (PeRL) umso stärker zum Herunterladen eines abzuspielenden Abschnitts (C) durch den Empfangsknoten (SK) bevorzugt werden, je näher der abzuspielende Abschnitt (C) am aktuellen Ab- spielzeitpunkt der Mediendatei (VF) liegt.
11. Verfahren nach einem der vorhergehenden Ansprüche, bei dem ein Empfangsknoten (SK) in Abhängigkeit von einem oder mehreren Kriterien als erster Knoten (Kl, ..., K8) in die dezentrale Struktur (R) einer jeweiligen Mediendatei (VF) dadurch aufgenommen wird, dass dem Empfangsknoten (SK) die Zu- ständigkeit für ein Teilintervall aus dem Identitätsintervall zugewiesen wird.
12. Verfahren nach Anspruch 11, bei dem das oder die Kriterien derart ausgestaltet sind, dass für einen Empfangsknoten (SK) eine Maximalanzahl von Malen nach einem Teilintervall des Identitätsintervalls gesucht wird, dessen Zustän- digkeit ein neuer Knoten in der dezentralen Struktur (R) übernehmen kann, wobei im Falle, dass kein Teilintervall nach der Maximalanzahl von Malen gefunden wird, der Empfangsknoten (SK) nicht als erster Knoten (Kl, ..., K8) in die dezentrale Struktur (R) aufgenommen wird.
13. Verfahren nach Anspruch 11 oder 12, bei dem gemäß dem oder den Kriterien nur solche Empfangsknoten (SK) in die dezentrale Struktur (R) aufgenommen werden, welche eine vorbestimmte Mindestgröße an Ressourcen bereitstellen können.
14. Verfahren nach einem der Ansprüche 11 bis 13, wobei dem in die dezentrale Struktur (R) aufzunehmenden Empfangsknoten (SK) zufällig oder nach einem vorbestimmen Muster eine Zuständigkeit für ein Teilintervall zugewiesen wird, wobei das vorbestimmte Muster insbesondere derart ausgestaltet ist, dass für Abschnitte (C) mit kleinen Identitätswerten (0, ..., 31) mehr erste Knoten (Kl, ..., K8) zuständig sind als für Abschnitte mit größeren Identitätswerten (0, ...,
31).
15. Verfahren nach einem der vorhergehenden Ansprüche, bei dem in der dezentralen Struktur (R) ein jeweiliger erster Knoten (Kl, ..., K8) den Nachbarknoten kennt, welcher für ein Teilintervall zuständig ist, das sich an das Teilintervall, für das der jeweilige erste Knoten (Kl, ..., K8) zuständig ist, in Richtung hin zu höheren Identitätswerten (0, ..., 31) anschließt, wobei die Adresse des Nachbarknotens durch den jeweiligen ersten Knoten (Kl, ..., K8) bei einem Abruf der Adressen der zweiten Knoten (K', K") an den Empfangsknoten (SK) übermittelt wird.
16. Verfahren nach Anspruch 15, bei dem der jeweilige erste Knoten (Kl, ..., K8) über weitere Informationen über den Nachbarknoten verfügt, welche neben der Adresse des Nachbarknotens an den Empfangskoten (SK) übermittelt werden und aus denen der Empfangsknoten (SK) das Teilintervall ermittelt, für das der Nachbarknoten zuständig ist.
17. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Abschnitte (C) durch einen Empfangsknoten (SK) in Abhängigkeit von einer oder mehreren, für die Abschnitte (C) vergebenen Prioritäten herunter geladen werden, wobei Abschnitte (C) mit höheren Prioritäten beim Herunterladen bevorzugt werden.
18. Verfahren nach Anspruch 17, wenn abhängig von Anspruch 3, bei dem für einen Empfangsknoten (SK) ein erstes Zeitintervall (W) vorgegeben ist, wobei der Empfangsknoten (SK) ausgehend von seinem aktuellen Abspielzeitpunkt
(Z) des Medienstroms Abschnitte (C), welche im abgespielten Medienstrom in dem ersten Zeitintervall (W) nach dem aktuellen Abspielzeitpunkt (Z) liegen, mit höherer Priorität als andere Abschnitte herunter lädt.
19. Verfahren nach Anspruch 18, bei dem Abschnitte (C) innerhalb des ersten Zeitintervalls (W), welche den aktuellen Abspielzeitpunkt enthalten, mit höherer Priorität als die anderen Abschnitte (Z) im ersten Zeitintervall (W) herunter geladen werden.
20. Verfahren nach Anspruch 18 oder 19, bei dem für einen Empfangsknoten (SK) ein zweites Zeitintervall vorgegeben ist, welches größer als das erste Zeitinter- vall (W) ist, wobei der Empfangsknoten (SK) ausgehend von seinem aktuellen Abspielzeitpunkt (Z) des Medienstroms Abschnitte, welche im abgespielten Medienstrom in dem zweiten Zeitintervall nach dem aktuellen Abspielzeitpunkt (Z) und außerhalb des ersten Zeitintervalls (W) liegen, mit niedrigerer Priorität als die Abschnitte innerhalb des ersten Zeitintervalls (W) herunter lädt.
21. Verfahren nach Anspruch 20, wenn abhängig von Anspruch 7, bei dem ein Empfangsknoten (SK) Abschnitte (C) zur Bereitstellung als permanent verfügbare Abschnitte (C) mit niedrigerer Priorität als die Abschnitte (C) aus dem ers- ten oder zweiten Zeitintervall nach dem aktuellen Abspielzeitpunkt (Z) herunter lädt.
22. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Abschnitte (C) einer jeweiligen Mediendatei (VF) jeweils in kleinere Teilabschnitte (AT) aufgeteilt sind.
23. Verfahren nach Anspruch 22, bei dem bei Herunterladen eines Abschnitts (C) der gesamte Abschnitt (C) oder eine Auswahl von Teilabschnitten (AT) aus dem Abschnitt (C) herunter geladen wird.
24. Verfahren nach Anspruch 22 oder 23, bei dem die Teilabschnitte (AT) aller Abschnitte (C) einer jeweiligen Mediendatei (VF) in mehrere Kanäle gruppiert sind, welche verschiedene Qualitätsstufen der Mediendatei (VF) repräsentieren.
25. Verfahren nach einem der Ansprüche 22 bis 24, bei dem ein Empfangsknoten (SK) Informationen über die Teilabschnitte (AT), insbesondere hinsichtlich der Zuordnung der Teilabschnitte (AT) zu Qualitätsstufen, aus einer Informationsdatei (AM) ausliest.
26. Verfahren nach einem der vorhergehenden Ansprüche, bei dem Informationen zu einer jeweiligen Mediendatei (VF) in einem Meta-Container bereitgestellt werden, welcher von einem Empfangsknoten (SK) herunter geladen werden kann.
27. Verfahren nach einem der vorhergehenden Ansprüche, bei dem eine Mehrzahl von Mediendateien (VF) über eine suchbaren Index im Datennetz bereitgestellt werden, wobei für jeden Index zumindest ein Teil der Adressen der ersten Knoten (Kl, ..., K8) der für die jeweilige Mediendatei (VF) gebildeten dezentralen Struktur (R) hinterlegt ist.
28. System zum Bereitstellen von Medieninhalten für eine Mehrzahl von Knoten (Kl, ..., K8, K', K") in einem Datennetz, wobei die Medieninhalte eine oder mehrere Mediendateien (VF) umfassen und die Knoten (Kl, ..., K8, K', K") über Adressen in dem Datennetz adressierbar sind, wobei das System die Mehrzahl von Knoten (Kl , ... , K8, K' , K") derart verwaltet, dass: - für jede im Datennetz bereitzustellende Mediendatei (VF) separat eine dezentrale, über einen oder mehrere erste Knoten (Kl, ..., K8) verwaltete Struktur (R) dadurch gebildet wird, dass die jeweilige Mediendatei (VF) in eine Mehrzahl von Abschnitten (C) aufgeteilt wird und den Abschnitten (C) jeweils ein Identitätswert (0, ..., 31) aus einem Identitätsintervall umfas- send aufeinander folgende Identitätswerte (0, ..., 31) zugeordnet wird, wobei der oder die ersten Knoten (Kl, ..., K8) jeweils für ein Teilintervall aus dem Identitätsintervall und hierdurch für eine Teilmenge an Abschnitten (C) aus der jeweiligen Mediendatei (VF) zuständig sind; in einem jeweiligen ersten Knoten (Kl, ..., K8) der dezentralen Struktur (R) eine Anzahl von zweiten Knoten (K', K") mit deren Adressen hinterlegt wird, wobei der oder die zweiten Knoten (K', K") zum Bereitstellen der Abschnitte (C) gemäß dem Teilintervall, für das der jeweilige erste Knoten (Kl, ..., K8) zuständig ist, vorgesehen sind; ein Empfangsknoten (SK), der zum Herunterladen zumindest eines Teils einer jeweiligen Mediendatei (VF) vorgesehen ist, mittels einer oder mehrerer Anfragen an die ersten Knoten (Kl, ..., K8) in der dezentralen Struktur (R) der jeweiligen Mediendatei (VF) die Adressen von zweiten Knoten (K', K") umfassend zumindest einen Teil derjenigen zweiten Knoten (K', K") abruft, welche zum Bereitstellen der Abschnitte (C) des zumindest einen Teils der Mediendatei (VF) vorgesehen sind, und Abschnitte (C) umfassend die Abschnitte (C) des zumindest einen Teils der Mediendatei (VF) von zumindest einem Teil der zweiten Knoten (K', K"), deren Adressen abgerufen wurden, herunter lädt.
29. System nach Anspruch 28, welches derart ausgestaltet ist, dass mit dem System ein Verfahren nach einem der Ansprüche 1 bis 25 durchführbar ist.
30. Knoten zur Verwendung in einem Verfahren nach einem der Ansprüche 1 bis 27, wobei der Knoten (Kl, ..., K8, K', K") derart ausgestaltet ist, dass er bei Betrieb in dem Verfahren als erster Knoten (Kl, ..., K8) oder als zweiter Rno- ten (K', K' ') oder als Empfangsknoten fungiert.
PCT/EP2010/052606 2009-03-13 2010-03-02 Verfahren und system zum bereitstellen von medieninhalten für eine mehrzahl von knoten in einem datennetz WO2010102926A2 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/256,310 US20120084392A1 (en) 2009-03-13 2010-03-02 Method and system for providing media contents for a plurality of nodes in a data network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102009012992A DE102009012992B4 (de) 2009-03-13 2009-03-13 Verfahren und System zum Bereitstellen von Medieninhalten für eine Mehrzahl von Knoten in einem Datennetz
DE102009012992.8 2009-03-13

Publications (2)

Publication Number Publication Date
WO2010102926A2 true WO2010102926A2 (de) 2010-09-16
WO2010102926A3 WO2010102926A3 (de) 2011-01-13

Family

ID=42355400

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2010/052606 WO2010102926A2 (de) 2009-03-13 2010-03-02 Verfahren und system zum bereitstellen von medieninhalten für eine mehrzahl von knoten in einem datennetz

Country Status (3)

Country Link
US (1) US20120084392A1 (de)
DE (1) DE102009012992B4 (de)
WO (1) WO2010102926A2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120257880A1 (en) * 2011-04-07 2012-10-11 Sony Corporation Reproducing apparatus and reproducing method

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9253548B2 (en) * 2010-05-27 2016-02-02 Adobe Systems Incorporated Optimizing caches for media streaming
WO2012137422A1 (ja) * 2011-04-05 2012-10-11 日本電気株式会社 情報処理装置
US9300814B2 (en) * 2011-09-12 2016-03-29 Microsoft Technology Licensing Llc Network adaptive content download
US10432541B2 (en) 2016-12-06 2019-10-01 Microsoft Technology Licensing, Llc Source prioritized useful sub-payload computer data transmissions
US10694221B2 (en) * 2018-03-06 2020-06-23 At&T Intellectual Property I, L.P. Method for intelligent buffering for over the top (OTT) video delivery
US11429891B2 (en) 2018-03-07 2022-08-30 At&T Intellectual Property I, L.P. Method to identify video applications from encrypted over-the-top (OTT) data

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030204602A1 (en) * 2002-04-26 2003-10-30 Hudson Michael D. Mediated multi-source peer content delivery network architecture
US7941553B2 (en) * 2002-10-18 2011-05-10 International Business Machines Corporation Method and device for streaming a media file over a distributed information system
GB0400474D0 (en) * 2004-01-10 2004-02-11 Koninkl Philips Electronics Nv Searching content directories
US8688803B2 (en) * 2004-03-26 2014-04-01 Microsoft Corporation Method for efficient content distribution using a peer-to-peer networking infrastructure
DE102006021591B3 (de) * 2006-05-09 2007-04-05 Siemens Ag Verfahren und Anordnung zur Datenübertragung zwischen Peer-to-Peer-Netzwerken
US9578288B2 (en) * 2007-06-08 2017-02-21 At&T Intellectual Property I, L.P. Peer-to-peer distributed storage for internet protocol television
JP4998197B2 (ja) * 2007-10-15 2012-08-15 ソニー株式会社 コンテンツ取得装置、プログラム、コンテンツ取得方法、およびコンテンツ取得システム
JPWO2009113371A1 (ja) * 2008-03-12 2011-07-21 日本電気株式会社 コンテンツ情報提示装置、コンテンツ情報提示システム及びそれに用いるコンテンツ情報提示方法
US20090248793A1 (en) * 2008-03-25 2009-10-01 Contribio Ab Providing Content In a Network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
W.-P. K. YIU; X. JIN; S.-H. G. CHAN: "Distributed Storage to Support User Interactivity in Peer-to-Peer Video Streaming", IEEE ICC '06, 2006

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120257880A1 (en) * 2011-04-07 2012-10-11 Sony Corporation Reproducing apparatus and reproducing method
CN102736989A (zh) * 2011-04-07 2012-10-17 索尼公司 再现装置和再现方法
US8588591B2 (en) * 2011-04-07 2013-11-19 Sony Corporation Reproducing apparatus and reproducing method

Also Published As

Publication number Publication date
DE102009012992A1 (de) 2010-09-23
WO2010102926A3 (de) 2011-01-13
US20120084392A1 (en) 2012-04-05
DE102009012992B4 (de) 2011-03-03

Similar Documents

Publication Publication Date Title
DE102009012992B4 (de) Verfahren und System zum Bereitstellen von Medieninhalten für eine Mehrzahl von Knoten in einem Datennetz
DE60306084T2 (de) Verfahren zur Rundsendung von Inhalten eines Peer-to-Peer Netzes
DE60131900T2 (de) Verfahren und system zur verwaltung von verteilten inhalten und verwandten metadaten
DE69832247T2 (de) Auf einem verteilten Internet- Protokollen basierte Echtzeit- Multimedia- Datenströmungs- Architektur
DE602006000171T2 (de) Verfahren zum Zuordnen einer Priorität zu einer Datenübertragung in einem Netzwerk und Netzwerksknoten, der das Verfahren verwendet
DE602005000984T2 (de) Verfahren und Vorrichtung zur Speicherung von Eingangs-Filterkriterien und zur Spezifizierung von Triggerpunkt-Vorlagen zum Zeitpunkt der Diensteimplementierung
DE60036021T2 (de) System zur Verteilung von Daten innerhalb eines Internetzwerkes mit zweitseitiger Vereinbarung über Inhalt
DE60111072T2 (de) Verfahren und vorrichtung zur parallelen nachrichtenübermittlung in echtzeit von dateisegmentierten
DE602005001815T2 (de) Verfahren zur effizienten Mehrfachverbreitung von Inhalten in einem Peer-to-peer Netzwerk
DE60122691T2 (de) Verfahren und vorrichtung zum verteilten cachen
DE60319758T2 (de) Verfahren und Vorrichtung für das Wechseln des Proxies für Medienströme während der Übertragung von zwischenspeicherbaren Inhalten zu mobilen Knoten in einem paketvermittelnden Netzwerk
DE60204031T2 (de) Hierarchische cachespeicherung in telekommunikationsnetzen
JP2011502412A (ja) 管理型マルチメディア配信ネットワーク内の回復力の高いサービス品質
WO2004015952A2 (de) Vorrichtung zum kopiergeschützten verteilen elektronischer dokumente
DE112011103642T5 (de) Verfahren zum Senden/Empfangen von Medieninhalt und Vorrichtung zum Senden/Empfangen, die dieses verwendet
DE602004009176T2 (de) Dienstverwaltung durch verwendung mehrerer dienstort-manager
WO2008098853A1 (de) Verfahren und vorrichtung zum verteilen eines datensegments eines datenstroms an eine gruppe von mehreren nutzern
DE60214399T2 (de) Endgeräte, die so ausgelegt sind, dass sie als relaisserver zum verteilen von paketen in einem client-server-netzwerk wirken
DE10004829B4 (de) Verfahren und Vorrichtung zum Übertragen von Dateneinheiten eines Datenstroms
CN105900437A (zh) 通信设备、通信数据生成方法和通信数据处理方法
DE60205393T2 (de) Verfahren und vorrichtung zum empfang von rundsendedaten
EP2454863A1 (de) Steuerung der datenrate eines medien-downloads anhand von client-wiedergabestatusinformation
EP0913974A1 (de) Verfahren zur Erstellung von Sendeplänen für Multi Media Daten
DE102007006432B4 (de) Vorrichtung und Verfahren zur Bereitstellung von Daten
EP3585059B1 (de) Übertragung von echtzeitdatenpaketen von sendungen aus dem internet

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10712718

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13256310

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 10712718

Country of ref document: EP

Kind code of ref document: A2