I. Résumé ♪▲
Le timeout existe sur le 4D Client et le 4D Server. Les réglages peuvent être modifiés par les développeurs 4D . Mais à quoi sert ce timeout , et comment fonctionne-t-il exactement ?
Nous répondrons à ces interrogations en étudiant des cas concrets et des réglages différents.
La première partie de cette note technique décrit le principe de communication en Client/Server bas niveau via le protocole TCP.
La deuxième partie permet de comprendre le rôle joué par le timeout en Client/Server. Nous détaillons ce rôle par plusieurs scénarios qui reprennent des réglages différents et qui décrivent le fonctionnement du timeout du côté du 4D Client et du côté du 4D Server.
La troisième partie explique la division du travail entre le 4D Client et le 4D Server.
II. Introduction▲
Le 4D Server et le 4D Client utilisent le protocole Tcp pour communiquer via un numéro de port défini par défaut. Le port numéro 19813 est utilisé par défaut dans 4D en Client/Server en mode TCP/IP. Pour modifier ce port, il faut soit :
- modifier dans les préférences de la base (pour la future version 4D 2004) ;
- ouvrir le fichier TCP.opt avec 4D Customizer Plus et choisir ensuite le menu « Préférences » (dans les versions 4D 68 et 4D 2003).
Le 4D Client demande l'établissement d'une connexion avec le 4D Server :
si le 4D Server (ou le gestionnaire de service) refuse la connexion, celle-ci n'a pas lieu ;
si le 4D Server accepte la connexion, une liaison s'établit entre le 4D Client et le 4D Serveur.
Le principe est similaire à une communication téléphonique, l'avantage principal de ce mode est l'identification de l'émetteur et du récepteur.
III. Principe d'utilisation des « sockets » TCP en Client/Serveur▲
La connexion entre le 4D Client et le 4D Server est définie par un couple de « sockets », l'un définissant l'émetteur, l'autre le récepteur, La connexion est bidirectionnelle.
Les sockets ou « ports réservés » correspondent à des numéros de port standardisés permettant aux ordinateurs à distance de déterminer à quel port il doivent se connecter pour bénéficier d'un service de réseau particulier. De cette manière, le processus de connexion est simplifié, puisque l'émetteur et le récepteur connaissent à l'avance le port spécifique qui sera utilisé pour les données destinées à une opération déterminée.
Exemple tous les systèmes offrant le service TELNET, le proposent sur le port 23, pour 4e Dimension le port réservé par défaut est 19813.
Côté 4D Server▲
- Le 4D Server ouvre sa « socket » et l'attache sur le port 19813 (1).
- Le 4D Server écoute sa « socket » et attend des demandes de connexion de la part du 4D Client 1.
- Le 4D Server détecte la demande de connexion et une nouvelle « socket » est ouverte automatiquement (3).
- La communication est établie entre le 4D Client et le 4D Server.
- En parallèle, le 4D Server scrute en permanence le port 19813 pour voir s'il existe de nouvelles demandes de connexions (1).
Côté 4D Server▲
- Le 4D Client fait une demande de connexion sur le port 19813 (2).
- Si la demande de connexion est acceptée par le 4D Server, le 4D Client connecte sa « socket » au 4D Server et la connexion est établie (4).
- La communication est établie entre le 4D Client et le 4D Serveur.
Multiplexage▲
Le principe de Multiplexage va permettre à plusieurs process de transiter via les « sockets » du 4D Client et du 4D Serveur.
Timeout▲
Le timeout peut être réglé sur le 4D Server et sur le 4D Client :
Timeout sur le 4D Server
Il permet de modifier la valeur du délai avant déconnexion (timeout) accordé par 4D Server aux postes clients.
Timeout sur le 4D Client
Il permet de modifier la valeur du délai avant déconnexion (timeout) accordé par le poste 4D Client au poste 4D Server.
Au niveau du poste 4D Server : entre les réglages de TimeOut définis dans les fichiers d'option « .opt » et ceux des « Propriétés de la base » ce sont ces derniers qui sont pris en compte.
Au niveau du poste 4D Client : entre les réglages de TimeOut définis dans les fichiers d'option « .opt » et ceux des « Propriétés de la base » (en fait, ceux du client) ce sont ces derniers qui sont pris en compte.
IV. Réglage du « TimeOut » sur le 4D Server et sur le 4D Client▲
Côté 4D Server▲
Le réglage peut se faire dans les propriétés de la base ou en utilisant la commande : FIXER PARAMETRE BASE avec le sélecteur 13. Il permet de modifier la valeur du délai avant déconnexion « TimeOut » accordé par 4D Server aux postes clients.
Par défaut, la valeur du délai avant déconnexion utilisée par 4D Server est définie dans la page « Connexions » de la boîte de dialogue des Propriétés de la base, sur le poste serveur.
Le sélecteur TimeOut 4D Server vous permet de fixer, à l'aide du paramètre valeur, un nouveau « TimeOut » , exprimé en minutes. Cette possibilité permet en particulier d'augmenter la valeur du « TimeOut » avant l'exécution sur le poste client d'une opération bloquante et de longue durée, risquant d'entraîner une déconnexion ; par exemple, l'impression d'un grand nombre de pages.
Côté 4D Client▲
Le réglage peut se faire dans les propriétés de la base ou en utilisant la commande : FIXER PARAMETRE BASE avec le sélecteur 14. Il permet de modifier la valeur du délai avant déconnexion « TimeOut » accordé par le poste 4D Client au poste 4D Serveur.
Par défaut, la valeur du délai avant déconnexion utilisée par 4D Client est définie dans la page « Connexions » de la boîte de dialogue des Propriétés de la base, sur le poste client.
Important
À partir de la version 2003.3 de 4e Dimension, on peut fixer les paramètres d'utilisation CPU localement sur le 4D Client. La valeur est modifiée dynamiquement sur le poste client et envoyée au serveur. Donc chaque poste client pourra avoir ces réglages spécifiques, si la commande FIXER PARAMETRE BASE est appelée.
Dans les versions précédentes, la requête était juste envoyée au serveur qui modifiait les valeurs au niveau de la structure, mais ne modifiait pas les valeurs en local. Il fallait donc quitter et se reconnecter avec le client pour bénéficier des paramètres.
V. Scénario avec différents « TimeOut » sur le 4D Client et 4D Serveur▲
Pour bien expliquer le principe de fonctionnement du « TimeOut » en Client/Serveur, Nous allons travailler sur plusieurs scénarios.
Important : Avant de traiter différents cas, il faut préciser que quand tout marche bien, le « TimeOut » n'est jamais atteint ni du côté Server, ni du côté Client.
Le traitement est très long du côté du 4D Client▲
Quand une action bloquante (traitement très long) est lancée côté 4D Client, celui-ci prévient le 4D Server qu'il ne va pas répondre pendant un certain temps : en clair il envoie un « TimeOut » très long au 4D Serveur. Ce « TimeOut » affecte tous les process pour cette connexion. Ce « TimeOut » est initialisé à la prochaine requête renvoyée par le Client.
Quand le 4D Client devient trop long au niveau réseau, le 4D Server atteint son « TimeOut » interne ; Il envoie alors sa valeur de « TimeOut » au 4D Client qui la prend en compte pour cette connexion (si il est toujours à l'écoute). Donc le 4D Server et 4D Client se retrouvent avec la même valeur de « TimeOut » des deux côtés. Le 4D Server coupe la connexion.
1er Cas : timeout du 4D Server est inférieur au timeout du 4D Client▲
Soit le cas de figure suivant :
4D Server avec un « TimeOut » de 2 minutes
4D Client 1 avec un « TimeOut » de 5 minutes (dans les préférences locales)
4D Client 2 avec un « TimeOut » de 3 minutes (dans les préférences locales)
Résultat des tests :
Si nous exécutons un traitement lourd sur le 4D Client qui dépasse 2 minutes et qui l'empêche de communiquer avec le 4D Server, les deux 4D Clients sont déconnectés après 2 minutes, ce qui correspond au timeout du 4D Server.
Explication :
Si le traitement lourd se fait sur le 4D Client 1 et qu'il dépasse 2 minutes :
- le 4D Client envoie un timeout très long au 4D Server (1) ;
- le 4D Server atteint son timeout interne (2 minutes) ;
- le 4D Server envoie son timeout au 4D Client 1 et au 4D Client 2 (2) et (3) ;
- le 4D Server et les deux 4D Clients se retrouvent avec la même valeur des deux côtés et la connexion est immédiatement coupée.
2e Cas : timeout du 4D Server est supérieur au timeout du 4D Client▲
Soit le cas de figure suivant :
4D Server avec un « TimeOut » de 5 minutes
4D Client 1 avec un « TimeOut » de 3 minutes (dans les préférences locales)
4D Client 2 avec un « TimeOut » de 2 minutes (dans les préférences locales)
Résultat des tests :
Si nous exécutons un traitement lourd sur le 4D Client qui dépasse 5 minutes et qui l'empêche de communiquer avec le 4D Server. Les deux 4D Clients sont déconnectés après 5 minutes, ce qui correspond au timeout du 4D Server.
Explication :
Si le traitement lourd se fait sur le 4D Client 1 et qu'il dépasse 5 minutes :
- le 4D Client envoie un timeout très long au 4D Server (1) ;
- le 4D Server atteint son timeout interne (5 minutes) ;
- le 4D Server envoie son timeout au 4D Client 1 et au 4D Client 2 (2) et (3) ;
- le 4D Server et les deux 4D Clients se retrouvent avec la même valeur des deux côtés et la connexion est immédiatement coupée.
Le traitement est très long du côté du 4D Server▲
Quand le Server commence à devenir trop long au niveau du réseau, tous les Clients peuvent potentiellement atteindre leur « TimeOut » local.
Dans ce cas, chaque 4D Client envoie au 4D Server son propre « TimeOut ». Le 4D Serveur, s'il est toujours à l'écoute, prend en compte ces nouvelles valeurs individuellement pour chaque connexion. Si le 4D Server ne répond pas pendant le nouveau « TimeOut », la connexion est coupée et l'erreur -10002 est produite sur le 4D Client.
1er Cas : timeout du 4D Server est supérieur au timeout du 4D Client▲
Soit le cas de figure suivant :
4D Server avec un « TimeOut » de 5 minutes
4D Client 1 avec un « TimeOut » de 3 minutes (dans les préférences locales)
4D Client 2 avec un « TimeOut » de 2 minutes (dans les préférences locales)
Résultat des tests :
Si nous exécutons un traitement lourd sur le 4D Server qui dépasse 5 minutes et qui l'empêche de communiquer avec le 4D Client, le 4D Client 2 est déconnecté au bout de 2 minutes et le 4D Client 1 est déconnecté au bout de 3 minutes.
Explication :
Le traitement lourd est réalisé sur 4D Server (plus de 5 minutes) :
- le 4D Client 2 atteint son timeout (2 minutes) ;
- le 4D Client 2 envoie au 4D Server son timeout local (2 minutes) (1) ;
- le 4D Server reçoit le timeout du 4D Client et coupe la connexion (erreur -10002 sur le 4D Client 2 (2)) ;
- le 4D Client 1 atteint son timeout (3 minutes) ;
- le 4D Client 1 envoie au 4D Server son timeout local (3 minutes) (3) ;
- le 4D Server reçoit le timeout du 4D Client et coup la connexion (erreur -10002 sur le 4D Client 1 (4)).
2e Cas : timeout du 4D Server est inférieur au timeout du 4D Client▲
Soit le cas de figure suivant :
- 4D Server avec un « TimeOut » de 2 minutes
- 4D Client 1 avec un « TimeOut » de 5 minutes (dans les préférences locales)
- 4D Client 2 avec un « TimeOut » de 3 minutes (dans les préférences locales)
Résultat des tests :
Si nous exécutons un traitement lourd sur le 4D Server qui dépasse 5 minutes et qui l'empêche de communiquer avec le 4D Client, le 4D Client 2 est déconnecté au bout de 3 minutes et le 4D Client 1 est déconnecté au bout de 5 minutes.
Explication :
Le traitement lourd est réalisé sur 4D Server (plus de 5 minutes) :
- le 4D Client 2 atteint son timeout (2 minutes) ;
- le 4D Client 2 envoie au 4D Server son timeout local (2 minutes) (1) ;
- le 4D Server reçoit le timeout du 4D Client et coupe la connexion (erreur -10002 sur le 4D Client 2 (2)) ;
- le 4D Client 1 atteint son timeout (5 minutes) ;
- le 4D Client 1 envoie au 4D Server son timeout local (5 minutes) (3) ;
- le 4D Server reçoit le timeout du 4D Client et coupe la connexion (erreur -10002 sur le 4D Client 1 (4)).
VI. Le 4D Server et le 4D Client parlent le même langage▲
Dans la plupart des architectures client/serveur, l'application cliente et l'application Server sont deux produits séparés, nécessitant une couche de communication pour pouvoir se comprendre entre eux. Avec 4D Serveur, l'architecture client/Server est entièrement intégrée. 4D Server et 4D Client sont deux applications qui partagent la même structure et communiquent directement.
Comme 4D Server et 4D Client parlent la même langue, il est inutile de traduire les requêtes. La division du travail entre le client et le Server est transparente et est gérée automatiquement par 4D Server.
La division du travail est organisée de telle manière qu'à une requête est associée une réponse. Comme vous pouvez le constater dans le schéma ci-dessus, le client est chargé de traiter les tâches suivantes :
- Requêtes : 4D Client envoie des requêtes à 4D Serveur. Ces requêtes peuvent être construites à l'aide des éditeurs intégrés, tels que l'éditeur de recherches et l'éditeur de tris, ou à l'aide du langage intégré de 4e Dimension. 4D Client dispose d'éditeurs dans lesquels les méthodes peuvent être créées et modifiées. Il gère également les composantes des méthodes telles que les variables et les tableaux ;
- Réception des réponses : 4D Client reçoit des réponses de 4D Server et en informe l'utilisateur par l'intermédiaire de l'interface utilisateur (des enregistrements différents sont affichés dans un formulaire, etc.). Par exemple, si le client recherche tous les enregistrements dont le nom est « Smith », 4D Client reçoit les enregistrements de 4D Server et les affiche dans un formulaire.
Le Server est chargé de traiter les tâches suivantes :
- Gestion des accès : 4D Server gère toutes les connexions simultanées et les process créés par les clients. Cette gestion tire parti de l'architecture multitâche de 4D Serveur ;
- Objets de structure et de données : 4D Server stocke et gère tous les objets de structure et de données, y compris les champs, les enregistrements, les formulaires, les méthodes, les barres de menus et les listes ;
- Au niveau de la requête : Lorsque 4D Client envoie à 4D Server une requête, telle qu'une recherche ou un tri, 4D Client envoie une description de l'opération de recherche ou de tri en utilisant la même structure interne que 4D Server.
VII. Rappel du principe de fonctionnement du protocole TCP▲
Le protocole TCP▲
En préambule, il est bon de faire un rappel sur le modèle OSI et les 7 couches qui le composent :
- couche 7 : application (Niveau Application) ;
- couche 6 : présentation (Niveau présentation) ;
- couche 5 : session (Niveau session) ;
- couche 4 : transport (Niveau message) ;
- couche 3 : réseau (Niveau paquet) ;
- couche 2 : liaison de donnée (Niveau trame) ;
- couche 1 : physique (Niveau physique).
Le rôle du modèle OSI consiste à standardiser la communication entre les machines afin que différents constructeurs puissent mettre au point des produits (logiciels ou matériels) compatibles (pour peu qu'ils respectent scrupuleusement le modèle OSI).
Le protocole TCP est situé au niveau 4 (couche transport). Les couches réseau sont localisées entre les niveaux 1 à 4. Le composant réseau est situé au niveau 5.
Le protocole de contrôle de transmission ou TCP (Transmission Control Protocol) vérifie donc le bon acheminement d'un paquet IP. Cela se fait de la façon suivante. Admettons que A veuille transmettre un paquet IP à B :
- A envoie son paquet IP à B ;
- tant que A ne recevra pas un accusé de réception de B lui indiquant que ce dernier a bien reçu le paquet IP dans son intégrité (grâce à l'en-tête de total de contrôle), il renverra à intervalles réguliers le même paquet IP à B ;
- A n'arrêtera d'envoyer ce paquet qu'à la confirmation de B ;
- B agira ensuite de même s'il doit transmettre le paquet plus loin ;
- si B constate que le paquet qu'il a reçu est abimé, il n'enverra pas de confirmation, de manière à ce que A lui renvoie un paquet « neuf ».
IP (Internet Protocol)▲
TCP découpe les données en paquets dont il garantit la livraison, mais c'est en fait IP qui effectue la livraison proprement dite. Au niveau de la couche IP, chaque paquet entrant ou sortant correspond à un datagramme. La couche IP ajoute les champs suivants à l'en-tête du paquet.
|
Champ |
Utilité |
|---|---|
|
Adresse source IP |
Identifie l'émetteur du datagramme. |
|
Adresse de destination IP |
Identifie le récepteur du datagramme. |
|
Protocole |
Signale à l'IP du récepteur de passer le paquet à TCP. |
|
Somme de contrôle |
Permet de vérifier l'intégrité du paquet reçu. |
|
TTL (Time to Live). Durée de vie maximale du datagramme. Cela évite d'avoir des paquets qui circulent indéfiniment sur un interréseau. Chaque routeur qui laisse passer le paquet décrémente de 1 le TTL. Le TTL par défaut sous Windows 2000 est de 128 secondes. |
La fonction de multiplexage▲
TCP permet d'effectuer une tâche importante : le multiplexage/démultiplexage, c'est-à-dire faire transiter sur une même ligne des données provenant d'applications diverses ou en d'autres mots mettre en série des informations arrivant en parallèle.
Ces opérations sont réalisées grâce au concept de ports (ou sockets), c'est-à-dire un numéro associé à un type d'application, qui, combiné à une adresse IP, permet de déterminer de façon unique une application qui tourne sur une machine donnée.
VIII. Conclusion▲
Cette note technique permet d'expliquer de façon détaillée le protocole de communication TCP et son rôle dans l'établissement d'une connexion entre 4D Server et 1 ou plusieurs 4D Clients.