Maintien de connexion V17 R3, 4DPeer.txt et interruption de connexion

Bonjour,

J’attendais la V17 R3 depuis des semaines par rapport à un souci qui semblait être résolu avec la gestion d’un UUID par poste et du fichier 4Dpeer.txt et ainsi éviter des soucis en cas de changement brutal d’adresse IP, voir https://kb.4d.com/assetid=78137

Or cela ne fonctionne toujours pas … J’ai vérifié, le fichier 4Dpeer.txt est bien présent sur le poste.

Voila mon environnement de test :

  • Application non compilée en client-serveur en Mas OS (10.12.6 pour le serveur et 10.14.1 pour le client)

  • Je me connecte une première fois sur le serveur avec une IP. Sur des micro-coupures ou des coupures du réseau de 30 secondes, pas de soucis, mon 4D client arrive à se reconnecter au serveur sur sa session en cours.

  • Je change alors l’adresse IP de mon client en laissant mon 4D client ouvert : impossible pour le 4D client de maintenir la connexion et au bout de 60 secondes, j’ai une interruption de la connexion à la base en cours. Je me reconnecte alors, et sur le serveur, je me retrouve avec deux utilisateurs (un par adresse IP) : j’ai donc une licence de perdue et tous les enregistrements ouverts par la première connexion sont bloqués.

Ces “fantômes” restent actifs pendant 2h30 environ avant d’être effacés du serveur.

Je refait un arrêt du réseau, au bout de 60s , interruption de la connexion, je me reconnecte alors en gardant mon adresse IP cette fois.

Et là, la R3 est pire que la R2 car avec la R2 lors de la reconnexion avec la même adresse IP, le fantôme précèdent était effacé pour être remplacé par la nouvelle connexion. Avec la R3, je me retrouve avec un 3ème utilisateur lors de la reconnexion (2 licences de perdues et 2 fois plus d’enregistrements bloqués). Et je n’arrive même pas manuellement à forcer la déconnexion d’un utilisateur depuis le serveur !

Bref, cela ne correspond pas du tout à mes attentes et est un réel handicap de fonctionnement.

Je fais quelque chose de mal ? Comment peut-on régler et diminuer cette durée de 2h30 pendant lesquelles les licences sont bloqués pour rien ?

Et est-il possible de monter le temps avant l’interruption de la base de données, 60 secondes est très court ? J’aimerais pouvoir changer du bureau avec un portable sans perdre la connexion, un timeout de 5mn serait pas mal.

Après un autre test, je viens de constater que le timeout de 60s n’est présent que si une requête a lieu vers le serveur, si je reste sur un écran sans cliquer, je peux tenir plus de 5mn (et me reconnecter ensuite), par contre si la connexion n’est pas revenue avant de faire un clic dans mon application, j’ai de nouveau une interruption de base.

Mais bon, à la limite, ce problème de timeout de 60s est presque secondaire par rapport au soucis d’utilisateurs fantômes sur le serveur.

Je ne pense pas être le seul dans ce cas, mais devant migrer de la V15 32 bits à la V17 64 bits dès que possible, je ne peux raisonnablement pas le faire avec un tel comportement …

Merci de votre pour comprendre et résoudre cette aberration …

En lisant cela, je ne comprends pas que si peu de gens rencontre le problème.
J’ai remonté tous ces soucis il y a plus de 6 mois, on était encore en v16.
Le problème c’est la nouvelle couche réseau et la gestion des licences 4D et la manière dont est géré la nouvelle notion d’endormissement…

Ce n’est pas tenable de conserver plusieurs licences actives pour un même poste client.(normalement, l’usage du 4Dpeer.TXT aurait du résoudre cela; mais, apparement ce n’est pas encore au point…)

En lisant le tableau des prochaines versions qui arrivent, lorsque je vois que la version 32 bit et que l’ancienne couche réseau vont disparaitre; il reste encore du travail. J’espère qu’avant de supprimer ce qui fonctionne (aka l’ancienne couche réseau), on aura quelque chose qui fonctionne également pour les remplacer… :roll:

Il devrait y avoir un réglage du Timeout du temps de conservation des clients endormi.
Timeout connexions inactives (54) a utiliser avec la commande FIXER PARAMETRE BASE )
A tester.

Oui, vu l’ampleur du soucis, c’est incompréhensible de ne pas avoir plus de monde touché par ce problème …

Je vais regarder dans les timeout …

Après, n’ayant pas de contrat avec 4D en dehors du suivi logiciel, je ne peux pas déclarer d’incidents …

Un doute car je ne sais plus, quand tu avais fait tes tests, c’était sur une application compilée ou sur du client-serveur direct ? Est-ce que le fait de compiler son application pourrait résoudre ceci (même si ce n’est pas vraiment logique que le bug ne soit pas présent en compilé …)

Nous sommes éditeurs, donc nous compilons et fusionnons notre application OEM en client-serveur sur Mac et sur PC.

Vu le nombre de problèmes (à l’époque), j’ai laissé à d’autres le soin de défricher. Actuellement, nous déployons en serveur 64bit mais utilisons volontairement l’ancienne couche réseau. (N.B. : nous sommes forcés de rester en clients 32bit : 4D View)

Nous avions d’énormes problèmes de gestion de licences ; celles de 4D comme toi, mais également les nôtres puisque basées sur celles de 4D…

