2010-09-19 10 views
3

J'écris un petit jeu simple pour mes enfants - peu importe ce qu'il fait, même si je ne peux pas vous le dire de toute façon, car je n'ai pas encore décidé! Cependant, je pense qu'il aura un composant de serveur et un certain nombre de composants de client, et je regarde des manières que les clients peuvent communiquer avec le serveur. TOUT mon expérience précédente ... toute ma carrière en fait ... a impliqué l'élément de serveur soit une base de données, un serveur Web, ou les deux en tandem. Aucun des deux n'est approprié dans ce cas, donc je suis curieux de savoir quels moyens je pourrais utiliser pour communiquer entre les deux.Communication asynchrone entre deux applications

De toute évidence, il serait préférable d'adopter une technologie ou une technique que je peux réutiliser dans mon travail, où je travaille de plus en plus avec Windows Forms. J'imagine qu'il y a 1001 approches différentes que je pourrais adopter; il s'agit de trier le bon grain de l'ivraie.

J'ai littéralement commencé à lire sur WCF, mais ce n'est pas encore clair, si cette approche orientée service est ce que je recherche. Je suis délibérément vague sur ce que les applications vont faire; Je m'attends à ce que le client annonce sa présence au serveur, alimente les choix des utilisateurs jusqu'au serveur, et en retour, le serveur mettra périodiquement à jour le client avec ce qui se passe dans le jeu plus large. Le jeu sera basé sur le tour plutôt que sur le temps réel ... et très low-tech vraiment!

Suggestions? Idéalement, avec des liens vers de bonnes ressources d'apprentissage, s'il en existe.

Conclusion: Je pensais réellement qu'il pourrait y avoir plus d'alternatives viables; il y a Remoting (maintenant déprécié), mais le consensus dit que WCF est la voie à suivre - dans mon cas, l'auto-hébergement semble attrayant.

Merci pour les réponses.

Répondre

3

On dirait que vous êtes intéressé par WCF et qui est une technologie raisonnable d'utiliser dans ce cas. Lorsque vous écrivez un jeu en réseau, l'approche la plus simple consiste à utiliser ici l'approche du serveur client. Avec WCF, vous avez des possibilités d'hébergement différentes, hébergement dans IIS ou auto-hébergement. Je voudrais aller à l'auto-hébergement pour éviter le besoin d'IIS sur vos ordinateurs à la maison.

Le service peut être hébergé dans un service Windows ou dans l'un des clients. Je recommande d'exécuter en tant que service Windows. Le service pourrait très bien fonctionner sur la même machine que l'un des clients.

Edit:
Si vous souhaitez héberger le serveur dans l'un des clients que vous pourriez fournir une option de menu « démarrer le service » qui commence un service self hosted sur cet ordinateur (et connecter automatiquement la partie client à localhost) . Une fois le service démarré, vous pouvez présenter le nom de l'ordinateur que vous entrez sur les "autres" ordinateurs à connecter.

Je suggère de séparer la partie de service dans un projet distinct, alors vous pouvez facilement répartir le service à un service Windows plus tard si vous le souhaitez.

Edit2:
Par ailleurs, étant donné que WCF est entraîné par les appels du client dont vous avez besoin pour interroger le serveur pour les changements. Vous pouvez google wcf long polling ou simplement long polling pour des méthodes pour "pousser" des messages du serveur au client.

+0

L'absence de besoin d'un logiciel ou d'un service pré-installé (par exemple, IIS, etc.) est une condition préalable (désolé, aurait dû être explicite). En dehors de .NET Framework bien sûr! Je ne savais pas si le serveur de jeu pouvait héberger des services WCF ... je préfère qu'il fonctionne dans le jeu, si possible - je veux qu'il soit aussi invasif que possible pour la machine hôte. – CJM

+0

@CJM: J'ai mis à jour ma réponse avec un lien décrivant comment héberger un service WCF qui devrait vous aider à démarrer. –

+0

Albin - Merci pour le lien sur l'auto-hébergement - ce regard sur la voie à suivre, je pense. – CJM

0

Je regarderais Remoting si j'étais vous. C'est assez facile à implémenter et vous pouvez certainement l'utiliser au travail.

Il y a un tutoriel sur le sujet ici: http://generally.wordpress.com/2007/05/31/a-simple-remoting-example-in-c/

+2

Remoting est vieille école, WCF devrait être utilisé. –

+0

http://msdn.microsoft.com/en-us/library/kwdt6w2k.aspx indique que l'accès distant est obsolète, WCF est le remplacement. –

