Conversation client/serveur - est-ce que je me trompe?

Question

J'ai une application client/serveur que j'ai faite en utilisant des sockets. La chose est, quand j'envoie une commande demandant des informations et attendre une réponse, je bloque jusqu'à ce que la réponse arrive. Cela rend plus difficile la mise en œuvre de la requête/réponse bidirecional. Permettez-moi d'expliquer à l'aide d'un exemple: Le client peut lister les fichiers dans un répertoire du serveur, donc je fais someting comme ça dans le code:

Code client: 1- commande Envoyer la demande: LS/ 2- Blocs en attendant le LS responde. 3- Obtenez la liste des fichiers.

La raison pour laquelle j'ai fait cela est que le client peut avoir à transférer un fichier, donc je le fais: 1- Envoyer la demande de transfert d'un fichier. 2- Blocs sur read() en attente de voir si le serveur accepte 3- Seulement si c'est le cas, envoyez le fichier.

Donc, c'était bien jusqu'à ce que je devais ajouter au serveur la possibilité de demander n'importe quoi. Dans mon code, le client peut demander n'importe quoi et se faire bloquer en attendant une réponse. Le serveur peut alors envoyer toute commande de requête qui n'aura aucun sens pour la réponse que le client attend. Cela viderait la conversation.

Une résolution que je pensais est de ne jamais bloquer pour une réponse. Je voudrais envoyer une commande de demande, puis revenez pour attendre n'importe quelle demande ou réponse du serveur, si une réponse arrive, je voudrais envoyer le fichier. Donc la chose est que je dois ajouter comme un ID dans chaque paire de demande/réponse pour savoir quelle réponse est pour quelle demande? Post-scriptum: Je suis assez perdu dans la façon de concevoir une conversation en réseau entre les hôtes et n'ai jamais lu un livre sur les modèles de conception pour les applications réseau.

PS2: dsl mon mauvais anglais;)

Answer 1

La chose que vous cherchez est un niveau d'application protocol entre le serveur et les clients. Pour votre cas particulier, le plus simple est que le serveur dise à l'avance ce qu'il va envoyer ensuite. Dites, mettez un type de message octet devant le message. Dites 0 signifie demande, 1 signifie réponse, etc. Collez cela dans une déclaration switch et vous avez terminé.

C'est une bonne idée d'inclure également la longueur du message dans cet en-tête, de sorte que le code de réception sache combien d'octets il faut récupérer du réseau pour obtenir un message complet.