[OSM-talk-fr] Encore un revert svp

[Philippe Verdy]

Le 18 février 2013 23:05, Christian Quest <cquest at openstreetmap.fr> a écrit :
> * à part ces doublons créés par JOSM et les serveurs OSM... du jamais vu
> jusque là il fallait que ça tombe sur Philippe !

Je connais un cas pas si rare que ça : c'est quand pour une raison ou
une autre la session HTTP tombe en cours de route : JOSM ne signale
rien du tout mais arrêt l'upload en laissant des objets orphelins ou
des objets qui auraient du être affacés à la fin.

On s'en rend compte uniquement parce que le changeset n'est pas fermé
: c'est pour ça qu'après un upload j'appuie sur CTRL+ALT+Q pour
vérifier que le changeset est bien fermé et complet et n'a pas été
interrompu en cours. Et c'"était justement le cas lors de l'import qui
a raté avec toutes les créations d'objets en double (alors que ce sont
normalement les premières à être envoyées, avant les modifs et les
suppression à la fin, mais le changeset contenait bien le tout :
créations, modifs, et suppressions c'est la première partie qui s'est
exécutée deux fois sur le serveur et dans la même session HTTP car les
IDs que j'avais dans mon fichier OSM étaient ceux de la seconde
version, et aucun de la première version envooyée par JOSM).

J'ai ce genre d'erreur beaucoup plus souvent si je laisse JOSM tout
envoyer en une seule transaction: pour limiter les dégats je lui fait
envoyer les objets par petits paquets de 5 objets maxi (il faut plus
de requêtes mais elles sont moins lourdes sur le serveur, il y a moins
de chance que la session tombe pendant l'exécution d'une grosse
requête) ; cela allège énormément aussi le temps pour résoudre les
conflits, même si quand il y en a un je vais systématiquement faire
CTRL+ALT+M après pour resynchroniser tous les autres objets en cours
de modif et qui n'ont pas encore été envoyés et marqués en conflit par
le serveur.

Ca permet aussi de limiter énormément le nombre de conflits à résoudre
pour pouvoir faire une sauvegarde intermédiaire (quand il y en a le
plus, c'est quand un conflit survient sur l'envoi d'un chemin modifié
avec un conflit par noeud modifié par quelqu'un d'autre (mais ça
dépasse rarement une vingtaine de conflits à résoudre pour fusionner
et recontrôler le tout, sauvegarder à nouveau, avant d'envoyer la
suite). Je me demande pourquoi JOSM par défaut essaye toujours de tout
envoyer en une seule requête (ce qui complique ensuite les corrections
en cas de problème en milieu d'un gros paquet).

Mais il se trouve qu'ici justement je veais de réinstaller JOSM et que
j'avais oublié de réduire la taille des requêtes. Une grosse
transaction est partie mais je ne sais pas comment JOSM a récupéré une
exception interne inattendue pour reprendre l'envoi sans rien dire et
faire comme si de rien n'était, en envoyant à nouveau les objets à
créer avec les mêmes ID négatifs sans lire la réponse du serveur lors
du premier essai d'envoi !

La requête n'était pourtant pas si volumineuse, mais l'envoi a été
inhabituellement long (je penche pour une rupture de session TCP entre
chez moi et le serveur non rapportée par un routeur intermédiaire ou
par le FAI, ou rapportée tardivement : en TCP il faut au moins 30
secondes minimum pour avoir au moins une erreur timeout en attente
d'un ACK ou d'un NAK TCP, qui normalement ne prend que le temps du
round-trip voisin de 20 ms si on le reçoit, multiplié par le nombre
d'essais d'envoi des datagrammes non acquittés, ce qui prend alors au
moins 3 minutes si la rupture de session TCP n'est pas rapportée au
client ; bien plus long en fait que l'exécution de la requête que
j'avais envoyée; sans doute le timeout est arrivé mais bien après).

TCP est réputé "fiable" mais qui n'a jamais téléchargé un gros fichier
ISO qui s'est avéré corrompu une fois qu'on l'utilise (alors qu'il se
monte très bien ou peut être gravé sans erreur sur un DVD) ?

Il y a bien la solution HTTPS mais le serveur actuellement ne semble
l'utiliser que pour l'authentification et pas pour la signature
sécurisée des transferts (je ne parle pas du cryptage ici mais d'un
hachage sûr comme MD5 au minimum -- SHA1 préférable -- au sein même de
la session HTTP ou bien au sein des transactions XML) : on envoie du
XML brut, sans aucune clé de vérification par le serveur.