IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Windows Discussion :

Concevoir une API pour client / serveur en utilisant un IPC


Sujet :

Windows

  1. #1
    Membre habitué
    Homme Profil pro
    Inscrit en
    Avril 2004
    Messages
    340
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Avril 2004
    Messages : 340
    Points : 177
    Points
    177
    Par défaut Concevoir une API pour client / serveur en utilisant un IPC
    Bonjour

    Je dois porter un code UNIX utilisant AF_Unix sous Windows, pour faire une communication "locale" (même ordinateur, ou ordinateur distant). Une utilisation classique de l'API est 20, 30, voire 50 clients.

    La discussion que je désire démarrer est pour savoir si mes choix sont corrects, et si non, quels sont vos recommandations. Je n'ai pas énormément d'expérience concernant l'architecture client/serveur, mais j'ai quand même déjà écrit deux client / serveur utilisant les tubes nommés et la mémoire partagée. Maintenant, je désire connaître le meilleur design pour les besoin de l'API ci-dessus.

    Voici mes questions et notes :


    1) Choix du design de l'IPC

    J'ai cherché sur internet (stackoverflow, ou [1]) et apparemment, ce qui semble le plus proche de AF_UNIX sous Windows sont les tubes nommés. Est-ce un bon choix ?

    2) Modes I/O

    Si les tubes nommés sont un choix correct, il y a plusieurs modes possibles :

    a) Synchrones (bloquant ou non)
    b) Overlapped asynchrone
    c) les "Completion Routine"

    Je pense que a) n'est pas le meilleurs.

    Pour b) MSDN a une implémentation [2], mais il me semble qu'il y a un hic. Dans la description, il est indiqué : "Because the same event object is used for read, write, and connect operations for each instance, there is no way to know which operation's completion caused the event to be set to the signaled state for simultaneous operations using the same pipe instance." Ne pas savoir si on a un read ou un write me semble gênant.

    Est-ce que c) est un bon choix ?

    3) modèles de notification

    Pour gérer les notifications, (client qui se connecte, message qui est reçu), il dépend du choix du mode pour l'I/O. Si c) est choisi, je pense qu'un des 2 modes suivant peut être utilisé :

    a) WaitForMultipleObjectsEx
    b) les I/O Completion Ports

    J'ai lu sur stackoverflow ou [1] que les I/O Completion Ports sont conçus pour des client/serveur avec beaucoup de charge, avec plusieurs centaines voire milliers de clients (mes besoins sont de ~50 clients, peut-être un peu plus. De plus, il ajoute un peu d'overhead s'il y a peu de clients, et semble plutôt difficile à implémenter correctement.

    Quels seraient vos conseils pour ce choix ?

    J'arrête mes questions et attends vos conseils avant de commencer à écrire le code

    merci

    [1] http://tinyclouds.org/iocp-links.html
    [2] https://msdn.microsoft.com/fr-fr/lib...(v=vs.85).aspx
    L'Opus attire les Prélats

  2. #2
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 518
    Points
    41 518
    Par défaut
    Je ne peux pas trop t'aider là-dessus, hélas.

    Par contre, pour les tubes nommés en Asynchrone, peut-être pourrais-tu utiliser des paires de tubes, un pour les transferts dans chaque sens?
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  3. #3
    Membre habitué
    Homme Profil pro
    Inscrit en
    Avril 2004
    Messages
    340
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Avril 2004
    Messages : 340
    Points : 177
    Points
    177
    Par défaut
    si j'utilise des tubes nommés en duplex, il n'y a pas de problèmes (on les crée avec PIPE_ACCESS_DUPLEX)
    L'Opus attire les Prélats

  4. #4
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 518
    Points
    41 518
    Par défaut
    Je voulais dire pour résoudre la possible gène de "ne pas savoir si c'est un read ou un write".
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  5. #5
    Membre habitué
    Homme Profil pro
    Inscrit en
    Avril 2004
    Messages
    340
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Avril 2004
    Messages : 340
    Points : 177
    Points
    177
    Par défaut
    ha, ok, je n'avais pas compris
    merci
    L'Opus attire les Prélats

Discussions similaires

  1. Conseils pour une application Java ( client/serveur )
    Par Jose.N70 dans le forum Débuter avec Java
    Réponses: 7
    Dernier message: 01/08/2012, 17h42
  2. Réponses: 1
    Dernier message: 22/02/2012, 16h41
  3. Réponses: 10
    Dernier message: 12/10/2007, 15h02
  4. Compiler une API pour serveur Web IIS
    Par [DreaMs] dans le forum API, COM et SDKs
    Réponses: 4
    Dernier message: 05/10/2007, 10h24
  5. Réponses: 36
    Dernier message: 13/05/2004, 19h22

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo