TCP/IP convient très bien surtout grâce à sa robustesse. UDP est moins sûr car les datagrammes peuvent se perdre sans remontée d'erreur, ou arriver en désordre, même si ces cas sont très rares sur un réseau stable et non sursaturé.
Ce qu'il faut déjà c'est définir précisément plusieurs points :
1)
il y a-t-il plusieurs clients ? Si oui, il faut les identifier, éventuellement de façon certaine (pour éviter que n'importe qui "impersonnifie" un client légitime avec son portable et s'amuse à mettre le dawa dans l'usine). Si multiplicité de clients, quelle synchronisation entre eux (client A envoie des ordres, et au beau milieu client B demande le reboot) ?
2) il faut définir un organigramme précis de tous les échanges possibles et par là définir un protocole strict avec des états clairement identifiés et des timeouts réalistes. On en déduit les conditions d'erreur et leur traitement (je suis dans tel état et je reçois ceci qui n'est pas prévu ou je ne reçois rien alors que je devrais ; que dois-je faire ?)
Un protocole de communication entre deux entités, c'est la définition stricte des interactions possibles entre deux machines à état (des
automates finis déterministes), virtuelles (papier) dans un premier temps, mais qui se concrétise peu à peu au fur et à mesure que tous les détails sont précisés et entrent en jeu (ici ça signifie deux programmes, mais c'est la même démarche entre deux automates mécaniques). Tout ça implique donc l'identification des conditions d'erreur et la définition explicite de leur traitement.
Ce que j'écris peut sembler un étalage de grands mots pour décrire quelque chose de relativement simple, mais sans une approche rigoureuse, on obtient un machin spaguettifié qui ne fonctionne pas correctement dans tous les cas.
Pour reprendre les points de ton message,
à ceci près de l'éventuelle multiplicité de clients :
A) les points 1., 2. et 3. sont des ordres particuliers (leur séquencement est figé) qui concluent l'envoi des "X ordres" déjà envoyés. A chaque étape, envoi d'un message ACK (accusé de réception) pour signifier que l'ordre a été bien reçu, puis d'un autre signifiant que l'ordre a bien été exécuté. Si problème, prévoir la gestion d'erreur. Comme TCP est fiable, si un TCPSend ne renvoie pas une erreur, c'est que le serveur l'a bien reçu en intégrité ; il n'y a donc pas lieu de prévoir un ACK sur réception d'un ordre quelconque. Pour la mise au point on peut l'afficher temporairement dans une console locale pour matérialiser la réception, comme mon exemple le fait.
B) au terme de cette action A) globale (à détailler plus loin), le pgm serveur se termine et se se relancera pour prévenir qu'il a bien [re]booté, qu'il a bien [re]lancé ACD puis IPBX. Du coup, on peut mettre cette partie au début du pgm serveur car tout commence par un [re]boot du serveur, lancement d'ACD puis de IPBX et acceptation de connexion du client. On n'a besoin que d'un pgm serveur qui fait tout ça. Mon exemple montre qu'on peut envoyer et recevoir avec la même liaison.
C) Au vu de ça, le client établit une connexion avec le serveur, reçoit une sequence Boot_OK, ACD_OK, IPBX_OK (ou une étape pas_OK et erreur), envoie sa séquence de "X ordres", ses ordres de tuer ACD, puis IPBX, puis reboot. Au terme de la réception d'ACK signifiant que toutes ces étapes se sont bien déroulées, il se relance (car la liaison va être coupée lors du reboot du serveur) et c'est tout, on reboucle sur C).
Il n'y a donc pas "d'inversion client/serveur". C'est juste que le début du protocole impose l'envoi de messages par le serveur vers le client, ce qui revient à dire en gros, "je suis né, tous mes organes sont fonctionnels, tu peux y aller papa, dis-moi quoi faire".
C'est à toi maintenant de voir si cette description grossière s'applique bien à ton cas.
La cryptographie d'aujourd'hui c'est le taquin plus l'électricité.
) pour lui dire que cela s'est bien passé (ou pas)
