docs/paper/src/implementation.tex

   1 One of the basic design principles of our platform was to publish it as open-source encouraging community contributions. To facilitate this we have chosen popular programming languages, frameworks and technologies in order to better attract open-source communities around our platform. These decisions along with implementation details are given in this section. Information found here accompanied by comments from the source code should hopefully provide enough information to a new contributor to this project.
   2
   3 Our implementation was designed to work on \textbf{GNU/Linux} distributions, so our back end dependencies, such as FFmpeg, has been chosen based on this. However we tried as much as possible to choose them such that they also run on other operating systems, such as Windows. Thus, porting P2P-Tube for them should be easy, but until this point creating a cross-platform implementation was not a priority for us.
   4
   5 \subsection{Web Application Front End}
   6 \label{subsec:front-end}
   7
   8 The front end of P2P-Tube provides an interface with the users of the platform. Today more and more applications are migrating from a classical desktop interface to a web interface. For instance, applications like Microsoft Office started to appear on the cloud, providing a web interface; one popular example is Google Docs. Besides this new trend, Next-Share content delivery platform was successfully implemented in browsers by P2P-Next. So implementing P2P-Tube as a web platform came as a natural choice.
   9
  10 Because almost any hosting provider offers a standard LAMP stack, we decided to cope with such a configuration. LAMP stands for Linux, Apache, MySQL, PHP, the technologies which is based on. We tested P2P-Tube on Apache web server, but it should work well on others.
  11
  12 P2P-Tube server side application is implemented in \textbf{PHP} which is one of the most popular programming languages for this purpose. To facilitate development we decided to use \textbf{CodeIgniter} \cite{code-igniter} open-source framework. Thanks to this framework the platform uses a \textit{MVC (Model-View-Controller)} design pattern, which separates the user interface part (View), from the data stored (Model) under the rule of the Controller.
  13
  14 Our implementation uses a \textbf{MySQL} database, but CodeIgniter abstracts the interface with the database, so porting our platform for a different SQL technology such as PostgreSQL should be easy.
  15
  16 As a web application, on the client side P2P-Tube uses HTML, CSS and JavaScript. As stated before SwarmPlayer only works with browsers that support HTML5. We decided to use jQuery \cite{jquery} as a JavaScript framework to ease development on the client side programming. We developed a jQueryUI \cite{jqueryui} widget which is used to control video playing with features like play, pause and stop buttons, time progress slider, volume control etc.. This widget is detailed in Subsection \ref{subsec:video-widget}.
  17
  18 The web application currently uses two models. \textbf{\texttt{videos} model} is an interface to the database for accessing information about video assets. \texttt{videos} table contains on each row data about a video asset. \texttt{videos_comments} stores each video comment created by an user on a row. Both videos and comments can be voted with like or dislike. Methods for returning detailed information about a video, for returning \textit{video summaries} and for searching in the videos set are implemented here. Video summaries are lists of video assets, with brief information about each one. For instance, \texttt{get_videos_summary} method can create a list of videos from a specific category, uploaded by a specific user, within a defined range described as offset and count and ordered in a specific way. Methods for adding and retrieving comments for voting or for incrementing the number of views for a video are also available here.
  19
  20 \textbf{\texttt{users} model} is an interface to the database for accessing information about users. \texttt{users} table stores on each row data about a registered user, including its user name, its password SHA1 hash, its e-mail and profile information such as gender, country, city, birth date etc.. Authentication information, authentication method (internal, with LDAP or with OpenID) and user preferences are also stored in this table. When signing in with OpenID, \texttt{users} table is joined with \texttt{users_openid} table which maps OpenID URLs with rows from \texttt{users} table. After registration, new users have to confirm their e-mail address by providing an activation code received on that address. Unactivated users with their activation codes are stored in \texttt{users_unactivated}. User activity is logged in \texttt{users_actions} table. This kind of information can be used to ensure that an user votes a comment or a video only one time during a day, but user history can also be tracked here.
  21
  22 \texttt{users} model methods can be used to check authentication credentials, to register new users, to activate accounts, to send password recovery e-mails and to modify user data. Column \texttt{auth_src} from \texttt{users} table identifies the authentication method used by the user. If internal authentication is used the password entered by the user is hashed with SHA1 and checked against the hash from \texttt{password} column. For LDAP authentication this field is NULL, because \texttt{users} model connects to an LDAP server for logging in. For authentication through OpenID, \texttt{users} model uses a third-party library developed by JanRain Inc. \cite{janrain-openid} which implements OpenID protocol.
  23
  24 Pages are organized around a few controller classes. \textbf{\texttt{catalog} controller} manages web pages that help users explore video assets. \textbf{Index page} shows the five most \textit{hottest} video assets from each category which are the newest and the most appreciated ones. The appreciation score is calculated as the number of views plus the number of likes minus the number of dislikes, so a video with a greater appreciation score is more appreciated. \textbf{Category page} permits users to explore video assets by category. Videos can be ordered alphabetically, by upload date or by showing the hottest first.
  25
  26 \textbf{\texttt{video} controller} manages the \textbf{watch page} were users can play a video asset with one of the two Next-Share plugins and the video widget presented in Subsection \ref{subsec:video-widget}. Commenting and voting mechanisms are also implemented into this controller through AJAX, such that when using this facilities the web page is not refreshed interrupting video playing.
  27
  28 \textbf{\texttt{user} controller} is used for user management. \textbf{\texttt{login} method} controls a web page which permits users to sign in with their user name and password or by providing an OpenID. Tree buttons for Yahoo!, Google and myOpenID ease authentication through OpenID with this services. \texttt{login} method checks authentication credentials by using \texttt{users} model and sets a new session in a cookie if authentication succeeded. To delete the session and sign out, \texttt{logout} method is used. \textbf{Registration} and account activation pages are managed by the same controller and logged in users can access \textbf{account page} to change account and profile information or to change their password. To verify that a real person applied for an account, a CAPTCHA is provided on the registration page. Users can see each other's profile through the \textbf{profile page} where one can also see what videos that user uploaded.
  29
  30 The platform provides a way to load static HTML as page content through \textbf{\texttt{article} controller}. The HTML is loaded from \textit{``application/views/article/$<$language$>$/$<$article_name$>$.php''} when URL \textit{``article/$<$article_name$>$''} is accessed. \textit{$<$language$>$} is the name of the current language set in \textit{``application/config/config.php''}. CodeIgniter's URI routing feature can be used in order to have a different URL for an article. In the default configuration of the P2P-Tube site there are four articles used: \textit{Install Plugins}, \textit{About}, \textit{Help} and \textit{Contact}. All of them use URI Routing in order to have a friendlier address.
  31
  32 CodeIgniter supports running its script from the command line. \textbf{\texttt{admin_cli} controller} implements a few methods that can be used by system administrators exclusively from the command line. Database cleanup methods are currently implemented here, which can be conveniently called as cron jobs.
  33
  34 Some parts of a web page are common to more than one page. This include headers, menus, footers, side parts with optional information etc.. All these components are implemented as \textbf{views} and are loaded within the controller of each page. \textbf{\texttt{header} view} renders the top of a web page and includes a menu, a logo, information about the logged in user if required and a search box that help users search video assets, described in Subsection \ref{subsec:searching}. \textbf{\texttt{footer} view} renders the bottom of a web page and typically contains copyright information or links. Common HTML tags like those found into head tag can be easily loaded by using views \textbf{\texttt{html_begin}} and \textbf{\texttt{html_end}}. View \texttt{html_begin} is used with \textbf{\texttt{Html_head_params} library} to load CSS files, JavaScript files, set the page title and add meta data.
  35
  36 \subsection{Searching Video Assets}
  37 \label{subsec:searching}
  38
  39 \subsection{Video Widget}
  40 \label{subsec:video-widget}
  41
  42 TODO
  43
  44 \subsection{Content Ingestion Back End}
  45 \label{subsec:back-end}
  46
  47 TODO
  48
  49 \subsection{Front End and Back End Communication}
  50 \label{subsec:communication}
  51
  52 The web server needs to communicate with Content Ingestion Server, whether or not through a CIS Load Balancer (CIS-LB), by sending a content ingestion request. By using a web service for this communication the implementation overhead is reduced. Sending HTTP requests from the PHP web server application is much more easy then creating a custom new protocol. The same applies at the other communication point, the Python server, where requests are received by Web.py framework, which makes HTTP methods processing extremely easy.
  53
  54 If another framework decides to use our solution based on CIS machines, interoperability is simplified by using web service interfaces, no matter what programming language is used for web server application.
  55
  56 \subsection{Programming Languages, Frameworks}
  57 \label{subsec:langs-and-frameworks}
  58
  59 Content Ingestion Server is written in Python, mainly because of the need of using threads. A master thread takes the role of a producer by receiving requests from clients and submitting them to a job queue. The consumer is a worker thread which gets jobs from the queue and executes them, using a first-come first-server servicing policy. If the queue is empty the worker waits without blocking until a new job is available. Client requests are received by the master with the aid of Web.py, a lightweight web framework \cite{webpy}.
  60
  61 \subsection{The Choice for the Web Service}
  62 \label{subsec:securing-cis}
  63
  64 Our choice between a SOAP web service and a simple RESTful web service was based on our needs. We wanted to make a server with a low communication overhead and SOAP has the disadvantage of consuming more computational resources when processing requests. Our messages that need to be passed through different services have a simple structure.
  65
  66 The \textit{get load request} does not have any parameters, so a simple HTTP GET request is sufficient and any extra data transmitted as XML with SOAP is redundant.
  67
  68 \textit{Content ingestion request} is a message with a greater complexity. The name of the uploaded file located on the web server needs to be transmitted, along with video formats information such as containers, codecs used, resolutions, frame rates, aspect ratios, audio sampling rates and bit rates. All these information would fit well as parameters in a SOAP message. However encoding then in a JSON seemed to be a much simpler solution. Both PHP and Python offer functions that convert their primitive types and data structures, like lists and dictionaries, into JSON strings. XML messages have a greater verbosity comparing to JSON messages. Features like XML tag attributes are not required for our application.
  69
  70 We expect web servers and their CIS Load Balancers to know CIS peers in advance. So there is no need for discovery services that could provide contact information for new CIS peers. This would reduce administrative control and would raise security concerns like discovering malicious CIS peers. So there is no need for service discovery features like UDDI from SOAP ecosystem.
  71
  72 Services functionality does not need to be described because it is expected to be known in advance by the client application, so SOAP's WSDL feature is not needed.
  73
  74 The simplicity of our web services and our need for a low communication footprint suggest us to use a RESTful web service with JSON encoded information when the POST method is needed. SOAP extra features like WSDL and UDDI are not required for our application, giving us another reason to exclude it as a candidate.
  75
  76 \subsection{Securing Content Ingestion Server}
  77 \label{subsec:securing-cis}
  78
  79 As pointed in the previous section, we require a low communication overhead. In Section \ref{subsec:ws-sec-perf} we have shown that WS-Security needs more processing time for message parsing. But is this worth it?
  80
  81 WS-Security offers end-to-end security, but P2P-Tube web servers and CIS peers are designed to be tightly coupled, usually being in the same data center or under the authority of the same organization. All these components communicate directly without proxies. So a simple point-to-point communication over HTTPS could be enough for our application.
  82
  83 The additional overhead of WS-Security against TLS/SSL solution is a price to pay for the advantage of an end-to-end communication. However, our solution is not designed to use proxies. So HTTPS with TLS or SSL is enough for our application and is much more easy to implement. Usually any library that supports HTTP also supports HTTPS. On the server side two additional informations need to be passed: server's certificate and its private key.
  84
  85 Because CIS communication with a CIS-LB or with a web server can be encrypted, authentication information can be added into messages when using the HTTP POST methods. CIS requires an user name and a password for content ingestion requests.
  86
  87 If CIS, CIS-LB and web server peers are located in the same data center which is secured and isolated from the exterior, secure communication between them might not be required. Taking into account the fact that HTTPS doubles communication overhead, the system administrator must think twice before securing services' communication.
  88
  89 File transfer between web server and CIS is made through a pluggable interface. Other protocols like FTP \cite{ftp}, scp \cite{scp} and rsync \cite{rsync} can be used. We currently implemented an FTP interface, where the control channel is encrypted using TLS. Data channel does not require encryption if the files are not secret. Securing this channel would substantially increase resource usage. We are planning to implement a rsync file transfer interface too. This protocol is secured by default because is built over SSH. It also has the advantage of reducing the amount of data sent over the network by transferring only the differences between files.
  90