Options réseau et Client-serveur

Vous pouvez définir divers paramètres relatifs au réseau et à la communication client-serveur dans l'onglet “Options réseau” de la page Client-Serveur des Propriétés de la base (accessibles depuis 4D en mode distant et 4D Server) :

En outre, à compter de 4D Server v14 R5, une option de compatibilité vous permet d'activer ou de désactiver à tout moment l'ancienne couche réseau :

Ces paramètres sont décrits dans cette section.

Cette option permet d’indiquer si la base 4D Server doit apparaître ou non dans la liste des bases publiées dans la boîte de dialogue de connexion.

• lorsque l’option est cochée (par défaut), la base est rendue publique, elle apparaît dans la liste des bases publiées (page "Disponible").
• lorsque l’option est désélectionnée, la base n’est pas rendue publique, elle n’apparaît pas dans la liste des bases disponibles. Pour se connecter, les utilisateurs doivent saisir manuellement l’adresse de la base dans la page Personnalisée de la boîte de dialogue de connexion.

Note : Si vous modifiez ce paramètre, vous devez redémarrer la base serveur afin qu'il soit pris en compte.

Cette option permet de modifier le nom de publication d’une base publiée par 4D Server, c’est-à-dire le nom affiché dans la page de publication dynamique "Disponible" de la boîte de dialogue de connexion (cf. section Connexion à une base 4D Server). Par défaut, 4D Server utilise le nom du fichier de structure de la base. Vous pouvez saisir tout nom personnalisé.

Note : Ce paramètre n’est pas pris en compte dans le cadre des applications client-serveur personnalisées. En principe, l’application cliente se connecte directement à l’application serveur, sans passer par la boîte de dialogue de connexion. Toutefois, en cas d’erreur, cette boîte de dialogue apparaît ; dans ce cas, le nom de publication de l’application serveur est le nom de la base compilée.

Cette option permet de modifier le numéro de port TCP sur lequel 4D Server publie la base de données. Cette information est stockée dans la structure de la base et sur chaque poste client. Par défaut, le numéro de port TCP utilisé par 4D Server et 4D en mode distant est le 19813. La personnalisation de cette valeur est nécessaire lorsque vous souhaitez utiliser plusieurs applications 4D sur la même machine avec le protocole TCP ; dans ce cas, vous devez spécifier un numéro de port différent pour chaque application. Lorsque vous modifiez cette valeur depuis 4D Server ou 4D, elle est automatiquement répercutée sur tous les postes 4D connectés à la base. Pour mettre à jour les autres postes clients non connectés, il suffira, lors de leur connexion suivante, de saisir le nouveau numéro de port (précédé de deux-points) derrière l’adresse du poste serveur dans la page Personnalisée de la boîte de dialogue de connexion. Par exemple, si le nouveau numéro de port est le 19888 :

Note : Lorsque 4D Server utilise IPv4, seules les bases publiées sur le port 19813 sont visibles dans la page de publication dynamique "Disponible".

4D Server utilise plusieurs ports TCP pour les communications entre les serveurs internes et les clients :

