[WT-support] Perte de qso en reseau ?

Noel Chenavard nc at lem.com
Tue Jun 8 12:19:15 CEST 2004


Bonjour à tous,
nous avons constaté un bug assez génant:
certains qso sont enregistrés sur le PC ou ils sont saisis, mais ne
parviennent pas à d'autres PC en réseau.

Les logs sont donc désynchronisés.
Ce n'est pas un problème si  on a un PC par bande, sauf qu'on peut réclamer
un qsy alors que le qso a déjè été fait.
Par contre, si on saisi plusieurs bandes sur un nombre restreint de PC, il
peut y avoir pas mal de confusion.

Dans ces conditions, je vois mal comment gérer une numérotation séparée par
bande
consistante sur sur tous les PC.

Nous utilisions des PC récents sous XP, reconfigurés à zero la semaine avant
le contest, avec tous les patches de sécurité.
Ils étaient connectés en ethernet avec un switch linksys 10/100, avec 3 m de
cable UTP.
Ce qui est curieux, c'est que les infos "tchatche" alt-G passaient bien ,
mais pas certains qso.
Ca ne semble pas lié au fait qu'on passe en émisission ou pas (interferences
HF?).

Je crois que WT utilise comme CT le protocole UDP qui est plutot du type
"send & pray".
Le concept est proche du "peer-to-peer" ou personne n'est vraiment maitre,
avec de  l'information redondante qui fait que l'ensemble résiste bien aux
pannes, avec une simplicité de config à toute épreuve.

A ma connaissance, CT envoie une seule trame par qso, et on espère que tous
les autres PC en réseau vont l'attraper et la traiter.
Si une trame passe mal, le qso ne sera pas enregistré sur d'autres PC.

L'expérience montre que malgré tout, c'est relativement fiable: on a
constaté des pertes de l'ordre de 1 à 3 pour 1000 QSO,
Cependant, le système à l'air mois fiable en WiFi ou certains utilisateurs
constatent plus de pertes.

Est ce  qu'il ne faut pas repenser le protocole réseau de WT, avec par
exemple un station "master" qui aurait en plus de l'heure, le log
"consolidé"
et l'index des derniers numéros par bande (editable si necessaire), etc...
?
Les PC esclave devraient se connecter au master (telnet?) et pourraient
recharger le log en cas de besoin.

C'est juste quelques idées en vrac. mais l'équipe support a sans doute déjà
planché la dessus...

73 de Noel F6BGC












More information about the Support mailing list