WCF, 4.0, Bidirectionnel

Question

... quelles sont les options disponibles avec .NET 4.0, d'une manière qui supporte NAT pour le client (c'est-à-dire le client derrière NAT). Je préférerais utiliser quelque chose basé sur HTTP, mais c'est une condition faible - je pense qu'à moyen terme, je vais avoir une communication non http en dehors de WCF de toute façon, donc la traversée de proxy est quelque chose que je pourrais retarder. Il y avait le problème que le canal serveur-> client était ouvert à partir du serveur, ce qui rendait NAT quelque chose de non-traversable.

L'interrogation n'est pas acceptable - nous parlons ici d'informations sensibles au temps.

Alors, quelles sont mes options maintenant?

Answer 1

Vous pouvez ouvrir une connexion du client et juste le garder ouvert. Ou transférer des ports sur NAT aux clients, de sorte que la connexion à NAT: 34823 ira à 192.168.xxx.xxx:80. Ou payez Microsoft un peu d'argent pour utiliser leur bus de service, qui n'est pas exactement terminé et avec un avenir incertain. Ou faites un peu de piratage intelligent, installez Skype sur les clients et les serveurs, envoyez vos messages via l'API.

Answer 2

Ceci n'est pas spécifique à .net 4.0, mais vous pouvez utiliser Windows Azure Service Bus.

Si votre application nécessite connectivité bidirectionnelle vous avez fait deux choix: Soit vous pariez sur les solutions de contournement disponibles et de vivre avec les conséquences (comme BitTorrent fait) ou vous construisez et exploitez une forme de service de relais pour votre application. Un service de relais accepte et maintient les connexions de clients pare-feu et/ou NAT-ed et route les messages entre eux. Pratiquement tout le chat, la messagerie instantanée , vidéoconférence, VoIP, et applications de jeux multi-joueurs et beaucoup d'autres applications Internet populaires dépendent d'une certaine forme de service de relais.

Le défi avec les services de relais est qu'ils sont incroyablement difficiles à construire de façon à pouvoir fournir l'échelle d'Internet où ils doivent route entre des milliers, voire millions de connexions que les grandes réseaux de messagerie instantanée faire. Et une fois que vous avez un relais qui peut soutenir une telle échelle, il est incroyablement cher pour fonctionner. Si cher en fait que les investissements requis et les coûts opérationnels résultants sont entièrement hors de portée pour la vaste majorité des sociétés de logiciels . Le défi de connectivité est un vrai bloqueur de l'innovation et représente une barrière d'entrée significative .

Les bonnes nouvelles sont que Microsoft .NET Service Bus offre une gamme de bidirectionnelle, peer-to-peer options de connectivité, y compris la communication relayée . Vous n'êtes pas obligé de construire le vôtre ou de le faire vous-même; vous pouvez utiliser ce Building Block à la place. Le bus de service .NET couvre quatre zones de fonctionnalité logiques: Naming, Registry, Connectivity et Eventing.

http://vasters.com/clemensv/PermaLink,guid,92d78bee-2cfd-4a29-95ab-c5abb9b905e7.aspx