Processus de transmission des messages SC_CALLBACK_REG entre un client et le serveur

Un client initie une connexion en ouvrant une connexion TCP sur l'adresse IP et le numéro de port du serveur. Une fois la connexion TCP établie et prête pour la lecture, le client doit envoyer son message de connexion. Il doit s'agir d'un message SC_CALLBACK_REG correctement formaté qui n'est ni suivi ni précédé d'octets supplémentaires.

Une fois tous les octets émis, le client doit rester connecté pour recevoir une réponse du client. Si ce dernier ne formate pas le message correctement, le serveur n'enregistre pas le client et lui transmet un message d'erreur. Si le client ferme la connexion de prise avant que le serveur n'envoie sa réponse, ce dernier enregistre le client comme d'habitude.

Un client peut contacter le serveur à tout moment. Chaque fois qu'un client contacte le serveur, il doit envoyer un message SC_CALLBACK_REG. Si le serveur reçoit un message malformé, en dérangement ou invalide, il renvoie un message d'erreur au client.

Un client ne peut pas transmettre un message ADD_EVENTS, REMOVE_EVENTS ou REMOVE_CLIENT avant d'avoir envoyé un message ADD_CLIENT. Un client ne peut pas transmettre un message REMOVE_CLIENT avant d'avoir envoyé un message ADD_CLIENT .

Si un client envoie un message ADD_CLIENT alors qu'il est déjà connecté, le serveur peut supporter ce message. Dans cette situation, le serveur remplace la connexion client antérieure par la nouvelle qui est spécifiée dans le second message ADD_CLIENT.

Mais en règle générale, un client se connecte une seule fois au serveur par l'envoi d'un message ADD_CLIENT. De même, il se déconnecte une seule fois en envoyant au serveur un message REMOVE_CLIENT. Le protocole CRNP offre une plus grande souplesse aux clients qui doivent modifier de façon dynamique leur liste de types d'événements.

Contenu d'un message SC_CALLBACK_REG

Chaque message ADD_CLIENT, ADD_EVENTS et REMOVE_EVENTS contient une liste d'événements. Le tableau indiqué ci-dessous présente les types d'événements que le protocole CRNP accepte, y compris les paires nom/valeurs requises.

Si un client

• Envoie un message REMOVE_EVENTS spécifiant un ou plusieurs types d'événements auxquels le client ne s'est pas précédemment connecté, ou

• Se connecte deux fois au même type d'événements,