Description of multicast distribution system of large content.
Author: Aleksey Lukin, Chernigiv, Ukraine.
(C) 2003-2008. All rights reserved.
Published at http://alukin@stu.cn.ua/contentrush/
Any use of ideas and algorithms from this article prohibited without authos written permition.
Patent pending.
1. General notes.
Multicast distribution of large content allows to reduce sattelite channels load and cost of
content delivering. On the other hand, multicast distribution system has following fetures
because of immanent technology drawbacks.
1. Content is broadcatsed in one way cast and must be encoded with Forward Error
Correction (FEC) codecs to ensure data integrity.
That anlarges data size by 1.3-1.5 factor.
2. Content is distributed syncronously to large auditorium of customers, therefore
receiver client must be informed of session start time, duration and must warn user
if he wants disconnect network interface, turn off comuter or interrupt session any
other way.
3. Content must be distributed by relatively small chunks to allow user's receiver
get missed chunks by unicast channel.
4. Distribution server must keep cache of sent content to allow user get missing chunks.
5. Distribution server and user client program must share some encription key to code
content with to avoid unauthorized content receiving and phishing. Obviosly, content
must be encripted before FEC coding.
6. Distribution server must send session annoncements to clients by wide range of
sommunication services like e-mail, SMS and so on to allow users prepare for
sessions.
7. Content distribution system must have some engaging and promotion mechanisms to
attract users.
8. Cost of received content must be significantly lower compared to traditional
9. All equipment on the server side must support full-featured IP multicast.
This includes but not limited to switches, network cards, routers.
10. Client of this service may be not a registered customer of sattelite service,
anyone who have working equipment and knows session keys may participate in the
session.
Comments to 9: Author tried to run multicast session on provider's backbone with speed of
2 Mbit/s and this session caused large failure of proxy servers, shapers and other networked
devices. The caues of failure was Intel Pro 100 network card that does not support multicast
by hardware and goes in promiscous mode to select multicast packets by software driver.
This mode of operation is extremal resource hog and causes DoS.
To avois such innaceptable situation techical staff must check equipment before any multicast
sessions.
2. Notes about pricing and user attraction.
To get maximum ammount of revenu, considerable end user prices and effective user attraction
policy author proposed some kind of light gambling called "Content rush".
Let's see an examle of session creation and pricing to get idea of "Content rush".
First user initiates session by choosing or downloading content to server and writes
comprehensive session description. Server planes session time and channels and announces
it to users' group of interest. Some number of users, let's say 1000, joining session.
Content price for unicast download is $100 so first user will get it anyway for this
price even if no one joins to session. So he does not risk much. If there are 2 users,
first pays $50, second pays $55 and owner of resource have $5 of revenu. For 10 users we have
following array of prices:
1.0 6.5 9.75 11.875 13.55 15.0 16.0 17.0 18.0 19.0 Owner rev=27.675
For 50 users:
-14.2 -5.9 -1.65 0.58 1.99 3.0 3.2 3.4 3.6 3.8 .... 3.8 3.8 Rev=49.81
For 100 users:
-16.1 -7.45 -3.075 -0.84 0.55 1.5 1.6 1.7 1.8 1.9 1.9 1.9 ... 1.9 Rev=52.58
For 1000 users:
-177.01 -88.01 -43.51 -21.26 -7.91 0.99 0.99 0.99 0.99 ... Rev=547.35
Minus sign means that first 5 users winning some ammount of money depending on
number of users that joined session.
This is more or less ballanced formulae copyrighted by author.
Cheaper content gives more bonuses for users and revenu for content distributor.
As can be seen, last joined user pays a bit more until price reaces minimal price
value.
3. Notes on technical implementation.
3.1 Server must implement following modules with described functionality:
3.1.1 User management module: user registration, users categories of interest,
user preferences.
3.1.2 Billing module: Interface to some web-money system or other payment system,
money charging and payment, price calculator.
3.1.3 File cache management module:
File slicing, ecnryption and encoding, caching, removing, aging, etc.
Cache search engine.
3.1.4 Session management module: Session and channel planing, sending of content
chunks.
3.1.5 User advertizing module: Session advertizing for user client software, session
descriptors and keys distribution to subscribed users., subscription management.
3.1.6 User interface: Session creation and joining, content downloading and choosing.
3.2.7 Administrator interface: System control and management.
3.2.8 Content control module: Uploading of copyrighted content, price control, content
advertizing.
3.2.9 Service module: Systen authomatic sanity checks for cache, users, session, payments and other
background tasks.
3.2.10. Sender module that takes chunks, encodes and sends as multicast packets.
3.2 User workstaion client must implement following modules with described functionality:
3.2.1 User GUI module: Session advertizment display, session subscription, session integrity
check, missing chunk downloading, user warnings about poweroff or network failures,
control of service module.
3.2.2 Service module: module that runs constantly as OS service or daemon and do real tasks
that GUI displays and controls.
3.2.3 Receiver module is celf-contained receiver that receives multicast packets, decoses
and decrypts them and places received chunk to serveice module spool.
4. Conclusion.
This service may be very cost effective even on small user base but needs certain development
efforts in ammount of appr. 12 month/person. Several modules can be developed in parallel and
estimated time is 4 month for 3 highly skilled developers and 1 month for tester from service
support team.