le protocole de communication en temps réel .NET socket bidirectionnelle

Question

Je dois maintenir une connexion entre un serveur et plusieurs clients afin que les clients peuvent envoyer des commandes et les événements déclencheurs du serveur. Le serveur est essentiellement un lecteur de musique, et les clients envoyer des commandes comme « Play () », « Pause () », « GetPlaylists () », etc. Le serveur sur le besoin de côté de ce pouvoir de dire aux clients des choses comme "SongEnded" ou "PlayerPaused". Et aussi, il doit être possible d'envoyer des données à deux sens (comme la chanson en cours, image de l'album, listes de lecture, etc.). Je pourrais la cause aller de l'avant et de créer une prise moi-même et créer mon propre protocole pour traiter tous les scénarios ci-dessus, mais il est probable que quelqu'un a déjà fait avant moi, donc ce que je veux vraiment est un cadre fait pour-Temps réel- la communication entre le serveur et le client pour .NET. Je l'ai regardé xml-rpc par exemple, mais ne sais pas comment je gérer le « OnClientSend » avec cela. De plus, si je ne me trompe pas, est fait pour être comme REST xml-rpc. Je l'ai aussi regardé WCF, mais comme je n'ai aucune expérience avec elle, je ne sais pas où commencer et comment héberger le serveur dans un simple console app.

Important:. Les besoins du client pour être en mesure de ne pas être .NET
Important: Cela doit être possible de se connecter à Java (Android)
. Important:. Plates-formes primaires sont des fenêtres (serveur et client) et Android (clients) à Important: Pas de streaming audio est fait. Toutefois, les images doivent être envoyées.

Toutes les idées pour une solution serait appréciée. En outre, si vous avez des liens vers un bon cadre, ou une description de la façon d'utiliser SERAIS vraiment heureux composants déjà existants dans .NET I.

[Modifier] Le problème est que lors de l'envoi des données sur les prises, il n'y a aucune garantie (du tout!) Que les paquets que vous avez envoyés seront lus par le serveur en même temps. Je pourrais envoyer 50, puis 100, puis 50 octets de nouveau, mais le serveur peut lire que comme un morceau de 200byte ou 100 premiers puis 100 etc, qui signifie que je dois créer un tampon, lire dans les messages jusqu'à ce que je sais pour certain (ce est le problème) que j'ai reçu un message entier (et rien de plus).

Answer 1

J'ai fini par créer mon propre protocole simple que je peux facilement mettre en œuvre en plusieurs langues. J'atteint le résultat recherché par l'ajout d'une couche supplémentaire de tampons sur les deux côtés de la douille, puis l'envoi de chaque message suivi d'une séquence d'octets qui indique à l'autre côté que ce fut la fin du message. Aussi j'ajouté id de au message pour activer le message spesial « $ Retour ».

Les messages sont simplement des classes sérialisés à l'aide XmlSerializer. Les classes sont générées à partir de XSD.

Answer 2

ZeroMQ semble un bon moyen pour votre problème. Semble que vous avez mis en place quelque chose vous similaire.

• La bibliothèque SuperSocket qui agit comme un cadre de concurrence.

• messages à travers Carries inproc, IPC, TCP et multicast.

• Connexion N à N dans sortance, PubSub, pipeline et modèles demande-réponse.

• assez rapide pour les produits ordonnés en clusters et un supercalculateur.

• E / S asynchrones pour des applications de transmission de messages multi-cœurs évolutive.

• Grande et active communauté open source.

• 20+ langues, y compris C, C ++, Java, .NET, Python.

• La plupart des systèmes d'exploitation, y compris Linux, Windows, OS X.

• LGPL logiciel libre, support commercial par iMatix Corporation.

Answer 3

Vous devriez aller pour WCF: http://msdn.microsoft.com /en-us/netframework/aa663324.aspx

Answer 4

Vous pouvez également consulter XMPP et WebSockets . XMPP est non seulement limité pour vous messagerie pouvez toujours l'étendre pour votre propre usage. WebSockets est à venir ainsi que cela fait partie de HTML5.