La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => 
K-Net => Opérateurs grand public alternatifs => Offre TV K-Net => Discussion démarrée par: jack le 17 février 2016 à 14:31:43
-
Des infos en vrac sur le serveur "OTT" utilisé par Knet !
Je ne donne pas de photo de l'intérieur, le serveur que j'ai sous la main est plutôt vide ..
En revanche, je peux parler de celui qui est actuellement en production
* Matériel utilisé:
- le chassis est un supermicro 6017R-WRF (http://www.supermicro.com/products/system/1u/6017/sys-6017r-wrf.cfm)
- un CPU E5-2620 (12 core, dont 6 physiques)
- 32GB de ram DDR3
- une carte PCI 4*SFP+, à base de broadcom (http://www.supermicro.com/products/accessories/addon/AOC-STG-b4S.cfm)
- des vieux disques dur qui trainent ..
Outre les ports SFP+, le serveur est branché sur un port Gb, utilisé pour le management et l'upstream.
* Logiciel
Niveau réseau, les 4 ports sont montés en LACP, sans vlan (pvid côté switch).
Comme l'upstream utilise le port Gb 'stock', la machine dispose vraiment d'une capacité utile de 40Gbps, soit 4000 clients fullHD simultané.
Au niveau routage, le serveur possède une session BGP avec le switch, afin d'annoncer l'IP "magique" de TV, via exabgp : c'est donc de l'anycast qui va me permettre, un jour peut-être, de faire de la haute disponibilité. Dans l'immédiat, cela permet à tout les abonnés de pointer sur le même nom de domaine, sur la même IP, mais sur des serveurs différents.
Au niveau système, l'ensemble des fichiers est stockés en mémoire : cela m'évite de passer par la case "stockage" pour bondir sur la case "IO cache", nécessaire pour fournir les débits requis. L'ensemble des chunks HLS a une taille inférieure à 5GB.
Quant au logiciel, j'utilise varnish .. un simple proxy cache HTTP. Tout est générique, rien n'est spécifique ! L'autre avantage, c'est que cela simule le comportement du multicast, sur des liens "en bout d'arbre" (deauville par exemple): si personne ne regarde une certaine chaine, cette dernière n'est pas ramené de l'upstream vers la machine.
* $$
Histoire de faire un peu de business, le coût de la solution "serveur" est inférieur à 5k€ (incluant la carte et les SFP+/DAC)
En rajoutant 4 ports 10G sur un switch (800€) plus le downstream (*2), on arrive à moins de 2k€ pour le réseau
Donc, pour 7k€, il est possible fournir 4000 clients dans le pire des cas (avec le ratio chaine HD / chaine SD, je planche plutôt sur 10k clients par serveur).
Cela fait donc 0.7€ par client (1.75€ dans le pire des cas), one shot.
-
Joli !
-
Quant au logiciel, j'utilise varnish .. un simple proxy cache HTTP.
Je pense que c'est très utilisé.
Je viens de recevoir un message d'erreur de varnish sur le Replay de Free.
-
Bon en gros le seul truc intéressant c'est le message sur le post-it ;D
-
C'est le mdp?
-
J'ai plusieurs questions pour Jack:
* Est-ce que tu nous confirmes que c'est un serveur uniquement pour du live streaming?
* Si oui, comment procédez-vous pour la partie VOD? L'objectif est également d'avoir des serveurs "répartis" dans les différents POPs?
* Quel est l'intérêt, pour vous, d'une solution OTT par rapport à une solution multicast pour le live?
- permettre aux utilisateurs d'accéder à la TV sur leur PC, leur tablette?
- avoir une solution TV (via box) qui fonctionne bien, y compris sur des réseaux de DSP qui ne proposent pas de Multicast, ou dont le multicast fonctionne mal ?
- avoir une solution unique pour tous les réseaux (DSP) sur lesquelles vous travaillez? Si oui, vous allez abandonner le multicast définitivement?
Leon.
-
Presque toutes les réponses sont dans le post Flux TV: Multicast ou Unicast ? (https://lafibre.info/tv-numerique-hd-3d/flux-tv-multicast-ou-unicast/)
Il me semble que K-Net ambitionne de faire passer tous ses clients en unicast, mais il faut pour cela upgrader les lien de collecte des DSP.
Je vois que le lien vers le SIEA est passé à 20 Gb/s, cela va permettre de mettre plus de clients de l'Ain en unicast, sous réserve que le SIEA n'ai pas de pb pour transporter les flux.
"permettre aux utilisateurs d'accéder à la TV sur leur PC, leur tablette?" C'est déja possible avec les flux Multicast, K-Net étais le seul FAI à mettre un logiciel dans sa box qui transforme les flux multicast en unicast (chez le client) pour pouvoir passer sur du WiFi (et donc regarder la TV sur tablette / téléphone avec les mêmes flux que la TV)
L’avantage principal de l'unicast, outre le fait qu'il fonctionne sur des réseaux où le multicast n'est pas possible, c'est la correction des paquets perdus et ne plus avoir de coupures liés a des pb d'implèmentation du protocole IGMP.
IGMP n'est pas suffisamment strict dans sa norme pour que deux équipements qui respectent la norme génèrent des pertes de paquets quand il y a un IGMP General Query suivit immédiatement d'un client qui résilie une flux.
Cela entraîne des problèmes complexes à tester et à reproduire en lab.
Concernant la TV, le fait d'être obligé de changer de chaîne pour que l'image revienne, cela semble visiblement un problème IGMP.
Je vais donner quelques conseils à Wibox, ayant déjà travaillé sur cette problématique.
4 éléments peuvent à l'origine de ce problème : La Set Top Box, la Wibox, le switch du SIEA qui possède les fonctions IGMP proxy, le routeur qui diffuse les flux ou une incompatibilité entre plusieurs de ces équipements.
Des problèmes d'interopérabilité peuvent survenir si une partie des équipements fonctionnent en IGMP snooping v2 et d'autres en IGMP snooping v3. Certaines box font des requêtes en v2 et en cas de non réponse passent ensuite en v3, bref il est préférable du forcer le même protocole partout (généralement IGMP v2)
Pour avancer, il faut des captures Wireshark. Je déconseille de mettre un switch avec port miroring, mon expérience que ces équipements actifs peuvent interférer sur les requêtes IGMP transmises même quand IGMP proxy est désactivé (je pense au matériel linksys / cisco). Je conseille de mettre deux PC linux avec chacun deux interfaces réseau et un pont pour relier les deux interfaces (tutoriel (https://lafibre.info/tutoriels/generer-des-pertes-de-paquets/)).
|---------| |----------| |-------| |----------| |----------------|
| STB |----| PC Linux |----| Wibox |----| PC Linux |----| CPE RESO-LIAin |----Fibre
|---------| |----------| |-------| |----------| |----------------|
Il faut vérifier la liste des paquets IGMP reçus et envoyés avant la coupure.
L'idéal serais d'avoir des captures Wireshark plus en amont, sur le réseau du SIEA.
Il faut voir en cas de coupure de flux où à été coupé le flux : C'est le switch du SIEA qui a arrété d'envoyer le flux à la Wibox ou c'est la Wibox qui a arrété d'envoer le flux vers la STB alors qu'elle reçoit toujours le flux de son port Wan ?
Toutes les deux minutes le switch de RESO-LIAin et la Wibox envoi un "IGMP General Query" afin que chaque équipement lui donne la liste des flux auquel il s'est abonné. Un "Query Response Interval" est alors positionné à 10 secondes. Afin de ne pas surcharger le switch, les équipements répondent après un temps d'attente aléatoire qui est entre 0s et 10s. Le switch, lui, va attendre 10 secondes + une petite marge de sécurité avant de couper les flux multicast pour lesquels il n'aura pas reçu de réponse. Il faut donc vérifier si la réponse a été émise juste avant l’expiration du délais, cela pourrait être une cause de coupure de flux.
Le "Query Response Interval" est généralement de 10 secondes pour un "IGMP General Query" mais de 1 seconde pour un "IGMP group-specific Query", envoyé quand un autre port du switch demande de quitter un flux multicast "IGMP Leave IP flux". Il est possible d'avoir des problèmes plus complexe, lié a ces différents timer.
Un exemple de bug difficile a tracer entraînant dans des cas particuliers une coupure de flux pour le client à tord :
- T 0 : La box chez le client est abonné au flux 225.0.0.5 et reçois un "IGMP General Query" avec un délai de réponse de 10 secondes. La box décide de répondre après 9 secondes (c'est un délai aléatoire entre 0 et 10sec).
- T 0 + 1 sec : Le switch de la SIEA à reçu un demande de résiliation du flux 225.0.0.5 (Leave Group message) d'un autre client. Le switch coupe le flux pour ce client et envoi un "IGMP group-specific Query" pour 225.0.0.5. Ce type de demande possède normalement un "Query Response Interval" interval de 1 seconde.
La box chez le premier client reçoit cette demande mais elle à déjà une réponse IGMP qui est en attente d'être envoyée et son mécanisme ne permet pas de répondre à plusieurs requêtes à la fois. (Tout ne sort pas de mon invention, des problèmes de ce type ont déjà existé chez certains opérateurs)
- T 0 + 2 sec : expiration du délai de 1 seconde pour le "IGMP group-specific Query". Le switch considère donc que la box n'est plus d'abonnés à ce flux et coupe le flux 225.0.0.5.
- T 0 + 9 sec : La box répond au "IGMP General Query" avec les 9 secondes d'attente. Le switch s'aperçois que la box est abonné à 225.0.0.5 et lui remet le flux.
Total pour le client : 7 secondes de coupure de flux.
Un P+ / P- permet bien sur d'envoyer une nouvelle demande d'abonnement et donc de retrouver le flux immédiatement.
Ce type de bug devrait ne pas être trop impactant pour le client car il faut plusieurs circonstances pour le re-produire : query general qui coïncide avec une réponse tardive et un autre client qui résilie la même chaîne au début de l'interval de temps. Plus le nombre de client augmente et plus on se met sur une chaîne populaire, plus les demandes de leave sont importantes et plus ce type de bug risque d'arriver si la box ignore les autres requêtes IGMP pendant le temps où la réponse est mise en attente. Je pense donc que ce n'est pas ce bug qui gêne les clients Wibox, c'est plus pour montrer qu'il est possible d'avoir des bug complexes avec IGMP v2 partout.
Concernant les bug liés à l'utilisaiton d'IGMPv2 et v3 sur le même réseau certains fabricants (huawei) ont décidés de forcer le choix d'un protocole. Si on choisit IGMP v2 les requêtes IGMP v3 seront ignorées. Cette modification provoque une coupure complète de flux multicast chez les client IGMPv3 ce qui est en fait préférable à avoir un bug lié a la cohabitaiton v2 et v3 qui est difficilement reproductible en lab.
-
* Est-ce que tu nous confirmes que c'est un serveur uniquement pour du live streaming?
Oui, puisque nous n'avons pas d'offre VOD
* Quel est l'intérêt, pour vous, d'une solution OTT par rapport à une solution multicast pour le live?
- permettre aux utilisateurs d'accéder à la TV sur leur PC, leur tablette?
- avoir une solution TV (via box) qui fonctionne bien, y compris sur des réseaux de DSP qui ne proposent pas de Multicast, ou dont le multicast fonctionne mal ?
- avoir une solution unique pour tous les réseaux (DSP) sur lesquelles vous travaillez? Si oui, vous allez abandonner le multicast définitivement?
Vivien t'a pointé vers un bon lien
En résumé, je préfère de loin payer 1€, une fois, par client, et m'économiser une quantité de travail conséquent (au niveau de la boite), tout en garantissant une qualité de service supérieure.
Cf le prix des solutions permettant d'améliorer la résilience du multicast (tout en étant imparfait, TCP est plus résilient)
Cf le fait que la qos, quand de multiple acteurs sont impliqués, est un peu un rêve utopique ..
Bon en gros le seul truc intéressant c'est le message sur le post-it ;D
Probablement !
L'important, c'est de faire une solution générique: stabilité car largement déployé (x86, linux, http), coût réduit par la production de masse, possibilité d'utilisation hybride avec un autre projet, si nécessaire
-
Intéressant. quelques questions:
une seule machine a base d'un seul Xeon peut vraiment 'cracher' 40Gbps ? si j'ai bien combien l'upstream arrive sur le (les?) port(s) 1Gbs de carte mere et les flux repartent en unicast vers les clients via les 4 ports 10 Gbps tout ca géré par Varnish.
y'a pas un risque d'avoir une seule machine pour 4k clients?
l'upstream c'est du multicast ou du HLS aussi?
Quel délai introduit la solution ?
-
J'arrive à cracher 40Gbps d'udp avec 3 cores
Je n'ai pas fait de tests de charge en TCP .. (requiert 2 machines, et un switch entre deux, tout cela que je n'ai pas en lab)
y'a pas un risque d'avoir une seule machine pour 4k clients?
Tu as deux possibilités:
- soit tu as le double de la capacité requise, et tu fais du failove
- soit tu n'as pas le double de la capacité requise, et tu as un service dégradé en cas de panne
Pour l'instant, c'est le #2, j'espère basculer sur #1
l'upstream c'est du multicast ou du HLS aussi?
Quel délai introduit la solution ?
Upstream en HLS (varnish ne fait pas de HTTP)
Le cache introduit un délai très limité : aucun délai lorsque les données sont en cache, presque aucun délai lorsque le fichier n'est pas en local
En revanche, la transformation multicast vers HLS introduit un délai de +/- 10sec (la taille d'un chunk, en bref)
-
Comment ca se compare a une solution "micro services" a base de 20 (ou moins selon les besoins) petites machines a 2x1Gbps faisant tourner un simple soft comme udpxy (ou gigapxy) ? (avec un load balancer dns ou autre devant et l'upstream en multicast). moins cher ? tco ?
voir juste utiliser udpxy/gigapxy sur ton gros serveur plutot que Varnish ?
-
20 petites machines = une demi-baie, sans compter la perte lié au load-balacing (c'est comme le LACP : 10*10G < 1*100G)
udpxy fait, si je me souviens bien, du HTTP "stream", alors que je fais du HTTP "fichier"
Avec du "stream", pour un flux de 10Mbps, tu dois avoir 10Mbps constant, ou plus
Avec du "fichier", il te suffit d'avoir 100Mbps réparti sur 10sec (donc : 10Mbps pendant 10sec, ou 100Mbps pendant 1sec), je trouve ça plus intéressant
-
Sur la capacité du serveur, un seul cœur d'un Xeon E5-1410 0 @2.80GHz ou d'un Xeon E3-1230 V2 @3.30GHz (j'ai testé les deux) sait envoyer 10 Gb/s de flux chiffré en https avec Apache2.
La charge CPU n'est pas le seul élèment a prendre en compte, mais si la carte PCI-express sais gérer 40 Gb/s sur le bus PCI express, je pense que le serveur (6 cœurs physique) devrait pouvoir monter à 40 Gb/s, sous réserve que le soft soit en mesure de répondre aux requêtes de 8 000 clients et qu'il utilise bien plusieurs cœurs (hypothèse d'un débit moyen de 5 Mb/s)
-
Tient j'ai les mêmes CPU 8)
-
8000 connexions en meme temps ca bouffe des ressources mémoires aussi, pas que du CPU et de l'I/O.
Il faut faire gaffe a ca meme si Varnish est opti pour ca. y'aura un gros 'tuning' de Varnish à faire.
après y'en a qui utilisent nginx (voir même "nginx plus") plutot que Varnish.
Le soft ca se change facilement si besoin et on peut meme faire de l'A/B testing pour comparer différents soft ou réglages.
Dailymotion par exemple ont des soucis de crash a 14Gbps avec Varnish, sur une config conçu pour du 20Gbps: http://engineering.dailymotion.com/varnish/
-
8000 connexions en meme temps ca bouffe des ressources mémoires aussi, pas que du CPU et de l'I/O.
Je doute d'atteindre autant de connexion par seconde
Avec, disons, 4000 clients qui regardent un flux à 10Mbps (total: 40Gbps), je pense que c'est plus proche de 400 clients qui téléchargent à 100Mbps pendant 1sec, que de 4000clients qui téléchargent à 10Mbps pendant 10sec
-
Avec, disons, 4000 clients qui regardent un flux à 10Mbps (total: 40Gbps), je pense que c'est plus proche de 400 clients qui téléchargent à 100Mbps pendant 1sec, que de 4000clients qui téléchargent à 10Mbps pendant 10sec
Pas de connexion persistante ? Le serveur envoie un header "Connection: close" ?
-
Je doute d'atteindre autant de connexion par seconde
Avec, disons, 4000 clients qui regardent un flux à 10Mbps (total: 40Gbps), je pense que c'est plus proche de 400 clients qui téléchargent à 100Mbps pendant 1sec, que de 4000clients qui téléchargent à 10Mbps pendant 10sec
Tu voudrais dire par là que le client télécharge son chunk HLS de 10 secondes en 1 seconde, attend 9 secondes puis recommence ?
-
Ce petit temps permet d'accueillir plus de monde sans prendre plus de bande passante puisque lorsqu'elle est libérée momentanèment par quelqu'un, elle peut servir à un autre client (un peu comme l'analogie avec les égouts)
-
Pas de connexion persistante ? Le serveur envoie un header "Connection: close" ?
Côté serveur non, côté client, ça ne m'étonnerai pas
Tu voudrais dire par là que le client télécharge son chunk HLS de 10 secondes en 1 seconde, attend 9 secondes puis recommence ?
C'est exactement ça : le client télécharge un fichier a la vitesse maximal, puis attends le temps restant qu'un nouveau fichier soit disponible
-
Côté serveur non, côté client, ça ne m'étonnerai pas
Je viens de faire un sniff sur un STB, et je confirme donc :
- le serveur envoie un Connection: keep-alive
- le client envoie un FIN après réception du fichier
Donc, une connexion par chunk
-
C'est quoi le soft coté upstream qui génère le HLS à partir des flux live ?
et coté client c'est quel soft HLS ?
-
Player propriétaire, aucune idée de ce que c'est, concrêtement
-
Merci pour les réponses.
Vivien t'a pointé vers un bon lien
En résumé, je préfère de loin payer 1€, une fois, par client, et m'économiser une quantité de travail conséquent (au niveau de la boite), [...]
Est-ce que ça ne coute pas plus cher que 1euro par client?
Est-ce que dans certaines DSP, il ne faut pas aussi re-dimensionner à la hausse la 'porte de collecte'? Ce qui implique des couts fixes et récurrents supplèmentaires...
Est-ce que tous les réseaux de DSP son suffisamment dimensionnés pour accueillir le débit supplèmentaire nécessaire?
Leon.
-
Pour les DSP qui font payer la collecte au Mb/s 95centile cela entraîne forcèment un sur-coût, mais il me semble que K-Net est sur des DSP qui ne font plus payer un prix pour le lien de collecte, sans vérifier la consommation, à un tarif assez faible.
Attention, certains réseaux font payer for cher les flux multicast qui sont rajoutés sur son réseau (il me semble que ce sont les les mêmes qui font payer le trafic de collecte au 95centile)
-
Est-ce que dans certaines DSP, il ne faut pas aussi re-dimensionner à la hausse la 'porte de collecte'? Ce qui implique des couts fixes et récurrents supplèmentaires...
De manière négligeable, oui
Est-ce que tous les réseaux de DSP son suffisamment dimensionnés pour accueillir le débit supplèmentaire nécessaire?
Suis-je concerné par cette question ? ::)
-
Suis-je concerné par cette question ? ::)
oui même si tu n'en es pas responsable, çà serait dommage que tu aies une solution inutilisable par tes abonnés ...
-
oui même si tu n'en es pas responsable, çà serait dommage que tu aies une solution inutilisable par tes abonnés ...
Ben, le réseau subit une constante évolution, la monté en débit en fait partie (que ce soit pour de la TV, pour plus d'abonné, ou pour des offres Gb)
Si la DSP en fait pas son travail, cela concerne le domaine économique, juridique et politique, pas technique
-
Est-ce que la DSP vous laisse prioriser ces flux, sur les flux internet de base ?
La commande sous Linux pour mettre le DSCP 20 en IPv4 et en IPv6 sur le trafic sortant du port 80 :
/sbin/iptables -t mangle -A OUTPUT -p tcp --sport 80 -j DSCP --set-dscp 20
/sbin/ip6tables -t mangle -A OUTPUT -p tcp --sport 80 -j DSCP --set-dscp 20
-
Pour certains, oui, mais je ne suis pas vraiment intéressé
La qos ne fonctionne pas par vlan, je ne vois aucune raison de penser que cela fonctionnera mieux avec du dscp
-
Le but est de limiter les cas où l'utilisateur va voir la TV se dégrader.
Par exemple un utilisateur qui fait un Test sur de très nombreuses connexions TCP en // pourrait arriver à dégrader une chaîne HD ou la téléphonie.
Dans les autres cas, c'est plus en cas d'incident sur la DSP où le reroutage du trafic entraîne une saturation.
Les gros opérateurs ont tous des stratégie de priorisation plus ou moins complexes (mais sur l'ADSL, l'absence de priorisation sur la téléphonie ou la TV est vite catastrophique)
-
Est-ce que la DSP vous laisse prioriser ces flux, sur les flux internet de base ?
Si le cache dans la Box est réellement de l'ordre de 10 secondes, je pense que la priorisation du flux n'est pas indispensable.
Leon.
-
un HLS est moins sensible qu'un flux tv 'tendu' mais quand meme ca peut merder si y'a une saturation.
C'est exactement comme Netflix et Youtube en fait (sauf qu'il n'y a pas de DASH).
Maintenant tout les clients sont en fibre et le serveur est pas 'loin' ou derriere un peering/transit.
apres je ne sais pas comment le lien "client KNet - DSP - KNet " fonctionne.
L'avantage du HLS est qu'on peut faire du P2P... un truc du genre:
- un client demande le prochain chunk de la chaine, le serveur lui envoi le chunk ainsi que quelques IP de clients (proches en terme d'infra) a qui il très récemment aussi envoyé ce chunk.
- au prochain chunk, plutôt que de demander en 1er au serveur, le client fait une demande en // a la liste des IP des autres clients. si aucun n'a le chunk suivant, le client demande au serveur.
ca me semble pas trop compliquer à mettre en oeuvre mais faut le coder (coté serveur et coté client). A priori KNet n'a pas la main sur le code du client ?
-
Netflix a des astuces (multiples connexions TCP) pour passer devant les autres en cas de saturation, sans mettre de DSCP.
Si on compare un flux K-Net a un flux Netflix sur un lien saturé, c'est le flux K-Net qui va souffrir.
Faites le test Netflix ou même Youtube contre CanalPlay, vous allez voir que CanalPlay se fait dégommer (baisse de résolution et même freeze complet). En regardant le fonctionnement, Canal Play me semble architecturé de la même façon (blocs de quelques secondes et le client attend d'avoir récupéré le bloc pour demander le suivant avec a chaque bloc une ouverture de connexion). Netflix va télécharger en continue (sur la même connexion TCP), et va le faire sur plusieurs connexions TCP.
Maintenant sur une ligne a 100 Mb/s c'est plus difficile a reproduire que sur un ADSL à 5 Mb/s.
-
oui et Netflix fait aussi de l'adaptatif (DASH) aussi donc baisse la résolution (donc la taille des chunks) si c'est encombré.
-
L'avantage du HLS est qu'on peut faire du P2P... un truc du genre:
- un client demande le prochain chunk de la chaine, le serveur lui envoi le chunk ainsi que quelques IP de clients (proches en terme d'infra) a qui il très récemment aussi envoyé ce chunk.
- au prochain chunk, plutôt que de demander en 1er au serveur, le client fait une demande en // a la liste des IP des autres clients. si aucun n'a le chunk suivant, le client demande au serveur.
ca me semble pas trop compliquer à mettre en oeuvre mais faut le coder (coté serveur et coté client). A priori KNet n'a pas la main sur le code du client ?
Tu ne vois que les avantages du P2P, alors qu'il y a aussi des inconvénients : vie privée (très facile de savoir qui regarde quoi), droits (si un mec regarde une chaine payante, ça débloque l'accès pour tout le monde ?), intégrité de la donnée (facile de réinjecter des données corrompues dans le réseau). Il faut vraiment comprendre que le P2P, c'est comme gueuler en place publique : je veux telle chaine, pour que tes peers t'envoient le jus. Malheur à celui qui commet le péché de luxure en zappant sur une chaine coquine ^^' .
De mon point de vue, cette solution fait très "bricolage".
-
Tu ne vois que les avantages du P2P, alors qu'il y a aussi des inconvénients : vie privée (très facile de savoir qui regarde quoi), droits (si un mec regarde une chaine payante, ça débloque l'accès pour tout le monde ?), intégrité de la donnée (facile de réinjecter des données corrompues dans le réseau). Il faut vraiment comprendre que le P2P, c'est comme gueuler en place publique : je veux telle chaine, pour que tes peers t'envoient le jus. Malheur à celui qui commet le péché de luxure en zappant sur une chaine coquine ^^' .
De mon point de vue, cette solution fait très "bricolage".
Pour la vie privée, si tu peux identifier la personne derrière l'IP, oui
Pour l'intégrité des données, elle est infalsifiable (les bloc sont vérifiés et rejectés si nécessaire)
Quant à la chaine payante, il suffit de ne pas la mettre au niveau du tracker
J'aime cette idée, je doute que cela se fasse un jour : il faudrait pouvoir faire du soft côté client, ce qui n'est pas vraiment le cas (très limité)
-
Ouais on peut intégrer une signature GPG dans chaque bloc, aussi...
-
Tu ne vois que les avantages du P2P, alors qu'il y a aussi des inconvénients : vie privée (très facile de savoir qui regarde quoi), droits (si un mec regarde une chaine payante, ça débloque l'accès pour tout le monde ?), intégrité de la donnée (facile de réinjecter des données corrompues dans le réseau). Il faut vraiment comprendre que le P2P, c'est comme gueuler en place publique : je veux telle chaine, pour que tes peers t'envoient le jus. Malheur à celui qui commet le péché de luxure en zappant sur une chaine coquine ^^' .
De mon point de vue, cette solution fait très "bricolage".
La tu généralises les défauts de "bittorrent" au P2P avec des clients open source sur des PC et qui peuvent faire n'importe quoi. C'est pas que ca le P2P.
Je ne propose pas d'utiliser du bittorrent mais un truc adhoc conçu par l'opérateur et contrôlé par lui dans les STB. C'est juste du cache réparti, ca se fait déjà pour du "backup ou cloud storage distribué" par exemple symform ou autre.
Avec une conception soignée y'a pas de soucis de vie privée, droits ou intégrité des données.
-
Ouais on peut intégrer une signature GPG dans chaque bloc, aussi...
Pourquoi faire ?
Quand je télécharge un fichier via torrent :
- je télécharge le fichier torrent via HTTPS, ce dernier contient la liste des chunks (+hash)
- je récupère la liste des pairs potentiels via tracker
- je récupère des chunks auprès des pairs, les chunks récupérés sont vérifiés (hash) et jeté si nécessaire
Je ne vois pas à quel endroit mon fichier de chats pourrait se transformer en fichier de culs ..
-
La tu généralises les défauts de "bittorrent" au P2P avec des clients open source sur des PC et qui peuvent faire n'importe quoi. C'est pas que ca le P2P.
Je ne propose pas d'utiliser du bittorrent mais un truc adhoc conçu par l'opérateur et contrôlé par lui dans les STB. C'est juste du cache réparti, ca se fait déjà pour du "backup ou cloud storage distribué" par exemple symform ou autre.
Avec une conception soignée y'a pas de soucis de vie privée, droits ou intégrité des données.
Euuuuuh, je n'ai pas parlé du tout de BitTorrent hein. Et la répartition d'un cache n'a rien à voir avec le P2P. J'ai l'impression que tu mélanges un peu tout ce soir, je mets ça sur le compte de l'apéro :)
Mon message portait sur le P2P en général et je l'entendais dans le sens où si un client reçoit TF1 par la bécane de Jack, il puisse lui aussi relayer la chaine à ceux qui veulent la suivre dans son quartier.
Je ne vois pas à quel endroit mon fichier de chats pourrait se transformer en fichier de culs ..
Hum, de simples bits aléatoires chez le peer ça suffit à faire couper son flux TV (invalidant ses blocs, le forcant à les retécharger et donc, à prendre du retard).
-
Hum, de simples bits aléatoires chez le peer ça suffit à faire couper son flux TV (invalidant ses blocs, le forcant à les retécharger et donc, à prendre du retard).
piece length—number of bytes per piece. This is commonly 28 KiB = 256 KiB = 262,144 B.
Sauf conspiration, je gage que le client va réussir à télécharger les 256KB en 10sec 8)
Ceci dit, c'est une bonne remarque, je me demande si les clients torrent peuvent "éliminer" les pairs qui génèrent trop d'erreur
-
Euuuuuh, je n'ai pas parlé du tout de BitTorrent hein. Et la répartition d'un cache n'a rien à voir avec le P2P. J'ai l'impression que tu mélanges un peu tout ce soir, je mets ça sur le compte de l'apéro :)
tu n'as pas parlé de BitTorrent mais tes objections sur le P2P sont celles uselement faites au BitTorrent d'ou le rapprochement.
non je ne mélange rien et c'est très clair pour moi. En quoi un cache réparti n'a rien avoir avec du P2P ? on ne doit pas se comprendre ou parler des memes choses, je parle d'un cache réparti au sens général du terme, pas au sens memcached, etcd, Redis, etc.
et non j'ai pas bu l'apéro encore.
-
Quand on sait à quel point Jack aime les chatons, ce serait un drame pour lui.
-
je me demande si les clients torrent peuvent "éliminer" les pairs qui génèrent trop d'erreur
Comme ça il me semble bien que oui et si c'est pas le cas ça serait facile à mettre en place.