Communication serveur-client asynchrone multidirectionnelle sur la même socket ouverte?

J'ai une application client-serveur où le client est sur un périphérique Windows Mobile 6, écrit en C ++ et le serveur est sur Windows et écrit en C #.

À l'origine, je n'en avais besoin que pour envoyer des messages du client au serveur, le serveur renvoyant uniquement un accusé de réception indiquant qu'il avait reçu le message. Maintenant, je voudrais le mettre à jour afin que le serveur puisse réellement envoyer un message au client pour demander des données. Comme je l'ai actuellement configuré pour que le client ne soit en mode de réception qu'après avoir envoyé des données au serveur, cela ne permet pas au serveur d'envoyer une demande à tout moment. Je devrais attendre les données du client. Ma première pensée serait de créer un autre thread sur le client avec une socket ouverte séparée, à l'écoute des requêtes du serveur ... tout comme le serveur a déjà à l'égard du client. Y at-il un moyen, dans le même thread et en utilisant le même socket, à tous les serveurs d'envoyer des demandes à tout moment?

Pouvez-vous utiliser quelque chose à l'effet de WaitForMultipleObjects() et lui passer un tampon de réception et un événement qui lui indique qu'il y a des données à envoyer?

0

4 Réponses

Je ne sais pas si vous voulez ou non ajouter les bits asynchrones au serveur en C# ou au client en C ++.

Si vous envisagez de le faire en C ++, les plates-formes Windows de bureau peuvent effectuer des E / S de socket de manière asynchrone via les API qui utilisent des E / S superposées. Pour les sockets, WSASend, WSARecv autorise les E / S asynchrones (lisez la documentation sur leurs paramètres LPOVERLAPPED, que vous pouvez remplir avec les événements qui sont définis à la fin de l'E / S).

Je ne sais pas si les plates-formes Windows Mobile prennent en charge ces fonctions, vous devrez peut-être effectuer des recherches supplémentaires.

0
ajouté

Découvrez asio . C'est une bibliothèque c ++ cross-compatible pour les E / S asynchrones. Je ne sais pas si cela serait utile pour le serveur (je n'ai jamais essayé de lier une DLL c ++ standard à un projet c #) mais pour le client cela serait utile.

Nous l'utilisons avec notre application, et il a résolu la plupart de nos problèmes de concurrence d'E / S.

0
ajouté

Lorsque je devais écrire une application avec un modèle client-serveur où les clients pouvaient partir et entrer quand ils le voulaient (je suppose que c'est aussi le cas pour votre application lorsque vous utilisez des appareils mobiles), je me suis assuré que les clients > en ligne message au serveur, indiquant qu'ils étaient connectés et prêts à faire tout ce dont ils avaient besoin.

à ce moment-là, le serveur pouvait renvoyer des messages au client via la même connexion ouverte.

En outre, mais je ne sais pas si cela s'applique à vous, j'ai eu une sorte de heartbeat les clients envoyés au serveur, le laissant savoir qu'il était encore en ligne. De cette façon, le serveur sait quand un client a été déconnecté de force du réseau et il peut marquer ce client comme hors ligne.

0
ajouté

L'utilisation de la communication asynchrone est totalement possible dans un seul thread!

There is a common design pattern in network software development called the reactor pattern (look at this book). Some well known network library provides an implementation of this pattern (look at ACE).

Brièvement, le réacteur est un objet, vous enregistrez toutes vos prises à l'intérieur, et vous attendez quelque chose. Si quelque chose se produit (nouvelles données arrivées, connexion à proximité ...) le réacteur vous en informera. Et bien sûr, vous ne pouvez utiliser qu'une seule socket pour envoyer et recevoir des données de manière asynchrone.

0
ajouté