Discussion :

[tayky]

Bonjour à tous,
Je suis en stage et dois réviser le système de communication entre les processus de notre suite d'applications.
Actuellement, nous utilisons les sockets mais malheureusement nous avons besoin de tester d'autres technos car les résultats ne sont pas parfaits.
Nous avons un serveur qui est en C++ et qui doit transmettre des infos à des applications WPF/C#.
Ce ne sont pas des grosses informations en mémoire mais super importante pour les process c#.
Et si l'une des applications c# vient à être killé le serveur ne doit pas être perturbé.

J'ai vue que le file mapping semble être la meilleur solution sous windows ; mais clairement malgré mes différentes recherches je ne parviens pas a me faire un simple code petit serveur/client.

Quelqu'un aurait-il des explications/simple code d'exemple ?

Je vous remercie par avance.
tayky

[Médinoc]

Je ne suis pas sûr qu'une mémoire partagée soit la meilleure solution, mais ce n'est pas à moi de juger.

Pour utiliser un minimum confortablement les File Mappings en C#, il faut .Net 4.0 ou supérieur (et donc, Visual Studio 2010 ou supérieur): On utilise la classe System.IO.MemoryMappedFile.

[tayky]

Merci de ta réponse
Qu'est-ce qui serait selon toi le plus judicieux ?
Pour te décrire le processus on a un serveur qui récupère des entré clavier et qui les transmet en temps réel à une application qui a le focus pour l'utilisateur.
Ce dernier peu effectuer des actions au clavier côté c++ et les envoyer directement à l'application focusé en c#.
On reste sur des transfères de quelques octets.
Le problème actuellement que l'on rencontre avec les sockets c'est quand le client ne répond plus pour une raison x le serveur est perturbé car il n'a pas de réponse de ce dernier.
J'ai bien pensé utiliser les sockets avec UDP mais je ne sais pas si c'est conseillé.

Je suis ouvert à toutes solution fiable et rapide
Si quelqu'un a un code c++ utilisant les bases du file mapping je suis preneur

ps: c'est pas un clavier ordinaire c'est pour ça qu'il il y a besoin d'un traitement particulier .


Merci d'avance
tayky

[Jipété]

Le problème actuellement que l'on rencontre avec les sockets c'est quand le client ne répond plus pour une raison x le serveur est perturbé car il n'a pas de réponse de ce dernier.

Oh chouchou, le serveur est perturbé, il va nous faire sa petite dépression, faut vite lui faire un calinou,

Et ça, ça veut juste dire que le code qui tourne sur le serveur est mal écrit !
Car il peut y avoir 1000 et une raisons pour lesquelles le client ne répond plus : on est venu le chercher, quelqu'un discute avec lui, son téléphone sonne, il est parti faire pipi, il est mort, quelqu'un s'est pris les pieds dans le câble, sa machine a planté, etc.

Donc il faut mettre un time-out dans le code du serveur et voilà !

J'ai bien pensé utiliser les sockets avec UDP mais je ne sais pas si c'est conseillé

Pas trop, non

[tayky]

Oh chouchou, le serveur est perturbé, il va nous faire sa petite dépression, faut vite lui faire un calinou,

Et ça, ça veut juste dire que le code qui tourne sur le serveur est mal écrit !
Car il peut y avoir 1000 et une raisons pour lesquelles le client ne répond plus : on est venu le chercher, quelqu'un discute avec lui, son téléphone sonne, il est parti faire pipi, il est mort, quelqu'un s'est pris les pieds dans le câble, sa machine a planté, etc.

Donc il faut mettre un time-out dans le code du serveur et voilà !

Oui en effet le timeOut va résoudre le plantage mais malheureusement les perfs resterons mauvaise.
C'est justement pour ça que je cherche à remplacer le système déjà mis en place.

Pas trop, non

Merci pour la ressource

[Jipété]

Oui en effet le timeOut va résoudre le plantage mais malheureusement les perfs resteront mauvaises.

Ben surement pas, ou alors tu n'as pas compris le principe (ou le programme sur le serveur est codé avec les pieds).

Le time-out c'est un compteur qui redémarre dès que le serveur a envoyé une réponse au client, dans le contexte du client (= chaque client a son contexte et son time-out), et si au bout d'un certain temps (à déterminer en fonction de paramètres que j'ignore, mais ça pourrait très bien être 5 secondes comme 10 minutes) le compteur déborde ça veut dire que le processus n'a pas eu de réponse du client donc le serveur déconnecte cette session et basta !

Exactement comme sur ce forum (comme partout, en fait) : ouvre une discussion en mode "répondre" et abandonne le navigateur pour aller faire autre chose ; tu verras qu'au bout d'un certain temps tu auras été déconnecté...


PS : quand tu réponds après avoir cliqué sur "Répondre avec citation", ce n'est pas dans la citation qu'il faut écrire, c'est après la balise /QUOTE, sinon ta réponse ne ressemble à rien. Et quand tu as une réponse qui ne ressemble à rien, tu as un bouton "Modifier le message" pour la remaquiller et lui filer un coup de peigne. Oki ?

[tayky]

Je me suis mal expliqué mais comme je te disais plus haut oui le timeout corrige bien le problème de plantage.
Mais en aucun cas les performances de transmission de notre information.
Je te fournis d'avantage d'info sur le processus:

Nous avons une suite d'applications optimisé en braille. Nous passons les strings contenues dans les applications client au serveur pour être translate en braille puis retransmit sur l'afficheur.
L'utilisateur a accès qu'à une portion de texte (32 chars), il peu effectuer des actions pour défiler le texte par une combinaison qui est transmise au serveur puis ce dernier récupère le bloc de texte suivant/précédent.

Actuellement ça fonctionne mais l'affichage ne défile pas assez rapidement.

Nous avons fais des tests isolés en prenant en compte les différentes remarques afin de tester dans un concept simple.
Mais les performances reste moyenne pour l'utilisateur.

[Jipété]

Bon, donc en gros le problème n'a plus rien à voir avec le titre de la discussion, mais plus avec la partie applicative.

Faudrait monter une appli de test où toute la partie affichage serait récrite (réécrite ou ré-écrite sont des fautes de français) d'une manière ultra-simple et légère, et testée avec un utilisateur voyant, pour vérifier que la communication client-serveur fonctionne vite et bien.
Si c'est le cas, le problème sera dans la partie application spécifique (Braille, tout ça..)
Si ce n'est pas le cas, ça sera plus facile à débugger sans toute la partie spécifique.

Allez hop !, au boulot

[Andnotor]

Le fichier mappé est juste une zone mémoire partagée, ça ne te dispensera pas de mettre en route une communication inter-processus.
Pourquoi ne pas simplement utiliser les messages Windows (ex. WM_COPYDATA) ?