+0

Intéressant, merci pour le lien. Je pensais plutôt à un peer to peer sur deux postes de travail mais je vais jeter un oeil à WCF :). – Wil

1

Here est un bon livre sur WCF, qui peut vous aider à démarrer. Il a une courbe d'apprentissage assez longue (j'ai encore à peine gratté la surface), mais j'ai l'impression que c'est un moyen très puissant de mettre en place une application basée sur le service. Sur la page que j'ai liée, consultez le lien Exemples, qui comprend un tas de code du livre, y compris ServiceModelEx de Juval, qui a une grande variété de classes utiles pour travailler avec WCF.

1

Je vais aller à l'encontre de la foule ici et de la suggestion de ne pas utiliser WCF. WCF est une excellente technologie pour l'architecture orientée services, mais il est largement écrit sur l'idée que les clients ne resteront pas connectés au serveur, mais plutôt se connecter, envoyer un message, peut-être recevoir un résultat, et se déconnecter.

Il existe un mécanisme qui peut être utilisé pour les clients connectés depuis longtemps, mais franchement, cela ne fonctionne pas très bien, a toutes sortes de problèmes et de bizarreries, et n'est pas très fiable pour savoir quand les clients se sont déconnectés ou non, ou si les clients savent s'ils sont toujours connectés au serveur. Il s'agit plutôt d'une solution boulonnée qui tente de s'ancrer dans le modèle WCF.

L'autre problème concerne les pare-feu. Il ne peut pas y avoir de pare-feu entre l'initiateur et le récepteur (ou il doit y avoir un port ouvert). Cela signifie que vous ne pouvez pas facilement avoir deux clients derrière des pare-feu qui veulent se parler. Vous avez besoin d'un type de serveur intermédiaire exposé qui est ouvert. Bien que ce problème s'applique à toutes les solutions, il est plus facile à gérer avec des connexions TCP directes qu'avec WCF. Je ne suis pas un très grand partisan du roulement de votre propre solution, mais WCF est vraiment exagéré pour une simple communication bidirectionnelle entre les applications client.

Je n'ai pas encore trouvé une bonne bibliothèque réseau open source pour .NET. Je sais que beaucoup de gens vont s'inscrire dans diverses bibliothèques, mais tout ce que j'ai vu est vieux et a plusieurs défauts. La plupart semblent être quelqu'un qui a arraché leur bibliothèque d'une application et a essayé de l'emballer comme un générique, mais laissant dans toutes les hypothèses de leur application.

Le problème est que les versions récentes de .NET ont ajouté beaucoup de nouvelles fonctionnalités réseau, notamment en termes de support asynchrone. Pour l'instant, je n'ai vu aucune bibliothèque qui implémente ces fonctions.

Tout le monde veut m'aider à construire une bonne bibliothèque réseau basée sur .net 3.5+.

+0

En l'occurrence, mon application n'a pas besoin de rester longtemps connectée, ni de traverser les pare-feux (au-delà de la version intégrée de Windows). Mais je prends votre point de vue. La WCF semble fonctionner pour moi, mais je suis ouvert d'esprit et je considérerai n'importe quelle alternative. – CJM

+0

Eh bien, si vous pensez que la WCF fonctionnera pour vous, alors il est assez facile de faire quelque chose. Cependant, il existe une courbe d'apprentissage importante pour aller au-delà des exemples types. –

+0

Les projets de travail sont habituellement précipités et mal planifiés, et ils doivent toujours être terminés hier - il est difficile d'apprendre des choses complètement nouvelles sur le tas. Alors j'essaie de prendre un tour ou deux dans mon temps ... courbe d'apprentissage abrupte = une connaissance utile à la fin? – CJM

0

Vous pouvez également envisager d'utiliser la communication via des messages en utilisant Eneter Messaging Framework. Le framework est très léger, facile à utiliser et supporte différents scénarios de communication (communication unidirectionnelle, requête-réponse, publication-abonnement, ...). Il peut communiquer via Named Pipes, Tcp ou Http et peut également être utilisé pour la communication entre les threads.

Si vous êtes intéressé, vous pouvez vérifier link text.

+0

Merci Ondrej. Bien qu'il semble être un cadre potentiellement utile, une licence est requise pour un usage commercial. Je serais d'accord avec ce projet, parce que ce n'est pas commercial, mais je veux acquérir des compétences que je peux acquérir en milieu de travail. Mais néanmoins, c'est un lien utile. – CJM

Questions connexes