Citrix or not Citrix

Bonjour à tous,

Pour une utilisation sous 4D Server avec des sites à quelques dizaines de Km, quelle est votre expérience d’une utilisation avec ou sans Citrix ? Notamment pour d’éventuels problème de latence, de bande passante, etc. ? Y a-t-il moyen de paramétrer 4D Server pour qu’il résiste mieux aux aléas du réseau ?

Les kilomètres n’ont pas d’incidence en revanche la qualité de la connexion (débit, latence et surtout STABILITÉ) elle en a hélas oui.

Bonjour Bernard,
mon expérience personnelle de connexion directe du client au serveur en distant (WAN) est qu’on peut faire de très bonnes applications avec 4D dans ce contexte. Je pense qu’ORDA est fait pour ça, d’ailleurs, pas seulement pour se faire plaisir avec une nouvelle syntaxe. Concevoir aujourd’hui une application sans se soucier de clients distants, c’est se condamner à perdre des marchés car ce que je retiens du confinement est que les applis conçues pour le distant ont permis aux entreprises de maintenir leur activité et qu’on n’a pas fini d’entendre parler de télétravail.

Si ton application n’a pas été développée de cette façon, il est quasi certain qu’elle révèlera tout un tas de défauts. Par exemple, en développant en distant, on apprend qu’un “tant que non fin de sélection” ou l’abus de “enregistrements dans table” sont des tueurs de temps de réponse ; ou qu’au contraire “lecture écriture” et “fixer lien champ” ne génèrent aucun traffic. Choses que jamais on ne décèlera en local. Mais tout ça, c’est de l’expérience qui s’acquière, ne pas comprendre cela est aussi stupide que prétendre écrire du client/serveur en ne développant qu’en monoposte. J’ajouterais que, personnellement, je trouve passionnant ce mode de développement, et quand on me dit « ha bin oui mais chez moi le 4d il est tout mou », je prends ça comme un défi.

Maintenant, dans l’immédiat, avec citrix ou autre équivalent TSE, tu es sûr de proposer des temps de réponse corrects d’emblée. Mais ça ne dispense pas de garder comme objectif premier de s’en débarrasser le plus vite possible car ça revient peu ou prou à faire bosser tous les utilisateurs “façon TeamViewer” et à filer des sous à la solution TSE, je préfère me les garder.

Au niveau du serveur il n’y a rien de spécial à faire - à la limite, en distant, il est vachement plus pépère qu’en local puisqu’on fait en sorte de l’interroger le moins possible. La latence et le débit, tu peux d’emblée considérer que, si le client est connecté avec un adsl ou une clé 4G au fond de sa cambrousse, coté serveur tu n’y peux strictement rien.

Retour de questions :

  • as-tu testé en distant ?
  • qu’est-ce que ça donne ?

PS : quelle version de 4D ?

Je me répète mais la STABILITÉ est plus importante(critique) que le débit.

J’ai eu des clients en 4G me disant qu’il avait toutes les barres :roll_eyes:, etc…; mais la connexion avait des micros coupures toutes les minutes !!! sur ce type de connexion le télétravail en direct via une application 4D Client est impossible…

Donc, pour moi, l’intérêt de ces technos (TSE, Citrix et consorts) c’est de répondre à des problématiques d’infrastructures réseau qu’aucune autre techno ne gère actuellement. Sauf à utiliser des applications full web.

Quelle version 4D, et, surtout, quelle couche réseau ?

Pour ce client, c’était de la v17.4(32 bit) ancienne couche réseau ; mais, lorsqu’il y a coupure réseau, j’ai des doutes sur le comportement de rétablissement, y compris avec la nouvelle couche réseau (même en local).

S’il y a eu des améliorations en v18 avec la nouvelle couche réseau, j’en serais le premier ravi.

J’utilise cette nouvelle couche avec la v17r4, ça doit faire plus de 2 ans désormais. Quand ça coupe (ce à quoi on ne peut strictement rien, mais ce sera pareil pour le mail ou le navigateur), il suffit la plupart du temps d’attendre que ça reconnecte. Par exemple, il m’arrive souvent de vouloir connecter un client… en oubliant de lancer le vpn avant. Avec l’ancienne couche, quoi que je fasse, la fenêtre d’attente du client se termine invariablement par l’erreur -10002 et je dois relancer la connexion. Avec la nouvelle, si pendant cette attente je me rue sur le vpn et le lance, la connexion 4D abouti.
Capture d’écran 2020-06-05 à 10.59.25
Autrement dit, tu as le choix entre :
• ancienne couche = certitude qu’une coupure déconnectera définitivement ton client
• nouvelle = de fortes chances qu’il se reconnecte
Rien de cornélien là dedans.

