quand utiliser duplex de service?

Bien, je sais que dans un duplex contrat, le service peut envoyer des messages au client, mais je voudrais savoir si c'est vraiment utile.

J'ai une application commune qui envoyer la demande au service afin d'obtenir des données de la base de données, insérer des données... etc. Aussi, j'ai besoin de stocker des fichiers sur 40 mo d'espace dans la base de données, j'ai donc besoin d'une bonne performance. Pour cette raison, je voudrais utiliser le net.tcp liaison avec le mode de transfert en streaming, mais le problème est qu'un filet.tcp duplex de service ne pouvez pas utiliser le flux de mode de transfert.

Donc je pense que j'ai quelques options.

1.- étude si j'ai vraiment besoin d'un duplex contrat pour ce type d'application. Peut-être dans une application de chat, par exemple, il a plus de sens, un duplex de contrat parce que le serveur a peut-être besoin d'en informer le client lorsqu'un contact est connecté... etc. Mais dans un même client que l'accès à une base de données, il est nécessaire un double contrat? ce genre d'opérations peut avoir besoin d'un duplex contrat?

2.- Autre option, c'est de ne pas avoir un duplex contrat, mais de mettre en place un pas de duplex contrat dans le serveur et les autres unique contrat le client, de sorte que quand un client se connecte au service, le service de recevoir les informations nécessaires pour vous connecter au service du client. Mais, est-ce un bon moyen d'éviter un duplex contrat?

3.- Vraiment pour mon application, j'ai besoin tcp au lieu d'un duplex HTTP qui permet une diffusion en continu en mode de transfert? Qu'est-ce que les avantages de la tcp sur le HTTP en termes de performance?

Grâce.

InformationsquelleAutor | 2012-06-25
  1. 5

    Aborder chaque point:

    1, 2. Je pense que pour votre scénario d'un duplex service est inutile. Comme vous le dites vous-même un duplex de service est généralement à portée de main lorsque le client et le service à la nécessité de garder informant les uns les autres sur une base constante, ce que vous faites, de recevoir beaucoup de/sortie de données d'une base de données ne semble pas être une bonne affaire pour l'utilisation de la communication en duplex. Concernant netTcpBinding ne permettant pas de Streaming avec recto verso, vous pouvez simplement retourner un tableau d'octets (byte[]) au lieu d'un flux. 40 MO, c'est beaucoup, mais je ne pense pas que le Streaming va nécessairement avoir un gain de performance significatif sur un duplex service qui va retourner un tableau d'octets (à vous de tester chaque installation et de comparer les résultats). Donc, vous avez quelques options ici, n'ayez pas de flux et de retourner un tableau d'octets (vous pouvez le faire avec votre duplex service) ou vous pouvez simplement oublier de faire votre service duplex depuis il ne semble pas y avoir un dossier solide pour vous rendre duplex et il suffit de retourner un Flux:

    [OperationContract]
