Developpez.com - 4D
X

Choisissez d'abord la catégorieensuite la rubrique :


Protocole Tcp/IP et TimeOut en Client/Server

Date de publication : Juin 2004

Par Aziz ELGHOMARI (Directeur Support Technique 4D SA)
 


I. Résumé
II. Introduction
III. Principe d'utilisation des "sockets" TCP en Client/Serveur
Côté 4D Server
Côté 4D Server
Multiplexage
Timeout
IV. Réglage du "TimeOut" sur le 4D Server et sur le 4D Client
Côté 4D Server
Côté 4D Client
V. Scénario avec différents "TimeOut" sur le 4D Client et 4D Serveur
Le traitement est très long du côté du 4D Client
1er Cas : timeout du 4D Server est inférieur au timeout du 4D Client
2ème Cas : timeout du 4D Server est supérieur au timeout du 4D Client
Le traitement est très long du côté du 4D Server
1er Cas : timeout du 4D Server est supérieur au timeout du 4D Client
2ème Cas : timeout du 4D Server est inférieur au timeout du 4D Client
VI. Le 4D Server et le 4D Client parlent le même langage
VII. Rappel du principe de fonctionnement du protocole TCP
Le protocole TCP
IP (Internet Protocol)
La fonction de multiplexage
VIII. Conclusion


I. Résumé

Le timeout existe sur le 4D Client et le 4D Server. Les réglages peuvent être modifiés par les developpeurs 4D . Mais à quoi sert ce timeout , et comment fonctionne-t-il exactement ?

Nous répondrons à ces interrogation 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

Pictures 0604x0384



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 4ème 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.

warning Important
A partir de la version 2003.3 de 4ème 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.

warning 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é 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 coté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)

Pictures 0604x0368



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.

2ème 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)

Pictures 0604x0372



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)

Pictures 0605x0326



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)).

2ème 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)

Pictures 0605x0321



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.

Pictures 0526x0280



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 4ème 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 multi-tâ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.

Pictures 0230x0129



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'un connexion entre 4D Server et 1 ou plusieurs 4D Clients.

__________________________________________________
Copyright © 1985-2009 4D SA - Tous droits réservés
Tous les efforts ont été faits pour que le contenu de cette note technique présente le maximum de fiabilité possible.
Néanmoins, les différents éléments composant cette note technique, et le cas échéant, le code, sont fournis sans garantie d'aucune sorte. L'auteur et 4D S.A. déclinent donc toute responsabilité quant à l'utilisation qui pourrait être faite de ces éléments, tant à l'égard de leurs utilisateurs que des tiers.
Les informations contenues dans ce document peuvent faire l'objet de modifications sans préavis et ne sauraient en aucune manière engager 4D SA. La fourniture du logiciel décrit dans ce document est régie par un octroi de licence dont les termes sont précisés par ailleurs dans la licence électronique figurant sur le support du Logiciel et de la Documentation afférente. Le logiciel et sa documentation ne peuvent être utilisés, copiés ou reproduits sur quelque support que ce soit et de quelque manière que ce soit, que conformément aux termes de cette licence.
Aucune partie de ce document ne peut être reproduite ou recopiée de quelque manière que ce soit, électronique ou mécanique, y compris par photocopie, enregistrement, archivage ou tout autre procédé de stockage, de traitement et de récupération d'informations, pour d'autres buts que l'usage personnel de l'acheteur, et ce exclusivement aux conditions contractuelles, sans la permission explicite de 4D SA.
4D, 4D Calc, 4D Draw, 4D Write, 4D Insider, 4ème Dimension ®, 4D Server, 4D Compiler ainsi que les logos 4e Dimension, sont des marques enregistrées de 4D SA.
Windows,Windows NT,Win 32s et Microsoft sont des marques enregistrées de Microsoft Corporation.
Apple, Macintosh, Power Macintosh, LaserWriter, ImageWriter, QuickTime sont des marques enregistrées ou des noms commerciaux de Apple Computer,Inc.
Mac2Win Software Copyright © 1990-2002 est un produit de Altura Software,Inc.
4D Write contient des éléments de "MacLink Plus file translation", un produit de DataViz, Inc,55 Corporate drive,Trumbull,CT,USA.
XTND Copyright 1992-2002 © 4D SA. Tous droits réservés.
XTND Technology Copyright 1989-2002 © Claris Corporation.. Tous droits réservés ACROBAT © Copyright 1987-2002, Secret Commercial Adobe Systems Inc.Tous droits réservés. ACROBAT est une marque enregistrée d'Adobe Systems Inc.
Tous les autres noms de produits ou appellations sont des marques déposées ou des noms commerciaux appartenant à leurs propriétaires respectifs.
__________________________________________________
 



Valid XHTML 1.1!Valid CSS!

Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur. La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.
Contacter le responsable de la rubrique 4D