In the end of the content ingestion process all other Content Ingestion Servers from the system must be aware of the new torrent files in order to seed them. First of all, the new torrent files need to be locally accessible to them, so all torrent files can be shared by CIS machines on a \textit{distributed file system} such as NFS, LustreFS or GlusterFS. The overhead of using shared storage between CIS machines shouldn't affect performance, even if NFS is used, which serves files through a single machine. This is because torrent files are very small so concurrently accessing more files on the shared file system can affect performance in a negligible manner.
-When the web server is notified about the job completion (10) a seed request must arrive to each CIS so that they can start seeding the new torrent files available in the distributed file system. This request is originated from the web server and there is no need to do this on a single CIS system, because this is already done in step 8 from Figure \ref{fig:content-ingestion}, so the web server can be configured to skip this redundant step from its configuration. In a multiple CIS system this step is mandatory for ensuring high availability of the new video assets. Thus, a \textbf{seed request} is sent from web server to CIS-LB, which forwards this message to all CIS from its jurisdiction. Upon reception they will start seeding requested torrent files which are located in the distributed file system.
\ No newline at end of file
+When the web server is notified about the job completion (10) a seed request must arrive to each CIS so that they can start seeding the new torrent files available in the distributed file system. This request is originated from the web server and there is no need to do this on a single CIS system, because this is already done in step 8 from Figure \ref{fig:content-ingestion}, so the web server can be configured to skip this redundant step from its configuration. In a multiple CIS system this step is mandatory for ensuring high availability of the new video assets. Thus, a \textbf{seed request} is sent from web server to CIS-LB, which forwards this message to all CIS from its jurisdiction. Upon reception they will start seeding requested torrent files which are located in the distributed file system.
+
+There may be situations when a seed request is lost by a CIS. For instance, a CIS is temporarily down or it has a temporary network failure and does not receive a seed request from CIS-LB. After recovery it will not know about the existence of new torrent files. This can lead to availability problems, so to solve this a CIS periodically scans the torrent directory for new torrent files.
+
+When a CIS daemon starts running it begins seeding all torrent files from the distributed file system.
\ No newline at end of file
-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 with comments from the source code should hopefully provide enough information to a new contributor to this project.
+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.
-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.
+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.
\subsection{Web Application Front End}
\label{subsec:front-end}
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.
-Because almost any hosting provider offers a standard LAMP stack, we decided to cope we such a configuration. LAMP stands for Linux, Apache, MySQL, PHP, the technologies which is based on. We tested P2P-Tube on an Apache web server, but it should work well on others.
+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.
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.
-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.
+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.
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}.
+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.
+
+\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.
+
+\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.
+
+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.
+
+\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.
+
+\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.
+
+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.
+
+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.
+
+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.
+
+\subsection{Searching Video Assets}
+\label{subsec:searching}
+
\subsection{Video Widget}
\label{subsec:video-widget}
projects / living-lab-site.git / commitdiff