WCF poussé vers le client via un pare-feu ?[fermé]

Question

Voir également Comment un serveur WCF informe-t-il un client WCF sur les modifications?(Meilleure solution que sondage simple, par exempleCommentaire ou long sondage)

Je dois utiliser la technologie push avec WCF via les pare-feu clients.Cela doit être un problème courant, et je sais pertinemment que cela fonctionne en théorie (voir les liens ci-dessous), mais je n'ai pas réussi à le faire fonctionner et je n'ai pas pu trouver d'exemple de code qui le démontre.

Exigences:

• WCF
• Les clients se connectent au serveur via le port TCP 80 (netTcpBinding).
• Le serveur renvoie les informations à intervalles irréguliers (1 min à plusieurs heures).
• Les utilisateurs ne devraient pas avoir à configurer leurs pare-feu, les push du serveur doivent passer par des pare-feu dont tous les ports entrants sont fermés.Pour cela, un duplex TCP sur la même connexion est nécessaire, une double liaison ne fonctionne pas puisqu'un port doit être ouvert sur le pare-feu client.
• Les clients envoient des battements de cœur au serveur à intervalles réguliers (peut-être toutes les 15 minutes) afin que le serveur sache que le client est toujours en vie.
• Le serveur est IIS7 avec WAS.

La solution semble être netTcpBinding duplex.Sur la base de ces informations :

WCF via les pare-feu et les NAT

Garder les connexions ouvertes dans IIS

Mais je n'ai pas encore trouvé d'exemple de code qui fonctionne.J'ai essayé de combiner les exemples "Duplex" et "TcpActivation" des exemples WCF de Microsoft sans succès.S'il vous plaît, quelqu'un peut-il m'indiquer un exemple de code qui fonctionne ou créer un petit exemple d'application.Merci beaucoup!

Answer 1

J'ai trouvé quelques solutions:

Glace ZeroC GPL avec une option commerciale.Je n'ai testé que rapidement.Semble plus puissant que .NET Remoting et est très activement développé.

RemObjects Développement commercial et actif, prend en charge tout mais ne semble pas avoir toutes les fonctionnalités plus avancées utilisées par GenuineChannels.

Chaînes authentiques.Il utilise l'accès à distance avec de nombreuses fonctionnalités supplémentaires intéressantes, la plus importante étant qu'il fonctionne via les NAT sans avoir besoin d'ouvrir le pare-feu client.Malheureusement, il semble être très mort.

Une autre solution consiste à utiliser le streaming avec IIS, selon cet article : Garder les connexions ouvertes dans IIS

Le client établit la première connexion (http avec IIS6, TCP avec IIS7) au serveur sur le port 80, la connexion est ensuite maintenue ouverte avec une réponse en streaming qui ne se termine jamais.

Je n'ai pas eu le temps d'expérimenter cela et je n'ai pas trouvé d'exemple indiquant que cela résout spécifiquement le problème du pare-feu, mais voici un excellent exemple qui fonctionne probablement : Flux XML.

Answer 2

As-tu essayé de regarder : http://www.codeproject.com/KB/WCF/WCF_Duplex_UI_Threads.aspx

Pouvez-vous donner des exemples de ce que vous avez déjà tenté ?Avec des détails sur les pare-feu, etc., des messages d'erreur ?

Si le client et le serveur peuvent être adressés directement et que les pare-feu ne posent pas de problème, avez-vous envisagé d'autoriser les clients à enregistrer une URL fournissant un contrat pris en charge.Le serveur peut ensuite appeler ce service chaque fois qu'il en a besoin, sans avoir besoin d'établir une connexion longue durée (mais principalement inactive), évite le besoin de battements de cœur et peut être rendu résilient entre les sessions/connexions.

Answer 3

Dans la plupart des configurations de pare-feu, la connexion TCP sera supprimée par le pare-feu si elle est inactive afin de conserver les ressources.Le délai d'inactivité n'est probablement pas quelque chose que vous pouvez contrôler.Certains les démoliront s’ils sont inactifs et qu’une limite de ressources est atteinte.

De toute façon, la plupart des environnements d'entreprise ne permettent à aucune machine d'établir une connexion TCP sortante.

De plus, l’utilisation de ce mécanisme signifie que vous rencontrerez des problèmes de mise à l’échelle.Je pense qu'une solution plus fiable consiste à mettre les informations en file d'attente et à demander à vos clients de les consulter régulièrement.Utilisez la mise en cache si possible de sorte qu'une enquête client ultérieure obtienne les données mises en cache du cache proxy du client, s'il en utilise un.

Si vous devez transmettre des données en temps opportun, en moins d'une seconde (c'est-à-direservices financiers), puis envisagez une infrastructure de messagerie telle qu'un distributeur NServiceBus côté client, mais cela nécessitera une installation client...

Alors, avez-vous essayé d'utiliser Toredo ?Après avoir lu qu'il y apparaîtrait, il est probablement trop compliqué à configurer pour un utilisateur.

Answer 4

Je n'ai pas essayé le scénario dont vous parlez donc je ne peux pas trop vous aider, désolé.Si tout ce que vous devez contourner est le pare-feu client, vous voudrez peut-être vérifier ce post.

Bonne chance.

Answer 5

Avez-vous essayé celui-ci ?DuplexHttpBinding

Il utilise une technique d'interrogation intelligente encapsulée sous forme de liaison WCF personnalisée.Cela devrait donc fonctionner immédiatement.

Answer 6

Vous pouvez effectuer les modifications suivantes dans le client pour accéder au service Web duplex sur un client compatible avec le pare-feu.

• Définir l'option WebHttp cochée dans Pare-feu -> Avancé -> Paramètres (des paramètres de connexion réseau) -> Serveur Web (Http)