diff options
author | Chocobozzz <florian.bigard@gmail.com> | 2016-07-22 11:53:55 +0200 |
---|---|---|
committer | Chocobozzz <florian.bigard@gmail.com> | 2016-07-22 11:53:55 +0200 |
commit | f018f38e0dbb58d829a2ca33b38449056e451502 (patch) | |
tree | 2cab83ada7126f064015b9f605b381ad443df56b /ARCHITECTURE.md | |
parent | 6dde6a31e3dfb0298e3f7171b2f8ad9bab1f2370 (diff) | |
download | PeerTube-f018f38e0dbb58d829a2ca33b38449056e451502.tar.gz PeerTube-f018f38e0dbb58d829a2ca33b38449056e451502.tar.zst PeerTube-f018f38e0dbb58d829a2ca33b38449056e451502.zip |
Typos
Diffstat (limited to 'ARCHITECTURE.md')
-rw-r--r-- | ARCHITECTURE.md | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md index 65dd5b49d..1454f9427 100644 --- a/ARCHITECTURE.md +++ b/ARCHITECTURE.md | |||
@@ -42,9 +42,9 @@ | |||
42 | * All the requests are retried if they failed | 42 | * All the requests are retried if they failed |
43 | * The requests are made at regular intervals to all pods of the network with a limit of parallel requests: if there are 1000 pods in the networks, the server won't make more than 10 requests in parallel | 43 | * The requests are made at regular intervals to all pods of the network with a limit of parallel requests: if there are 1000 pods in the networks, the server won't make more than 10 requests in parallel |
44 | * If there are no informations to send (no video addition/removal), no requests are made | 44 | * If there are no informations to send (no video addition/removal), no requests are made |
45 | * The requests are grouped: for example if the interval is 1 hour and an user upload 2 videos there will be only 1 request that contains the 2 videos informations | 45 | * The requests are grouped: for example if the interval is 1 hour and a user$ upload 2 videos there will be only 1 request that contains the 2 videos informations |
46 | * The requests in the group are ordered: if an user add a video and remove it, we need to transmit these informations to the other pods in the same order | 46 | * The requests in the group are ordered: if a user add a video and remove it, we need to transmit these informations to the other pods in the same order |
47 | * The requests are grouped with a limit: if an user uploads 100 videos at a time, the information could be propagated in a few hours to do not make too big requests | 47 | * The requests are grouped with a limit: if a user uploads 100 videos at a time, the information could be propagated in a few hours to do not make too big requests |
48 | * If a grouped request fails the score is decreased by x points | 48 | * If a grouped request fails the score is decreased by x points |
49 | * If a grouped request is a success the score is increased by x points | 49 | * If a grouped request is a success the score is increased by x points |
50 | * The maximum of points would be defined | 50 | * The maximum of points would be defined |
@@ -56,8 +56,8 @@ | |||
56 | * A pod has different user accounts that can upload videos | 56 | * A pod has different user accounts that can upload videos |
57 | * All pods have an index of all videos of the network (name, origin pod url, small description, uploader username, magnet Uri, thumbnail name, created date and the thumbnail file). For example, a test with 1000000 videos with alphanum characters and the following lengths: name = 50, author = 50, url = 25, description = 250, magnerUri = 200, thumbnail name = 50 has a mongodb size of ~ 4GB. To this, we add 1 000 000 thumbnails of 5-15 KB so 15GB maximum | 57 | * All pods have an index of all videos of the network (name, origin pod url, small description, uploader username, magnet Uri, thumbnail name, created date and the thumbnail file). For example, a test with 1000000 videos with alphanum characters and the following lengths: name = 50, author = 50, url = 25, description = 250, magnerUri = 200, thumbnail name = 50 has a mongodb size of ~ 4GB. To this, we add 1 000 000 thumbnails of 5-15 KB so 15GB maximum |
58 | * After having uploaded a video, the server seeds it, adds the meta data in its database and makes a secure request to all of its friends | 58 | * After having uploaded a video, the server seeds it, adds the meta data in its database and makes a secure request to all of its friends |
59 | * If an user wants to watch a video, he asks its pod the magnetUri and the frontend adds the torrent (with WebTorrent), creates the HTML5 video tag and streams the file into it | 59 | * If a user wants to watch a video, he asks its pod the magnetUri and the frontend adds the torrent (with WebTorrent), creates the HTML5 video tag and streams the file into it |
60 | * An user watching a video seeds it too (bittorent) so another user who is watching the same video can get the data from the origin server and the user 1 (etc) | 60 | * A user watching a video seeds it too (bittorent) so another user who is watching the same video can get the data from the origin server and the user 1 (etc) |
61 | 61 | ||
62 | ## Ideas | 62 | ## Ideas |
63 | 63 | ||