Discussion :

[Kropernic]

Hello,

Je vais prochainement être amené à développer une application client/serveur en utilisant la techno WCF.

N'ayant jamais utilisé cette techno, je recherche donc des conseils concernant les bonnes pratiques à respecter.

J'ai joué un peu avec en suivant un tuto pour faire un chat mais rien de bien folichon.

La question principale que je pose est de savoir s'il vaut mieux laisser le client connecté au serveur non-stop ou s'il faut le déconnecté après chaque demande.

Y a-t-il une limite au nombre de canaux ouverts ?

[DotNetMatt]

La question principale que je pose est de savoir s'il vaut mieux laisser le client connecté au serveur non-stop ou s'il faut le déconnecté après chaque demande.

Y a-t-il une limite au nombre de canaux ouverts ?

Oui c'est comme pour ADO.NET, il vaut mieux ouvrir puis fermer dès qu'on a terminé.

Dans certains scénarios, type batch, tu peux aussi mettre tes opérations en queue, puis ouvrir ta connexion, les exécuter et enfin fermer... L'idée derrière c'est que dès que tu n'as plus besoin de la connexion, tu dois la fermer, exactement comme en SQL.

1 canal = 1 connexion, et il y a une sorte de connection pool (comme en SQL) qui s'occupe de gérer les connexions. A noter, les connexions ne sont pas thread-safe ! Il n'est en général pas conseillé de réutiliser les canaux, il vaut mieux en créer un à chaque fois que tu en as besoin. Ce n'est pas coûteux. L'opération la plus coûteuse est de créer la ChannelFactory, qu'il vaut mieux garder en cache pour la réutiliser lorsqu'on veut créer un canal.

[Kropernic]

Comme quoi, j'ai bien fait de poser la question aussi sur le forum.

Avant de venir ici, je suis allé faire un tour sur le chat. Là, on m'a dit qu'il valait mieux laisser ouvert et fermé une fois tout fini.

Sinon, si je compare avec le tuto du chat, là, on laisse effectivement ouvert. Mais WCF a un timeout par défaut à 10 minutes en cas d'inactivité. Mais le chat est p-e un cas particulier.

L'application que je vais devoir faire devra aller récupérer des informations de tickets de caisses. Donc une fois la requête envoyée et la réponse reçue, c'est vrai que je n'aurai plus besoin de la connexion avant quelques minutes. Donc autant la fermer. C'était ma première intuition et tu la confirmes. Donc ça c'est bien.

D'autres choses auxquelles il faut faire attention avec WCF ? Des trucs particuliers qui ne sont pas forcément intuitifs ? (le genre de truc qu'on se dit après coup "fallait le savoir!")

[DotNetMatt]

Mais le chat est p-e un cas particulier.

En effet par exemple si tu utilises des mécanismes tels que full duplex ou autre, ca peut varier. Je répondais d'une manière générale pour des scénarios classiques

D'autres choses auxquelles il faut faire attention avec WCF ? Des trucs particuliers qui ne sont pas forcément intuitifs ? (le genre de truc qu'on se dit après coup "fallait le savoir!")

Avec WCF il y a plein de choses à savoir, donc difficile de te faire liste exhaustive, le mieux c'est de se casser les dents dessus Un truc quand même très important, les exceptions ne vont pas remonter jusqu'à ton client, du moins pas toutes. Donc le débuggage peut être compliqué et lourd parfois... En gros la plupart des fois où tu n'as pas de message très précis, il faut que tu regardes du côté du serveur.

[Kropernic]

Le serveur devrait à priori (pas encore vraiment fait d'analyse) être trèèèèèèès simple.

Il devrait se contenter de

1. Recevoir :

• un numéro de magasin
• une date
• un numéro de caisse
• un numéro de ticket

2. Faire la requête vers le serveur approprié (déterminé en fonction du numéro du magasin) pour récupérer les infos du ticket

3. Renvoyer le ticket vers le client (ce sera une classe qui contiendra toutes les infos nécessaires)

Donc niveau erreur côté serveur, ça devrait aller ^^.

Ce que je redoute le plus, ce sont les problèmes de communication entre clients et serveur car je n'y connais pas grand chose en réseau et quand bien même, je n'ai pas la main dessus pour pouvoir administrer quoi que ce soit...

[DotNetMatt]

Donc niveau erreur côté serveur, ça devrait aller ^^.

Tant mieux alors ! C'est souvent ce que je me dis aussi mais bizarrement il y a toujours quelque chose qui ne marche pas

Ce que je redoute le plus, ce sont les problèmes de communication entre clients et serveur car je n'y connais pas grand chose en réseau et quand bien même, je n'ai pas la main dessus pour pouvoir administrer quoi que ce soit...

Ca tu peux (et tu dois ) le planifier avec ton équipe réseau. Pour chaque serveur il faut recenser la liste des ports nécessaires (ex. 80 pour HTTP, 443 pour HTTPS, 1433 pour SQL Server, etc.) et tu leur envoie en leur demandant s'il y a quelque chose (firewall, reverse proxy, etc.) qui puisse bloquer les communications entre les machines sur ces ports.