Noter quand même que le téléchargement en torrent d'un fichier Planet de ~53 Go prend pas loin 7 heures même en fibre. Dont au moins 2 heures en session "stalled". La raison est un démarrage très lent (lié au fait qu'il y a une préallocation initiale de 53 Go qui peut imposer de bloquer l'appli pendant plus d'une heure juste pour écrire des zéros avant de pouvoir écrire le moindre fragment. C'est un problème de la gestion des IO dans les applis torrent. Une fois cette heure passée, ce qui a déjà été chargé est perdu (session perdues) et le client se trouve temporairement "banni" des peers hôtes, et on récupère très lentement la capacité de télécharger et le débit maximum n'est pas atteint tant qu'on n'a pas téléchargé au moins 50% du fichier, les derniers 50% se font en moins d'une heure. C'est un problème de libtorrent toujours pas résolu. Il n'a pas été mis au point pour supporter correctement des fichiers de plus de 4Go. Ce qui laisse à penser que pour une distribution efficace, il serait sans doute avantageux de "splitter" ces fichiers de 50Go en parties de 4Go maximum et fournir un outil permettant ensuite de les concaténer rapidement. Ce problème existe aussi bien sous Windows que Linux et notamment si on télécharge non par sur un SSD (les SSD de forte capacité sont chers) mais sur un disque dur ou un RAID. Pour l'instant aucune correction en vue de libtorrent (utilisé pas la plupart des clients torrent, y compris l'officiel BitTorrent ou microBittorrent ou qBitTorrent, parmi les plus populaires, mais aussi le client Torrent intégré à la Freebox). Bref il faut être TRES patient et ne PAS devoir rebooter son PC pendant plus d'une heure et demi (en forçant un "kill" de l'appli Torrent qui ne répond pas et est bloqué avec une I/O depuis une heure ou plus par l'OS qui passe son temps à écrire des zéros dans les parties non téléchargées avant de pouvoir écrire le fragment demandé). Autre solution: télécharger temporairement sur un SSD et déplacer le torrent terminé vers son nouvel emplacement (non pris en charge par les applis actuelles: il faut arrêter le torrent, copier le fichier (cela prend quelques minutes mais ce n'est pas bloquant), modifier le dossier dans les propriétés du torrent pour indiquer son nouvel emplacement et pouvoir le repartager. Beaucoup se contenteront d'arrêter le torrent immédiatement une fois terminé et ne le remettront pas en route : le repartage ne fonctionne pas. On en reste donc à une dépendance à quelques gros peers J'ai demandé aux auteurs de libtorrent de prendre en charge la "préallocation" de façon efficace (on peut tout à fait préallouer un fichier de 50Go initialisé "virtuellement" à zéro en quelques millisecondes, aussi bien sous Windows que Linux mais il faut utiliser des API non POSIX. Libtorrent pour l'instant ne connait et n'utiliser que les API de création de fichier, "seek" (valable uniquement dans l'espace déjà alloué) et write et implémente très mal la préallocation (qu'il propose mais de façon horrible). Seule parade: forcer le téléchargement séquentiel (mais on perd la capacité du Torrent de distribuer en priorité des fragments moins partagés: le démarrage sera rapide, mais la fin du téléchargement sera très lente car il y aura peu de disponibilité hormis quelques gros peers surchargés qui limitent fortement le débit pour satisfaire tout le monde). Pour l'instant si je compare le temps nécessaire, c'est 10 fois plus long de télécharger un fichier planet en Torrent qu'en simple HTTP. Le torrent n'est pas pour tout le monde: il faut une connexion fibre (en DSL pas moyen d'avancer) Le protocole Torrent n'est pas en cause mais bien l'implémentation (libtorrent en l'occurrence qui fait office de "standard" pour pas mal d'applis, porté sous Windows, Linux, et quelques systèmes BSD, sans doute aussi macOS mais je n'ai pas regardé)
Note: @cquest: tes Torrents mentionnent trois trackers qui ne fonctionnent pas du tout et rejettent toute connexion (ou connexion échouée en timeout): * http://tracker.cquest.org:6969/announce (visiblement il est "off" chez toi) * http://tracker.computel.fr:80/announce (ne fonctionne quasiment jamais) * retracker.local (non routable : ne fonctionne jamais, comment on est sensé y accéder???) Les deux seuls trackers utilisables sont: * udp://tracker.opentrackr.org:1337/announce * udp://tracker.torrent.eu.org:451/announce Le sam. 15 août 2020 à 11:28, Christian Quest <[email protected]> a écrit : > Le 15/08/2020 à 10:04, Yves P. a écrit : > > Des technos plus basiques (HTTP) me semblent largement suffisantes pour > démarrer et pour faciliter l'adoption initiale. > > L'adoption des consommateurs ou l'adoption par les archiveurs ? > Les consommateurs accéderaient les images via une passerelle HTTP, donc > aucune différence pour eux. > > +1 > > Pour les archiveurs/miroirs idem, ils pourraient faire miroir via IPFS ou > via n'importe quel autre protocole (rsync, FTP...). Ce ne serait qu'un > avantage supplémentaire. > > Le but d'une archive est qu'elle soit pérenne. La rendre > "mirrorable"/"shardable" facilement me semble important pour éviter les > risques associés à avoir qu'un seul miroir. C'est là qu'IPFS excelle vu que > n'importe qui peut devenir lui-même miroir sans manipulation de la part du > miroir principal. > > +1 > > IPFS serait un CDN de facto. Ton / tes serveur (s) stockent nativement les > images sur IFPS. > La fondation OSM peux rajouter autant de serveurs sans difficultés, les > performance et la fiabilité en seront améliorées. > > Les clients passent par des serveurs webs classique (et pourquoi pas à > terme directement via IPFS). > > Le gain pour un stockage / archivage de photo ne saute pas aux yeux, mais > pour le stockage / partage de fichiers pbf ça me parait "évident". > D'autant plus que tu avais parler de ça en février : "Héberger un mirroir > ou un bittorrent pour les planet, possible?" > > La diffusion du fichier planet en pbf par bittorrent tourne depuis fin > janvier: https://osm.cquest.org/torrents/ > > -- > Christian Quest - OpenStreetMap France > > _______________________________________________ > Talk-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