Les changements d’ip sont imparables, par contre. Mais si je considère que ce que je développe en 4D client est destiné à un utilisateur confortablement installé devant un bureau et non à un nomade en train de courir les stations de métro, ce problème devient négligeable. Pour ce dernier, le serveur peut être 4D mais pas le client, du moins en l’état. Si vraiment j’ai affaire à un pov’ malheureux dont la connexion est définitivement exécrable, je prends la solution TSE, mais c’est loin d’être le cas général et il n’est pas certain que ça arrangera son problème de ligne pourrie.

Juste une remarque : ton VPN ne change rien à l’affaire. Tu es dans les mêmes conditions qu’une connexion directe.

Si vraiment c’est le cas tant mieux, mais tu es dans une version R-Release plus proche de la v18 tu n’es pas en 32 bit, etc. Bref, pas dans les mêmes conditions. Le jour où l’on pourra déployer en v18 sur la nouvelle couche réseau je verrais bien si cela fonctionne. Concernant l’IP, je ne sais pas comment cela fonctionne avec une connexion 4G par exemple, est-ce que suite à une déconnexion tu es assuré de conserver la même IP coté client ?

En tout cas, le confinement a révélé que malheureusement encore beaucoup de gens n’ont PAS une bonne connexion réseau chez eux…

Et pas besoin d’aller chercher loin (même en local) : le gars avec un ordinateur portable qui passe de salle en salle de réunion qui change de réseau Wifi à la volé et tu as ton cas d’usage typique de déconnexion… :roll_eyes:

Je sais pas, je n’ai pas bossé comme ça depuis un moment. Je te dirai, ça risque d’arriver bientôt.

Raison de plus pour les bichonner, ne pas prendre les transports pour aller au bureau est bon pour la planète et ce type d’utilisateurs ne fera qu’augmenter.

Si ce gars là fait l’effort de se lever de sa chaise et de marcher, il peut aussi faire celui de se déconnecter et se reconnecter. Ou bien il me dit clairement qu’il veut absolument enfoncer son clou, fût-ce avec un tournevis, et dans ce cas là je lui indique le prix du marteau pour qu’il arrête de me faire ch…

Sauf que ce genre de gars, c’est souvent le directeur… :grimacing:

C’est à dire celui qui signe le contrat, dont je doute qu’il y soit mentionné “vous aurez accès à 4D partout, que ce soit en haut d’un télésiège ou aux chiottes du bistrot du coin”. Mais je m’égare :wink:

On voit qu’on est vendredi… :joy:

Merci Arnaud et Manuel de m’avoir fait partager votre expérience.
On sent le vécu :scream:

Je vous résume :

  • la limite est plus la stabilité que les kilomètres, la latence ou le débit.
  • pas de réglage de “tolérance” dans 4D Server ou 4D Client
  • revoir éventuellement quelques commandes pénalisantes
  • nouvelle couche réseau pour ses capacités de reconnexion
    => pas de Citrix systématique

Pour ma part, j’ai quelques éléments plutôt favorables :

  • 4D v17.4 64 bits
  • nouvelle couche réseau
  • communication entre IP a priori stables
  • problème avec changements de réseau Wifi entre pièces
  • liaisons entre réseaux hospitaliers a priori plutôt correctes
  • pas de traitement en tâche de fond entre client et serveur

Si vraiment c’est le cas tant mieux, mais tu es dans une version R-Release plus proche de la v18 tu n’es pas en 32 bit, etc. Bref, pas dans les mêmes conditions. Le jour où l’on pourra déployer en v18 sur la nouvelle couche réseau je verrais bien si cela fonctionne

Là, je n’ai pas tout compris. La V18 ne fonctionne pas avec la nouvelle couche réseau ?

Si si, bien sûr :

ServerNet [=nouvelle couche] est automatiquement activé dans les nouvelles bases et les bases converties depuis les versions 15 et suivantes. […] la version minimale du client pour utiliser la couche ServerNet est 4D v14 R4

Je ne m’en souvenais plus mais je l’avais utilisée en v14r4, avant une migration en v17r4. Avec une base convertie tu conserves la possibilité de “switcher” la couche réseau.

Zut, je n’avais pas pensé au milieu hospitalier, l’ordi portable qui se balade sur le charriot de soins est courant :hot_face:. À moins de pouvoir en “stabiliser” l’ip (?), il n’y a guère d’autre solution que TSE à court terme et un mode déconnecté à plus long terme, je pense.