KeepAlive avec WCF et TCP?

J'ai un Windows Service d'hébergement avancé de service WCF qui communique sur TCP(netTCP) avec protobuf.net, quelques fois aussi avec des certificats.

La receiveTimeout est infinie à ne jamais laisser tomber la connexion en raison d'inactivité. Mais ce que je comprends de la connexion pourrait être abandonné de toute façon j'ai donc créé un simple de deux façon keepalive méthode de service que le client appelle toutes les 9 min de garder la connexion. Il est très important que la connexion ne brise jamais.

Est-ce la bonne manière? Ou pourrais-je simplement supprimer mon garder parce que la receiveTimout est infinie?

Edit : application en cours.config pour le service WCF : http://1drv.ms/1uEVKIt

source d'informationauteur Banshee

  1. 33

    Pas. C'est très mal compris, et, malheureusement, il ya beaucoup de désinformation là-bas.

    Tout d'abord, "l'Infini" est une sorte de semi-valeur valide. Il y a deux config sérialiseurs que convertir "Infini" TimeSpan.MaxValue ou int.MaxValue (donc ils ne sont pas vraiment "infini" de toute façon), mais tout n'est pas dans WCF semble le reconnaître. Il est donc toujours préférable de préciser vos délais d'attente explicitement avec des valeurs de temps.

    Deuxième, vous n'avez pas besoin d'un "keepalive" méthode à votre service, depuis WCF fournit ce qu'on appelle une "session". Si vous ajoutez <reliableSession enabled="true" /> puis WCF fournira sa propre garder vivante mécanisme par "messages d'infrastructure".

    Par avoir votre propre "keepalive" mécanisme, vous êtes effectivement le doublement de la charge de travail de votre service et vous pouvez en fait créer plus de problèmes qu'elle n'en résout.

    Troisième, lors de l'utilisation d'un système fiable de session, vous utilisez le inactivityTimeout réglage de reliableSession. Cela ne signifie deux choses. Tout d'abord, il contrôle la fréquence de l'infrastructure (keepalive) les messages sont envoyés. Elles sont envoyées à la moitié de la valeur de délai d'expiration, si vous le réglez à 18 minutes, puis ils seront envoyés à toutes les 9 minutes. Deuxièmement, si aucune infrastructure ou l'exploitation des messages (c'est à dire des messages qui font partie de votre contrat de données) sont reçues dans le délai d'inactivité, la connexion est annulée parce qu'il n'y a probablement eu un problème (un côté est tombé en panne, il y a un problème de réseau, etc..).

    receiveTimeout est le montant maximum de temps dans lequel aucune opération n'messages peuvent être reçus avant que la connexion est interrompue (la valeur par défaut est de 10 minutes). Mettre ce paramètre à une valeur élevée (Int32.MaxValue est quelque part dans le voisinage de 24 jours) maintient la connexion cloué, l'installation inactivityTimeout à une valeur plus petite (encore une fois, la valeur par défaut est de 10 minutes) (pour un temps inférieur à 2x le montant maximum de temps avant que les routeurs de réseau d'une perte de connexion de l'inactivité) maintient en vie.

    WCF gère tout cela pour vous. Vous pourrez alors simplement vous abonner à la Connexion Interrompue messages pour savoir si la connexion est abandonnée pour les raisons réelles (application se bloque, les délais d'attente réseau, les clients de perdre le pouvoir, etc..) et vous permet de recréer les connexions.

    En outre, si vous n'avez pas besoin commandé des messages, définir des ordered="false"ce qui réduit considérablement les frais généraux de la fiabilité des séances. La valeur par défaut est true.

    Remarque: Vous ne pouvez pas recevoir une connexion interrompue jusqu'à ce que le inactivityTimeout a expiré (ou vous essayez d'utiliser la connexion). Être conscient de cela, et de définir vos délais d'attente en conséquence.

    La plupart des recommandations sur l'internet sont à définir à la fois receiveTimeout et inactivityTimeout à l'Infini. Cela a deux problèmes, le premier de l'infrastructure messages ne sont pas envoyés en temps opportun, de sorte que les routeurs perte de connexion... vous forçant à faire vos propres connexions actives. Deuxièmement, les grandes délai d'inactivité signifie qu'il ne reconnaissent pas quand une connexion légitimement gouttes, et vous devez compter sur à qui de ping abandon de savoir lorsqu'une défaillance se produit. C'est tout à fait inutile, et peut, en fait, même faire à votre service même plus fiable.

    Voir également ceci: Comment puis-je configurer correctement un WCF NetTcp Duplex Fiable Session?

  2. 0

    Dans mon expérience, j'ai trouvé le problème qui n'est pas nécessairement causé par le service WCF ou de la configuration, mais les clients propre routeur.

    Auparavant, j'ai eu des problèmes où les longs délais d'attente ont été l'installation et la connexion encore tombé après une période d'inactivité. Je crois que certains routeurs ont un mécanisme en place pour jeter les connexions qu'il juge les plus actifs, donc ma seule solution était de mettre en œuvre une méthode vide sur le service et l'appeler périodiquement à partir du client.