Dans un système client-serveur, est-il considéré comme une bonne architecture pour une méthode de serveur de "demander au client" pour plus d'informations? Si oui, quelle est la meilleure façon de concevoir un tel scénario? Y a-t-il un "modèle" pour cela? Par exemple, supposons que l'utilisateur final sélectionne un ensemble d'enregistrements à supprimer dans l'interface utilisateur du client, puis le client effectue un appel de suppression d'enregistrements sur le serveur avec l'ensemble d'enregistrements en tant que paramètre. Ensuite, le serveur trouve un sous-ensemble de ces enregistrements qui sont "spéciaux" d'une certaine manière et doivent donc être confirmés par l'utilisateur. Est-il approprié que le serveur "rappelle" le client à une méthode appelée "confirmer les enregistrements" tout en continuant l'appel original du client au serveur? Et qu'en est-il des appels de serveur plus complexes qui pourraient nécessiter un long dialogue entre le serveur et le client?Serveur demandant au client des informations?
Répondre
Un rappel comme qui inverse le rôle du client et le serveur. Dans beaucoup de ces types d'architectures, le client n'a pas la capacité d'écouter les demandes. Si c'est le cas, vous commencez à regarder le type de système P2P. Peut-être que quelque chose comme ça pourrait fonctionner. Par conséquent, le premier appel à deleteRecords renvoie une liste de ces enregistrements spéciaux qui doivent être supprimés explicitement. J'espère que cela t'aides.
Une sorte de réponse qui dit "Les enregistrements x, y et z n'ont pas été supprimés, essayez de nouveau avec I_RELLY_WANT_TO réglé pour les supprimer" me semblerait une solution raisonnable.
Motif général; ne demandez pas, faites des choses et ne retournez pas, laissez le client décider quoi faire ensuite. Cela pourrait être fait dans le contexte d'une connexion persistante en tant que forme de dialogue.
Pas vraiment mon champ si ... ajouter 64mg NaCl
Je pense que ce genre d'arrangement est très bien. Rien n'empêche le serveur de répondre avec une requête au client pour plus d'informations et pour le client de le fournir. Tant que la connexion par socket est ouverte, vous pouvez librement envoyer des messages d'avant en arrière.
J'ai vu un arrangement où le client a envoyé un message au serveur et après cela n'a pas fait beaucoup plus qu'une petite couche au-dessus de stdin/out et le système de fichiers sur la machine locale comme serveur contrôlé il. Cela a fonctionné très bien et était très rapide.
Le client envoie une liste de fichiers à supprimer, n'est-ce pas? Laissez simplement le serveur répondre avec une liste de statuts de réussite, indiquant quel fichier a été supprimé, lequel ne l'était pas, et, peut-être, pourquoi il n'a pas été supprimé (n'existe pas, pas de permission, etc.). Si le cas courant est que tous les fichiers sont supprimés correctement, démarrez éventuellement la réponse avec un champ d'état indiquant si tous les fichiers ont été supprimés ou si le client doit réellement évaluer les codes d'état pour voir comment l'opération a été supprimée. disparu. Avec cette réponse, le client devrait être capable de mettre à jour sa vue sur l'état du serveur, au moins en ce qui concerne les fichiers qui ont été sélectionnés pour la suppression (par exemple, supprimer de l'interface utilisateur les fichiers qui ont été supprimés avec succès , mais aussi ceux qui n'existaient plus, peut-être aussi indiquer les fichiers que le serveur n'a pas pu supprimer en raison d'une autorisation manquante en conséquence).