Voici quelques temps j’ai été confronté à des Timeout avec une petite application utilisant WCF. Cette application utilisait le binding wsDualHttpBinding en mode duplex. Tant que les deux parties de l’application se trouvaient sur la même machine cela fonctionnait correctement, mais lors de tests sur des machines différentes là cela ne marchait plus, timeout et encore timeout.

Mon application utilisait des méthodes « One Way » (IsOneWay = true) avec un contrat de callback, c’est-à-dire que toutes les méthodes du service étaient « void » et ne renvoyaient rien. Pour faire vite ce procédé permet de ne pas rester bloqué sur des méthodes en attendant la fin du traitement pour avoir une réponse. Ainsi quand un client envoie une requête vers un service il n’attend pas la réponse, le client se contente d’envoyer une requête et c’est tout, le service renverra la réponse une fois le traitement terminé en utilisant le contrat de rappel. Le contrat de rappel est implémenté par des méthodes côté client. Ainsi chaque côté utilise des méthodes qui ne retournent rien, la réponse à une requête revient par l’appel d’une autre méthode dans le sens opposé. Le fonctionnement est alors asynchrone, et vos applications ne tournent pas désespérément dans le vide, ou pire, restent bloquée en attendant une réponse.

Assez d’explications, revenons en au problème que j’ai rencontré. Quand les deux parties de l’application se trouvaient sur des machines différentes j’avais inévitablement un Timeout. Je vais vous expliquer pourquoi, vous allez voir c’est vraiment très bête mais en il est très facile de perdre une heure sur un tel détail…

Voici comment était configuré le binding côté client :

Vous avez trouvé l’erreur ? En fait il s’agit de l’url ! Celle-ci est définie avec localhost, ainsi quand le service veut répondre à cette adresse alors que le client se trouve sur une autre machine et bien il ne trouve tout simplement plus le client. Pour corriger cela il faut donc utiliser l’IP ou le nom de la machine où se trouve le client. Voilà à quoi ressemble le fichier de configuration une fois le problème corrigé :

Ainsi lors du callback le service sait à quelle adresse il doit rappeler le client. On voit donc qu’ici avec l’utilisation d’un binding qui gère le callback il est très important de renseigner correctement la « clientBaseAddress« . Il en va évidemment de même avec l’adresse du « Enpoint » côté service mais cela pas la peine de le préciser.

Voilà c’est tout bête mais il est facile de tomber dans le piège!

Au court de cet article je vais vous présenter Windows Communication Foundation, ou WCF, qui est une des grandes nouveautés du Framework.Net 3.0. WCF fournit un modèle de programmation unifiée pour construire des applications distribuées, WCF va permettre de faire communiquer des composants applicatifs se trouvant sur une même machine, mais le plus souvent sur différentes machines reliées en réseau.

Consulter l’article

Je vous rappelle que vous pouvez égalememt consulter mon domaine sur Developpez.com. Cette page liste tous mes articles sur .Net, SQL Server et Windows.

Au cours de cet article je vais vous présenter un aspect souvent peu abordé, il s’agit de la synthèse vocale. En effet, peu de développeurs ont eu un jour l’idée d’intégrer une telle fonctionnalité dans leur application… Pourtant, si l’on y réfléchit un peu cela pourrait s’avérer utile dans de nombreux domaines allant de la borne de musée interactive à une application de supervision d’un quelconque process. Quand un avertissement sonore doit être émis par une application la méthode le plus souvent employée est la lecture d’un fichier préenregistré, ici je vous propose de synthétiser de manière dynamique le message vocal. Pour réaliser cela vous aller voir que Microsoft nous simplifie grandement la vie. Depuis plusieurs années Microsoft propose gratuitement au téléchargement un SDK de reconnaissance et de synthèse vocale, depuis Windows Vista la donne a légèrement changée puisque tout cela est intégré au Framework .Net 3.0… Cet article porte uniquement sur le développement d’applications bâties autour de .Net 3.0, et donc ne s’appuyant pas sur la version 5.1 de SAPI (Speech API) employée pour les versions précédentes de Windows, mais sur la toute nouvelle version 5.3.

Accèder a l’article

Bonne lecture, de plus je vous rappelle que vous pouvez consulter l’intégralité de mes articles depuis cette page.