Handling Multimedia Objects in Peer-to-Peer Networks

Video-on-demand systems and services [4, 2] are predominantly offered over dedicated private networks with the help of large servers [3, 13]. Such systems are restricted by the number of concurrent accesses allowed as well as load balancing issues that ensue when the demand for video objects is skewed [1, 13]. The widespread usage of broadband networks in connection with the low-cost commodity hardware may offer alternative avenues for the delivery of video streams and other multimedia objects. This goal can be achieved with the help of multiple, independent, and inexpensive computing nodes that function using a peer-to-peer P2P protocol [9, 8, 7]. P2P services have so far concentrated in the exchange/sharing of “small” objects including mp3, images, and audio files as well as CPU cycles and memory space [5, 11]. Discovery of objects solely based on the existing message-based schemes may prove rather ineffective [10]. Centralized indexing methods used in early P2P systems are very restrictive [12]. As groups of sites tend to form sizable node clusters [10], the large total number of dispatched messages makes inefficient use of computing resources. It is our position that furnishing video services on a P2P network not only can offer viable alternatives to the mostly proprietary architectures used today for the delivery of video services, but also it can be done in a reliable and scalable manner. We build upon the approach of ad-hoc P2P networks of resources and propose a new architecture that can support storage and retrieval of movies and/or video-clips. Our proposed configuration exploits the availability of high-performance links to networks, the usage of exclusive and partial indexing in peers, making nodes “aware” of the content in their own vicinity, replication of objects and caching of popular items, as well as full connectivity among servers whenever feasible. The architecture uses efficient indexing mechanisms for the retrieval of the multimedia objects, guarantees continuous operation in light of server failures and allows for the transparent population of new servers as well as the evolution of the furnished services and/or network resources with minimal disruption to the users. One key provision to realize such a P2P infrastructure is that the core peers (or servers) are expected to be linked via a low-latency and high-bandwidth network capable of effective handling and delivery of voluminous multimedia data. It is also anticipated that end-users should have sufficient connections to object servers. For acceptable quality MPEG-compressed video streams, one would approximately need 30 frames/sec and around 1.5Mbit/sec network connection to the source. This is well within reach as more individuals are connected through specialized modems (cable, DSL, etc.) or T1-level network connections [14, 6]. The system consists of a number of servers that constitute the basis for managing the storage and retrieval of video objects. Each peer functions as an indexing site as it features local access structures that help identify and retrieve objects of interest. Servers also maintain partial indexes for the video and/or clips held by sibling nodes. Fig. 1 depicts this architecture term Multiple Independent Indexing Servers (MIIS). Peers have a maximum capacity for video objects and each stored object maintains frequency accesses and timestamps for the last time it was accessed. End-users initiate multimedia object requests by using the payload of query messages. When a server receives a request, it searches through its local repository. If the object is found locally, it is presented to the requesting site (through a query reply message). Otherwise, the server uses its partial index to check if the objects are stored in a sibling (peer). There are two options: 1) First Cache–Then Deliver: The item is first cached to the server that the requesting site is attached to and then it is distributed. The condition that enables such a copy is that an object has become popular (object has received k% of the most recent requests). User sites ultimately receive objects from their own respected serving peers. 2) Forward Object: The data server managing the item streams the object via the network directly to