Stream RetrieveFile(long _fileId);
[OperationContract]
long SaveFile(Stream _stream);

    3. netTcpBinding a un considérable avantage de performance sur HTTP liaisons, mais il vient avec un prix, principalement parce que ses ports TCP sont parfois bloqués par le pare-feu internet, mais vous pouvez utiliser netTcpBinding sur internet, il n'est pas recommandé. Le choix d'une liaison dépend de ce que vous cherchez à faire, si vos clients vont consommer votre service sur internet, alors netTcpBinding n'est pas une bonne idée (bloqué les ports TCP, pare-feu etc.), mais si vos clients utilisent le service dans le même réseau local (LAN) puis netTcpBinding est la plus sensible de choix. wsDualHttpBinding (ne prend pas en charge le streaming :@) est un bon choix si vous voulez rester un duplex de service (l'équivalent de PollingDuplexHttpBinding en Silverlight), ou tout autre protocole HTTP liaisons si vous laissez aller de l'idée d'un duplex de service.

    Certains articles qui peuvent vous aider, comparaison des performances de différents WCF les liaisons:

    http://blog.shutupandcode.net/?p=1085

    http://tomasz.janczuk.org/2010/03/comparison-of-http-polling-duplex-and.html

    Et sur le Streaming de données de grande taille avec WCF sur HTTP, selon les auteurs, les deux échantillons ont été testés avec jusqu'à 2 go de données:

    http://garfoot.com/blog/2008/06/transferring-large-files-using-wcf/

    http://www.codeproject.com/Articles/166763/WCF-Streaming-Upload-Download-Files-Over-HTTP

    Vous ne devez pas penser que vous doit utilisation netTcpBinding ou vous devez utiliser en Streaming de transfert pour votre service, netTcpBinding ne devient plus performant que les liaisons HTTP après l'activation de la limitation et de la configuration de certains au niveau de la socket propriétés. Et streaming 40 MO ne pas avoir d'importants gains de performance par rapport tampon de transfert. Si vous avez beaucoup d'options et beaucoup de compromis à faire. Il n'y a pas de noir et blanc, bon ou mauvais, c'est comment vous pouvez personnaliser à votre service pour répondre à vos besoins mieux, la plupart des solutions de travail. Votre scenrio est très fréquent et il y a beaucoup de choses en ligne sur transfert de données volumineuses dans WCF, faire plus de recherches 😉

    • Eh bien, mes besoins sont d'environ 40 mo de fichiers, mais dans l'avenir, c'est probablement que j'ai besoin d'utiliser de plus gros fichiers, peut-être 500-1 000 MO. Aussi je ne comprends pas pourquoi la limitation de l'duplex contrat et de diffusion, dans une application de chat, aujourd'hui est commun à l'envoi de fichiers entre les clients et peut être des fichiers volumineux. Pourquoi choisir entre un bon transfert (streaming) ou un duplex application?
    • Ma conjecture est que l'arrière-et-vient de la communication n'est pas de bien jouer avec la notion d'un grand flux continu de données. Il n'y a également aucune raison pourquoi, et j'imagine que c'est le cas, que le chat lui-même est en duplex tandis que le fichier de la communication se fait via un service distinct avec différentes liaisons. Le serveur de chat peut même envoyer un avis à travers le canal duplex "hey, il y a un fichier à télécharger, allez l'obtenir via le canal de données"
    • La limitation de duplex+streaming aura certainement une technique de raisonnement derrière elle. Dans un chat applicaion vous pouvez avoir un duplex de service et d'envoyer vos fichiers comme un byte[], j'ai fait ça avant, et ça a bien fonctionné pour les fichiers de jusqu'à 100 mo. Dans votre cas, je ne pense pas que vous avez encore besoin d'un rappel. Regardez les 2 échantillons de transfert de fichiers volumineux, apparemment, les deux ont été testés jusqu'à 2 go, et en regardant le code, il ne semble pas trop difficile.
    InformationsquelleAutor Mohammad Sepahvand
  2. 7

    Vous avez besoin recto-verso si vous souhaitez mettre en œuvre rappel de modèle. Rappel signifie que le client ne sait pas quand un événement se produit dans le serveur.

    Si vous ne savez pas quand l'événement se produit, vous avez deux options à mettre en œuvre:

    1. D'interrogation - envoyer des demandes de toutes les X minutes pour vérifier si l'événement s'est produit. Serveur de rendre les détails de l'événement (si c'est arrivé) ou retour drapeau dire que vous avez besoin de continuer à demander. Le serveur peut également retourner recommandé de délai d'attente dans les scénarios avancés.
    2. De rappel - le client envoie une certaine forme de description de ce serveur doit faire si l'événement s'est produit. Ce peut-être un pointeur de fonction en C, délégué à .NET ou de point de terminaison de schéma dans WCF. Le serveur se souvient de cette info et fait appel de leur côté lorsque le temps est venu.

    Comme vous pouvez le voir recto-verso/rappel signifie qu'à un certain point de fonctionnement du serveur en tant que client (initie la communication) et c'est un grand jeu de changement.

    WCF duplex de communication pourraient nécessiter la configuration du réseau, car dans de nombreux cas, le réseau permet de faire appel aux services externes (vous travaillez en tant que client), mais interdit de ressources extérieures pour vous appeler (service externe fonctionne comme client). Ceci est mis en œuvre pour des raisons de sécurité.

    De retourner à vos questions:

    1. Vous n'avez pas besoin recto-verso si vous avez seulement besoin de télécharger de grandes quantités de données. Vous pourriez en avoir besoin si vous voulez attraper mises à jour qui s'est passé en serveur et informer les clients. Duplex devrait travailler pour le Chat, car dans le chat il y a de nombreux scénarios, quand le client a besoin pour être averti des modifications apportées par les autres.
    2. Ce que vous avez décrit est faite à la main variante de canal duplex. Vous devez utiliser prouvé et testé duplex de mise en œuvre prises par les états membres Si vous souhaitez que le serveur d'appeler votre méthode. Sinon, votre option est d'interrogation.
    3. Vous avez raison, vous avez besoin de tcp + diffusés en mode de transfert de traiter avec de grandes quantité de données. Le protocole TCP utilise la sérialisation binaire qui est plus compact comparant au texte de sérialisation + avec TCP vous n'avez pas besoin d'envoyer d'autres en-têtes HTTP ou SOAP enveloppe. Désactiver la sécurité si vous n'en avez pas besoin. Il a un gros impact sur les performances.
    InformationsquelleAutor Dmitry Harnitski