Discussion :

[LEK]

Bonjour,
j'ai une question toute bête : je developpe une application Asp.Net pour laquelle j'utilise actuellement du polling côté client pour que le serveur puisse tracker :
- les clients connectés
- et pusher des infos à afficher sur le client.

Chaque client (portable avec clé 3g : profil itinérant) appelle toute les 10 secondes, et j'ai du mettre en place un mécanisme côté serveur pour détecté les clients qui ont disparus du radar s'ils ne se sont pas manifestés depuis plus de 10 secondes...

Bref cela m'a fait implémenté pas mal de logique et consomme pas mal de ressource serveur. Donc j'ai pensé à utiliser SignalR pour utiliser les possibilités de détection d'un client déc/connecté et ne plus faire du poliing pour aller vers du temps réel...

La question que je me pose concerne la facture internet de mes clients : est-ce que cela leur reviendra plus cher d'être tout le temps connecté à un serveur sur internet ou bien le coût ne dépend que des infos qui transitent auquel cas les 2 solutions devraient revenir probablement à un coût similaire non ?
Désolé de la naiveté de la question mais merci pour toute info !

Lek.

[DotNetMatt]

La question que je me pose concerne la facture internet de mes clients : est-ce que cela leur reviendra plus cher d'être tout le temps connecté à un serveur sur internet ou bien le coût ne dépend que des infos qui transitent auquel cas les 2 solutions devraient revenir probablement à un coût similaire non ?

Non pas du tout. Faire du polling est la solution la plus ineficace qui puisse exister, puisque quoi qu'il arrive, tu vas faire communiquer avec ton serveur toutes les 10 sec, meme si ce n'est pas utile (par ex, aucun client n'a disparu du radar).

SignalR peut utiliser plusieurs modes de communication :

• WebSockets
• Long polling
• Forever Frame
• Server Sent Events

Par defaut, il va choisir le mode de transport le plus adapte, mais il est possible de le forcer si besoin.

Ensuite au niveau du fonctionnement, en gros le client envoie une requete AJAX au serveur qui attend de recevoir un signal pour y repondre, de maniere asynchrone (donc le client n'attend pas forcement une reponse immediate). Quand on recoit un signal, ou qu'on atteint le time out, SignalR va repondre au client avec le contenu de la reponse. Ensuite on ouvre une nouvelle requete, et ainsi de suite.

C'est donc bien plus optimise qu'un simple polling... Tu pourras trouver de la doc ici : Introduction to SignalR.

[LEK]

Bonjour,
merci pour le retour : je connais SignalR et son fonctionnement ainsi que la différence avec le polling que j'ai mis en place. La question que je me pose est plus liée au coût sur un abonnement 3g indexé sur la consommation : est-ce que le fait d’avoir une websocket ouverte en permanence ne fait pas monter le coût de cette facture?

Merci en tous cas pour les indications,
Lek

[DotNetMatt]

La question que je me pose est plus liée au coût sur un abonnement 3g indexé sur la consommation : est-ce que le fait d’avoir une websocket ouverte en permanence ne fait pas monter le coût de cette facture?

Je t'ai deja repondu : pour une meme quantite de donnees, non ca ne va pas faire monter le cout de la facture au contraire.

Le principe des WebSockets est de reduire la quantite de traffic HTTP/S echange. C'est le principal interet de cette technologie. Pour faire simple, lorsqu'on ne conserve pas la connexion ouverte, on est a chaque fois oblige d'envoyer de nombreux paquets HTTP/S a chaque communication.

Lorsqu'on ouvre une connexion sur un WebSocket, voici comment ca se passe.

Le client ouvre la connexion via un "handshake" avec le serveur. En gros, on envoie une requete HTTP/S classique.
Ensuite pour informer le serveur qu'on veut ouvrir un WebSocket, le client envoie une requete HTTP/S avec un entete Upgrade. Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
GET ws://websocket.tondomaine.com/ HTTP/1.1
Origin: http://tondomaine.com
Connection: Upgrade
Host: websocket.tondomaine.com
Upgrade: websocket

(Note, si on est en HTTPS, on va utiliser wss au lieu de ws).

Si le serveur supporte WebSockets, il va repondre avec quelque chose comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
HTTP/1.1 101 WebSocket Protocol Handshake
Date: Tue, 26 Sep 2017 20:00:00 GMT
Connection: Upgrade
Upgrade: WebSocket

Maintenant qu'on est connecte, la connexion HTTP va etre remplacee par une connexion WebSocket, qui va s'appuyer sur la connexion TCP/IP etablie. Cette connexion est dormante, tant que le client et/ou le serveur n'ont rien a envoyer, donc il n'y a aucune donnee qui transite.

A chaque fois que des donnees sont envoyees, elles sont transferees sous la forme de messages, chaque message contenant des "frames" qui contiennent les donnees. Chaque message est prefixe avec quelques bytes qui decrivent les donnees, pour faciliter leur reconstruction. Cela implique que les notifications ne sont recues/envoyees que lorsque la totalite des messages ont ete transferes et reconstruits. Ce mecanisme permet de ne transferer que le minimum vital de donnees...

A toi donc de t'assurer que toutes les notifications sont optimisees au maximum et que tu ne fais pas transiter de donnees inutiles.

Maintenant, ca me fait repenser a une situation a laquelle on avait du faire face il y a quelques annees : certains operateurs mobiles bloquaient les communications sur le schema WS ou WSS. Je ne sais pas si c'est toujours le cas aujourd'hui, en tout cas on avait abandonne SignalR pour un client, au profit d'un Message Bus.

L'avantage du Message Bus, c'est qu'il offre plus de fiabilite lors de la livraison des messages, et on reste sur un mecanisme de messages/notifications.

[LEK]

Merci pour ta réponse détaillée! Concernant ta remarque sur le bus de message : cela veut dire que comme alternative, je peux utiliser un bus de message exposé sur internet ? Il ne faut pas être dans un vlan commun pour que cela fonctionne ?

[DotNetMatt]

Concernant ta remarque sur le bus de message : cela veut dire que comme alternative, je peux utiliser un bus de message exposé sur internet ? Il ne faut pas être dans un vlan commun pour que cela fonctionne ?

Ca depend comment tu veux proceder. Il n'est pas raisonnable pour des raisons de securite d'exposer un bus sur internet, par contre derriere un Web Service WCF en full duplex, ca peut s'envisager ! Sinon le mieux rester de laisser le bus sur le LAN, et de connecter SignalR (cote serveur) dessus, c'est-a-dire de consommer les evenements du bus.

[LEK]

Merci pour les clarifications !