Déterminer le temps nécessaire à l'envoi de messages avec WCF net.tcp

Question

Je suis en train d'écrire un prototype d'application distribuée compatible WCF, pour essayer de trouver les problèmes que j'aurais à mettre à jour mes applications existantes "envoyant du xml sur tcp pour communiquer" que j'ai. J'utilise des Callback Contracts pour enregistrer les clients auprès d'un serveur (Singleton dans ServiceHost) et jusqu'à présent toutes les communications entre le client et le serveur fonctionnent. Je peux connecter plusieurs clients au serveur et envoyer un broadcast depuis le serveur qui sera reçu par tous les clients. Je peux bloquer un client particulier et les autres clients reçoivent toujours les appels. C'est une bonne chose.

Pour poursuivre mon apprentissage et l'évaluation des performances, j'aimerais que le client enregistre l'heure à laquelle le serveur envoie chaque message, ainsi que l'heure à laquelle le client reçoit ce même message. Quelle est la meilleure façon de procéder ?

Existe-t-il quelque chose de similaire aux extensions SOAP, où je peux ajouter à la sortie du serveur et à l'entrée du client ? Ou dois-je ajouter un paramètre "timeSent" à chaque méthode que le serveur appelle sur le client et enregistrer l'heure reçue sur le client (beurk !)? Existe-t-il un meilleur moyen d'y parvenir ?

J'utilise net.tcp plutôt que wsDualHttpBinding (qui fonctionne également mais est moins performant).

Answer 1

Hmmm... c'est une question difficile. Le problème ici est que vous ne pouvez même pas vous assurer que les minuteries du client et du serveur sont synchronisées.

Si vous souhaitez envoyer des données hors bande, sans avoir à modifier vos méthodes, vous pouvez utiliser la méthode proposée. aquí . Je pense que cela devrait suffire.

Answer 2

David a raison en ce qui concerne les problèmes de synchronisation des horloges. Cependant, l'ajout de l'information d'horodatage en dehors de l'implémentation du service/client n'est pas du tout difficile avec WCF.

Vous avez raison, il ne prend pas en charge les SoapExtensions, bien qu'en fait, il dispose d'un ensemble beaucoup plus riche de points d'extension. Dans votre cas spécifique, je pense qu'un comportement personnalisé qui ajoute un MessageInspector fonctionnerait probablement.

Il existe en fait deux interfaces d'inspecteur de messages : L'une pour le client ( IClientMessageInspector ), et un pour le serveur ( IDispatchMessageInspector ).

La façon la plus simple de connecter un inspecteur de distribution du côté du service est par le biais d'un comportement de service (IServiceBehavior), puisque vous pouvez le connecter à votre implémentation de service en tant qu'attribut personnalisé. Voici un comportement de service exemple simple de la manière de le faire. Vous pouvez également l'accrocher par le biais d'un IEndpointBehavior, mais vous devez le faire soit par le code lors de la mise en place de l'hôte du service, soit par la configuration, ce qui nécessite l'écriture d'un peu plus de code.

Du côté client, vous utilisez toujours un comportement de point final, mais il est beaucoup plus facile de l'introduire dans le code puisque vous avez un accès direct au ClientRuntime à partir du client proxy.

Quoi qu'il en soit, je pense qu'il est préférable d'ajouter un horodatage au message sous la forme d'un en-tête personnalisé, de sorte qu'il ne fasse pas directement partie de la charge utile du message.