• Serveur SQL : 19812 par défaut (modifiable via la page "SQL" des Propriétés de la base).
• Serveur d’application : 19813 par défaut (modifiable via la page "Client-serveur/Configuration" des Propriétés de la base, cf. ci-dessus).
• Serveur DB4D (serveur de base de données) : 19814 par défaut. Ce numéro de port n’est pas modifiable directement mais il s’agit toujours du numéro de port du serveur d’application + 1.
  Lorsqu’un client 4D se connecte à 4D Server, il s’adresse au port TCP du serveur d’application (19813 ou port indiqué après ':' dans l’adresse IP indiquée dans la boîte de dialogue de connexion. La connexion aux autres serveurs via leur port respectif est ensuite automatique, il n’est pas nécessaire de les préciser.
  A noter que dans le cas d'accès via un routeur ou un firewall, les trois ports TCP doivent être ouverts explicitement.

Cette option permet d'activer la fonction d'authentification unique (Single Sign On ou SSO) dans votre base 4D Server sous Windows. Lorsque vous cochez cette option, 4D se connecte de manière transparente à l'Active Directory du serveur de domaine de Windows et récupère les tokens d'authentification disponibles.

Cette option est détaillée dans la section Authentification unique (SSO) sous Windows.

Lorsque l'authentification unique est activée (cf. ci-dessus), vous devez remplir ce champ si vous souhaitez utiliser le protocole d'authentification Kerberos.

Cette option est détaillée dans la section Authentification unique (SSO) sous Windows.

Ce thermomètre permet de définir le timeout (période d’inactivité au-delà de laquelle la connexion est fermée) entre 4D Server et les postes clients qui s’y connectent. L’option Illimité élimine le timeout. Lorsque cette option est sélectionnée, le contrôle d’inactivité du client est désactivé. Lorsqu’un délai est sélectionné, le serveur mettra un terme à la connexion d’un client s’il ne reçoit pas de requête de ce dernier dans l’intervalle de temps spécifié.

Lorsque cette option est cochée, tous les postes 4D distants se connectant à la base peuvent exécuter des méthodes à distance. Ce mécanisme est détaillé dans la section Procédures stockées sur les clients.

Cette option permet d'activer le mode sécurisé pour la communication entre le poste serveur et les postes 4D distants. Cette option est détaillée dans la section Crypter les connexions client/serveur.

Ce paramétrage permet de définir globalement le mode de mise à jour de l'instance locale du dossier Resources des postes 4D connectés en cas de modification du dossier Resources de la base au cours de la session (le dossier Resources est automatiquement synchronisé sur le poste distant à chaque ouverture de session). Trois paramétrages sont proposés :

• Jamais : Le dossier Resources local n’est pas mis à jour en cours de session. La notification envoyée par le serveur est ignorée. Le dossier Resources local pourra toutefois être mis à jour manuellement via la commande Mise à jour des ressources.
• Toujours : La synchronisation du dossier Resources local est automatiquement effectuée en cours de session lorsque la notification est envoyée par le serveur.
• Demander : Lorsque la notification est envoyée par le serveur, une boîte de dialogue s’affiche sur les postes clients, signalant la modification. L’utilisateur peut accepter ou refuser la synchronisation du dossier Resources local.
  Le dossier Resources centralise les fichiers personnalisés nécessaires à l'interface de la base (fichiers de traduction, images, etc.). Des mécanismes automatiques ou manuels permettent de notifier chaque client lorsque le contenu de ce dossier a été modifié. Pour plus d'informations, reportez-vous à la section Gestion du dossier Resources.

Cette option permet de définir le mode d'ouverture de la structure de la base par les postes clients. Par défaut, le mode Lecture écriture est défini, mais vous pouvez configurer l'ouverture en mode Lecture seulement afin d'empêcher toute modification de la structure.

Cette table vous permet de définir des règles de contrôle d’accès à la base en fonction de l’adresse IP des postes 4D distants. Cette option permet de renforcer la sécurité par exemple pour des applications stratégiques.

Note : Cette table de configuration ne contrôle pas les connexions Web. 

Le fonctionnement de la table de configuration est le suivant :

• La colonne “Autoriser-Refuser” permet de sélectionner le type de règle à appliquer (Autoriser ou Refuser) à l’aide d’un pop up menu. Pour ajouter une règle d’adresses, cliquez sur le bouton Ajouter. Une nouvelle ligne apparaît dans la table. Le bouton Supprimer permet de supprimer la ligne courante.
• La colonne “Adresse IP” permet de désigner la ou les adresse(s) IP concernées par la règle. Pour spécifier une adresse, cliquez dans la colonne et saisissez l’adresse sous la forme 123.45.67.89 (format IPv4) ou 2001:0DB8:0000:85A3:0000:0000:AC1F:8001 (format IPv6).
  Vous pouvez utiliser le caractère * (étoile) pour spécifier des adresses du type “commence par”. Par exemple, 192.168.* indique toutes les adresses débutant par 192.168.
• L’application des règles s’effectue dans l’ordre d’affichage de la table. Si deux règles sont contradictoires, la priorité sera accordée à la règle située le plus haut dans le tableau.
  Vous pouvez réordonner les lignes en modifiant le tri courant (cliquez sur un en-tête de colonne pour alterner le sens de tri). Vous pouvez également déplacer des lignes par glisser-déposer.
• Pour des raisons de sécurité, seules les adresses correspondant à une règle d’autorisation explicite pourront se connecter.
  En particulier, si la table contient uniquement une ou plusieurs règle(s) de type Refuser, toutes les adresses seront refusées car aucune ne satisfera à au moins une règle. Si vous souhaitez refuser certaines adresses et autoriser toutes les autres, ajoutez une règle Autoriser * à la fin de la table. Par exemple :
  - Refuser 192.168.* (refuser toutes adresses débutant par 192.168)
  - Autoriser * (et autoriser les autres)
  Par défaut, aucune restriction de connexion n’est appliquée par 4D Server : la première ligne de la table contient le libellé Autoriser et le caractère * (toute adresse).

A compter de 4D v14 R5, les applications 4D contiennent une nouvelle couche réseau, nommée ServerNet, chargée de gérer les communications entre 4D Server et les postes 4D distants (clients). La couche ServerNet est basée sur une API moderne et robuste. De maintenance simple, elle facilitera l'implémentation des dernières technologies réseau tout en proposant un haut niveau de performances.

Du point de vue de l'utilisateur, l'usage de ServerNet est transparent. A noter toutefois que, lorsque la couche ServerNet est utilisée, le nom des bases publiées en mode sécurisé n'est plus précédé du caractère "^" comme dans l'ancienne couche réseau (cf. Crypter les connexions client/serveur).

L'ancienne couche réseau est conservée pour assurer la compatibilité des bases existantes. ServerNet est automatiquement utilisé dans les nouvelles bases.

Des options vous permettent d'activer ou de désactiver ServerNet. Pour que vos applications soient en mesure de bénéficier des futures évolutions réseau, nous vous recommandons d'activer ServerNet progressivement dans toutes vos bases.

Vous pouvez activer ou de désactiver à tout moment l'ancienne couche réseau dans votre application 4D Server. Vous pouvez utiliser :

• soit la constante Utiliser ancienne couche réseau avec la commande SET DATABASE PARAMETER,
• soit l'option Utiliser l'ancienne couche réseau dans la boîte de dialogue des Propriétés de la base (cf. Page Compatibilité) :
  

Note : Comme précisé dans son libellé, cette option est ignorée dans 4D Server version 64 bit pour OS X ; seul ServerNet peut être utilisé sur cette plate-forme. 

Par défaut, la nouvelle couche réseau serverNet est :

• automatiquement activée dans les nouvelles bases, créées avec 4D v14 R5 et suivantes,
• automatiquement désactivée dans les bases converties.

Lorsque vous activez la couche réseau ServerNet dans votre application serveur existante, seules les applications clientes compatibles pourront se connecter :

• Les applications clientes en version 15 (ou à compter de 4D v14 R4) peuvent se connecter sans modification. 
• Les applications clientes en version précédente (v14.x et toutes les releases v14 'R' précédentes) doivent au préalable être mises à jour pour pouvoir se connecter au serveur.

Si votre application fonctionne avec des clients 4D Volume Desktop fusionnés en version antérieure à la v14 R4, et si vous souhaitez utiliser, pour la mise à jour, le mécanisme automatique de 4D Server pour la distribution des applications clientes via le réseau, vous devez concevoir une stratégie de migration. Cette stratégie doit s'appuyer sur principes suivants :

• les clients non compatibles peuvent uniquement se connecter à un 4D Server utilisant l'ancienne couche réseau.
• les clients mis à jour adaptent dynamiquement leur protocole et peuvent donc se connecter à 4D Server v15 ou suivante, quelle que soit la couche réseau activée par le serveur.

Votre stratégie de migration doit donc comporter ces étapes :

1. Construisez une mise à jour de l'application cliente avec 4D v15 ou suivante.
2. Lancez 4D Server v15 ou supérieure avec le paramètre "Utiliser l'ancienne couche réseau" activé.
   Cette configuration permet à tous les clients de se connecter.
   Note : Rappelez-vous que 4D Server version 64 bits pour OS X ne prend pas en charge cette option. 
3. Déterminez une période de temps durant laquelle chaque application cliente aura eu l'occasion de se connecter et de télécharger la nouvelle version.
   Cette période peut durer une journée, une semaine ou même davantage. Dans ce mode transitoire, les "anciens" et les "nouveaux" clients se connectent en utilisant l'ancienne couche réseau.
4. Une fois que tous les clients ont été mis à jour, vous pouvez désactiver l'ancienne couche réseau et activer définitivement ServerNet sur 4D Server.

Cette stratégie est illustrée dans le schéma suivant :

Pendant le processus de migration, nous vous recommandons d'activer le fichier de diagnostic de 4D. Lorsque ce fichier est activé, 4D Server y enregistre chaque requête de mise à jour cliente, ce qui vous permet de contrôler le déroulement de l'opération. Ce fichier n'est pas activé par défaut : vous devez appeler la commande SET DATABASE PARAMETER avec le sélecteur Enreg diagnostic et la valeur 1.

Pour chaque requête de mise à jour, les informations suivantes sont conservées :

• IP du client
• version du client
• événement "Update client"

Contrôler le fichier de diagnostic est utile également après avoir activé la couche réseau ServerNet sur le serveur, afin de vous assurer que tous les clients ont été correctement mis à jour. Si un client non compatible a tenté de se connecter, le serveur aura enregistré les informations suivantes :

• IP du client
• version du client
• événement "Fail to connect"

Dans ce cas, vous pourrez par exemple décider d'effectuer une mise à jour manuelle du client.