Note: cette idée de "métaserveur" de tuiles je suis en train de l'exprimenter localement dans un greffon Java pour JOSM. Le "serveur" est en fait sur mon PC, il gère lui-même ses caches et sa file d'attente, mais dans JOSM il me suffit de pointer le serveur TMS sur mon petit service local.
Au passage j'ai viré complètement le pseudo-"cache" de tuiles intégré à JOSM (défectueux car il ne se purge pas correctement et ne gère pas les expirations, rapidement il sature mon stockage local avec des tuiles obsolètes depuis longtemps, et j'étais sans arrêt en train de le purger, ce qui demande quelques minutes de travail quand il y a des milliers de fichiers de tuiles et de fichiers tag à effacer): à la place JOSM utilise un cache externe standard et conforme (Squid), il me suffit juste de configurer JOSM pour utiliser un proxy de mon choix (mon Squid), qui en plus est beaucoup plus performant et gère beaucoup mieux le stockage. Dans JOSM en revanche il n'y a plus qu'un petit cache web en mémoire (max 128Mo ça me suffit largement) par lequel transite tout le traffic web HTTP ou HTTPS (les tuiles, les JSON, les requêtes de données XML à la base, les mises à jours de plugins...) car j'ai reconfiguré le cache web par défaut de la VM Java (pour qu'il ne pollue pas non plus l'espace dans les données utilisateur Java): toute requête HTTP ou HTTPS qui retourne plus de 1 Mo n'est même pas gardé dans ce cache mémoire, car c'est mon proxy local (Squid) qui prend ça en charge (au passage il me sert aussi pour autre chose que JOSM, notamment les navigateurs que j'ai configurés aussi pour utiliser ce proxy web, partagé aussi sur plusieurs PC). Les I/O disque local ont largement diminué, JOSM est beaucoup plus réactif et utilise moins de mémoire, son garbage collector est moins sollicité aussi. ---- Prochaine étape: intégrer ce squid en mode "transparent" (sans aucune configuration nécessaire sur les PC ou mobiles, autre que de désactiver ou réduire les caches locaux) sur mon routeur Internet auquel j'ai adjoint un stockage USB externe (j'ai déjà un routeur transparent Ethernet/Ethernet) entre ma box et mon réseau local Ethernet (ou Wifi), ce routeur contient déjà un antivirus et un outil d'administration de parefeu plus efficace que celui de la box de mon opérateur, ainsi qu'un serveur de stockage et de médias. Ce routeur est sous Linux (avec un shell BusyBox, pas de X11), c'est en fait un mini PC (à processeur compatible x86 et non ARM) mais avec plus de mémoire que ce qu'on trouve habituellement et plus de connectivité de stockage, et ça boote bien plus vite qu'un PC (ou que la box du FAI qui met plusieurs minutes et qui perturbe le fonctionnement du réseau local !) et consomme même moins d'énergie que la box du FAI ! Le réseau local est constamment disponible même si la box du FAI ne l'est pas toujours (on ne sait jamais quand le FAI décide de la rebooter à distance). On pourrait faire ce type de routeur sur une Raspberry, voire n'importe quel vieux PC recyclé (mais moins efficace car boot plus lent à moins de changer de BIOS et peu économe en énergie et souvent encombrant et pas toujours avec la connectivité qu'on voudrait pour y mettre un stockage type NAS). D'ailleurs je ne comprends pas pourquoi on ne trouve pas ça préconfiguré sur le marché : on trouve des serveurs de médias, des NAS, parfois un parefeu voire un antivirus en général assez mauvais, mais rien intégrant des caches efficicaces (y compris pour les mobiles connectés en Wifi). Aucune des "box" des FAI ne gère ça. En plus ces box imposent un DNS mal fichu et souvent intrusif, (pour le DNS je suis passé chez OpenDNS pour ne pas utiliser les DNS du FAI, d'autant plus que le client-proxy DNS intégré aux box sature trop vite et répond alors n'importe quoi !) Et le serveur UPnP (pour la configuration NAT+PAT) est tout aussi mal fichu dans toutes les "box" Au passage mon routeur gère aussi la compatibilité IPv6 (pas besoin de terminaison locale de tunnel sur les PC ou mobiles connectés, IPv6 est fourni nativement, le(s) tunnel(s) sont établis par mon routeur, la box du FAI ne s'occupe de rien et ne voit qu'un "PC anonyme" connecté en IPv4 sur un port Ethernet mais qui n'utilise jamais le DNS du FAI ni l'UPnP de la box, qui elle-même fonctionne beaucoup mieux et plante moins souvent un fois qu'on y a désactivé tous les services non nécessaires!), en attendant que le FAI propose une réelle connexion IPv6 native, sans tunnel dont la terminaison est sur un serveur surchargé et mal administré (comme le fait encore Orange qui n'a pas avancé d'un pouce depuis une douzaine d'années... SFR en a fait encore moins, Bouygues ne propose rien non plus, Free propose un IPv6 qui fonctionne mais avec de forts bridages). Microsoft propose pour Windows son tunnel-broker pour IPv6-sur-IPv4 mais il est lui aussi très lent et limité en protocoles et services, il le supporte en fait uniquement pour connecter sa communauté de joueurs XBox, chaque jeu utilisant ensuite son propre tunnel si nécessaire mais la plupart faisant une connexion IPv4 sur un unique port UDP au serveur de jeux de son fournisseur, ce port UDP transporte aussi du TCP, mais encapsulé en RUDP sur ce même port UDP pour mieux gérer les temps de réponse et priorités de trafic et éviter les "freezes" du TCP natif). D'autres services Internet utilisent leurs propres tunnels-brokers IPv6-sur-IPv4 pour les communications instantanées interpersonnelles (chat, VoIP...), y compris avec les mobiles dans le monde entier (si le FAI de leurs utilisateurs n'a pas de connectivité IPv6 native ou si le routeur propose une connectivité trop lente ou restreinte), mais ces tunnels ne sont pas toujours très stables non plus. Ce qui est commun partout, c'est que ces applications essayent d'évaluer la connection IPv6 locale, et si ça ne marche pas ou pas bien, un autre tunnel sera créé et utilisé. Le 27 mai 2016 à 21:59, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Y a-t-il moyen d'enrichir les métadonnées sur ce poroxy pour qu'il > mentionne des corrections de date effective de mise à jour, afin de pouvoir > alors utiliser une autre source ortho plus récente ? > > L'idée serait d'associer à une donnée en cache sur une zone indiquant une > date de la ramener à une date antérieure plus correcte (juste enregistrer > ces deux dates sur cette zone définie comme un ensemble de tuiles: toutes > les tuiles dont la BD Ortho mentionnant une date entre les deux sera > ramenée à la plus ancienne; si plus tard la BD Ortho met à jour cette zone > avec des tuiles valides, elle indiquera avec cette tuile une date hors de > cet intervalle, et alors le cache de dates corrigées pourrait être supprimé > automatiquement au moins sur cette tuile; on peut garder en cache le > contour de la zone avec la technique des "quadtiles" pour en réduire le > volume, par exemple si cela concerne un département entier comprenant de > nombreuses tuiles; évidemment ce cache est dépendant du niveau de zoom, > chaque niveau ayant ses mises à jour) > > --- > > Ensuite on pourrait imaginer de mettre en place un *autre* serveur > (beaucoup plus compliqué!) permettant de combiner les sources d'ortho ayant > chacune ce système de cache de dates, pour les comparer et ne retenir que > la plus récente dans les requétes par défaut (mais les métadonnées > pourraient lister plusieurs versions venant de différentes sources, ces > sources étant classées par date, et permettant de voir certaines évolutions. >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
