WSDualHttpBinding pour les rappels duplex

Question

L'utilisation de WSDualHttpBinding pour les rappels duplex fonctionnerait-elle dans des scénarios réels ?Supposons que j'ai une application .NET qui utilise un port aléatoire, le service serait-il capable de résoudre les adresses de base et le port du client pour les rappels ?

Answer 1

Une réponse complète à votre question dépend du « scénario du monde réel » : un scénario Intranet ou Internet.Bien que WSDualHttpBinding fonctionne dans les deux scénarios, il y a des spécificités à prendre en compte :

Intranet

WSDualHttpBinding fonctionnera avec votre application .NET en utilisant un port personnalisé préconfiguré dans un scénario Intranet et « Oui », le service sera en mesure de résoudre les adresses de base et le port du client pour les rappels :exactement comment est expliqué ci-dessous.La raison pour laquelle cela est expliqué ci-dessous est que WSDualHttpBinding est principalement conçu pour être utilisé sur Internet.

Les rappels duplex dans un scénario Intranet lorsque vous pouvez utiliser WCF à la fois sur le client et le serveur sont mieux réalisés en utilisant NetTcpBinding ou NetNamedPipeBinding.Ces liaisons utilisent respectivement TCP et ICP comme transport (plutôt que HTTP) et un codage binaire personnalisé, c'est pourquoi WCF est requis des deux côtés.Pour les rappels vers le client, le même canal utilisé pour se connecter au Service via le Binding est réutilisé sans nécessiter l'ouverture d'un nouveau port.

l'Internet

Dans un scénario Internet, les requêtes et réponses HTTP valides ne voyagent que dans un seul sens, HTTP est conçu comme un protocole unidirectionnel.Lors de l'utilisation de WSDualHttpBinding, WCF crée donc un canal HTTP séparé pour les rappels.En réponse à votre deuxième question :l'adresse de destination de ce rappel au client est composée par défaut du nom d'hôte de la machine client et du port 80.Si le client est une machine de développement par exemple et qu'IIS est installé, le port 80 sera exclusivement réservé dans certains scénarios ce qui entraînera des conflits avec votre application prototype.C'est quoi ce billet de blog présente une solution et ce pour quoi la propriété ClientBaseAddress est conçue pour aider.Quel que soit le port que vous utilisez - celui par défaut ou personnalisé, vous devez vous assurer que tous les pare-feu et routeurs des deux côtés sont correctement configurés pour permettre l'établissement du canal sortant et du canal de rappel séparé.

Une application .NET peut également désigner une application Silverlight.Étant donné qu'une application Silverlight exécutée dans un navigateur ne peut pas accepter de nouvelles connexions HTTP entrantes, WSDualHttpBinding avec son canal arrière séparé ne fonctionnera pas.Par conséquent, PollingDuplexHttpBinding a été créé d'abord dans Silverlight 2, ce qui peut être considéré comme une « astuce » intelligente pour contourner le fait que HTTP est unidirectionnel en gardant le canal de requête ouvert pendant une longue période (interrogation longue) et en l'utilisant comme canal de retour pour rappelle le client.Cela a un certain nombre d'implications côté client et côté serveur, particulièrement pertinentes pour la mise à l'échelle. Pour plus de détails, veuillez consulter cet article de mon blog.

Avec une idée de votre "scénario du monde réel" particulier et de vos cas d'utilisation, j'espère que cela vous aidera à déterminer la liaison correcte à utiliser pour les rappels duplex.

Answer 2

S'il s'agit d'une application derrière un pare-feu, théoriquement oui.Cela dépend de ce que vous entendez par « monde réel » ;si vous entendez par là "hautes performances", NetTcpBinding est peut-être une meilleure approche.