Je n’ai pas retesté récemment donc je ne sais pas à quel stade ça en est mais visiblement ce n’est pas encore ça…

Ça me perturbe d’autant plus que le but est de basculer sur cette nouvelle couche réseau une fois qu’elle sera stabilisée et utilisable…

Certains te diront qu’il FAUT compiler donc je serais toi je tenterais le coup juste pour éliminer cette hypothèse.

Mais tant que la gestion du 4Dpeer ne sera pas fonctionnelle, je ne vois pas comment on peut utiliser cette couche réseau pour des applications en client-serveur…

Bon pour compiler, cela va être difficile, je n’ai pas la licence … Sans compter que j’ai beaucoup de vieux code à corriger pour compiler l’application …

Dans mes tests de hier, j’avais oublié sur mon serveur 64 bits de décocher la case “Utiliser l’ancienne couche réseau”, mais bon, cela ne change pas grand chose au final, toujours des fantômes sur les changements d’IP brutales. Ca va mieux sur les déconnexions sans changements d’IP, car pas de fantômes quand l’utilisateur se reconnecte (par contre si après un plantage, l’utilisateur ne se reconnecte pas, toujours plus de 2h de licences bloquées).

J’ai fini par tester si en 32 bits ancienne couche réseau, ca va, on retrouve les habitudes de la V15 : les fantômes disparaissent entre 3 et 10mn (je ne saurais expliquer pourquoi ce n’est pas plus fixe…). Mais bon, avec Apple qui va nous sortir un OS total 64 bits d’ici fin 2019, ça devient compliqué de déployer en 32 bits actuellement …

Sinon un serveur en 32 bits ancienne couche réseau avec un client 64 bits marche quand même, même si je ne vois pas trop l’impact que cela peut faire avec une telle configuration …

Par contre, je viens de faire une série de tests en décochant la case “Crypter les connexions clients-serveurs” et les choses vont beaucoup mieux !!! :smiley: Je vais approfondir pour voir dans les prochains jours si le soucis vient que de cette option ou de ma clé de cryptage, à suivre …

Bonjour,

Depuis 15 jours, je n’ai pas eu le temps de revenir sur ce soucis, mais voila, je viens de faire une batterie de tests dans tous les sens et c’est moins pire que je le pensais.

Déjà, 1er constat, il y a une différence si les communications clients-serveurs sont cryptées ou non. Tous mes tests ont été fait en version Mac 64bits nouvelle couche réseau avec un client Mac 64bits.

Globalement, le seul problème le plus grave est si le client change d’adresse IP, je pensais que le 4DPeer.txt devait résoudre ceci, mais impossible, dès qu’un client change d’IP, c’est mort, on a un fantôme sur le serveur et tous ses enregistrements bloqués pendant 2h-2h30 (avec le cryptage des communications clients-serveurs).

Par contre, si les communications clients-serveurs ne sont pas cryptées, pas de soucis, le serveur éjecte tout seul le fantôme au bout de 2mn environ (comme sur la V15 32bits).

De même, lorsqu’un client perd sa connexion internet, il ne dispose que de 50 secondes environ pour pouvoir se reconnecter. J’ai essayé plusieurs paramètres comme le FIXER PARAMETRE BASE, mais non, rien n’y fait, impossible de maintenir sa connexion plus de 50 secondes. Je ne comprends pas toutes ces possibilités d’endormissements comme le process qui passent en Postponed (ou alors, cela vient du fait que mon application n’est pas compilée ?). Si les communications clients-serveurs sont cryptées, on a de nouveau facilement un fantôme, mais pas toujours (ce qui n’est jamais le cas si cela n’est pas crypté).

Bref, je sais que si je ne crypte pas les communications, la V17R3 ne devrait pas trop me poser de soucis en prod, je vais donc franchir le cap dans les prochaines semaines, et je vais peut-être quand même tester avec le cryptage des communications pour voir si avec mes utilisateurs, c’est un réel soucis ou non.

J’aimerais bien pouvoir déclarer le bug auprès de 4D, mais n’ayant pas de contrat le permettant, je ne vois pas comment faire.
Pour résumer si quelqu’un a la possibilité de le faire, voici les soucis :

  • si les communications clients-serveurs sont cryptées et qu’un utilisateur change d’adresse IP, on a un fantôme pendant plus de 2h
  • si les communications clients-serveurs ne sont pas cryptées et qu’un utilisateur change d’adresse IP, on perd la connexion et l’utilisateur est éjecté du serveur au bout de 2mn
  • il est impossible de déconnecter manuellement un fantôme depuis l’interface d’admin du serveur
  • si jamais on essaie de quitter l’application 4D Serveur pendant qu’il y a un fantôme, l’application de bloque et ne répond plus et on est obligé de forcer à quitter le 4D Serveur

De plus, j’aimerais bien avoir une doc claire et précise pour mieux gérer les déconnexions et mise en veille des process :

  • Est-ce que certains de mes soucis viennent du fait que mon application n’est pas compilée ?
  • Comment faire pour que les utilisateurs puissent se mettre en veille pendant 5 ou 10mn (par exemple pour changer de bureau en considérant que l’on garde la même IP fixe pour ne pas avoir de soucis).
  • Comment éviter les déconnexions brutales au bout de 50 secondes lorsque l’on perd le réseau ?

Voila un peu l’état des lieux, à suivre une fois que je serais passé à la V17 …