Content Delivery
Infrastructures for Live Streaming Progress Report
held
at the TF-VVC Face 2 Face meeting of November 8 2005, Utrecht
Outline
OpenCDN
is an application-level
Content
Delivery Network for
replication and splitting of live multimedia content
and distributed caching of VoD, by deployment of a
Streaming Relay Overlay
Network. It has grown as an
OpenSource project, and can be adapted to any kind of streaming
technology. Free participation can be in the form of development and
testing, set up of remote replication nodes, and contribution of live
feeds.
Goals
When
and if the OpenCDN project will be widely endorsed, netcasting to large
audiences will become as easy as meeting friends at pub. No ubiquitous
multicast routing will be necessary, and TV will become
obsolete.
Artistic
and cultural events will reach broader audiences, students
will attend to courses from home, videoconferences will become
Internet
talk-shows.
Architecture
OpenCDN is made of the following
entities:
- a Request Routing and
Distribution Manager (RRDM)
performing a centralized control
- an Announcement Portal
where viewers find the contents list and the best surrogate address
- some replication Nodes
- some content Origins
Features
- New replication nodes and contributing sources may be
independently added, without the need of inter-administrator
coordination
- Resilience to network partitions, node failures, and RRDM
reboot
- Clients can interact without the need of special features or
multicast: their browser and the player for the requested content are
enough
- different streaming technologies (Real, QuickTime, WM) can co-exit
- distribution root is located near the encoder
- the edge server is located near the requesting client
This year achievements
- adaptation to the Helix server by Real
- WM delivery through Helix
- authentication infrastructure
- edge surrogate <-> client RTSP autentication
- UDP probes optimization
- use of single-thread asyncronous I/O instead of the forking of
many sub-processes
- a convercence layer allows for
co-existence of different
streaming technologies within the same host
- presence of Origin entities allow
- independent registration of the available contents metadata
- determination of the FirstHop Node which is nearest to the
Origin
- if a LastHop node is in the same LAN of the Origin, it is
promoted to FirstHop for clients in
the same LAN
Almost ready
- Localization of the LastHop node which is nearest to the client
- it was proposed by Cineca and there called
PYTE
- the same problem was tackled as a static configuration (footprint) whose feasibility is
questionable
- now the solution will be based on an objective latency measure
- global LastHop nodes
can now be deployed
Things to do (maybe?)
- many refinements
- a better announcement portal layout
- embedding of the viewer
- configuration GUI
- graphic sketch of the resulting topology
- a simple interface for VLC-based content providers
- an adaptation layer for Windows Media Server
- documentation (now in the form of sparse README files, should be unified)
- aging of state information
- policy for a public use by (independent) content providers and
supporting nodes
- a network topology aware deployment of the distribution tree
Future (?)
Development without field trials is
almost non-sensic. There can be an egg and chicken problem (no contents
without the network, no network without contents), but also pretending
that everything works by itself is exaggerate. As an open source
project, space exists for contributions in many aspects. For instance,
Helix fine-tuning work came mainly by an independent contributor.
Alessandro
Falaschi - November 8, 2005
