Accueil > Mobile, Web > Petit tour d’horizon des outils du temps réel

Petit tour d’horizon des outils du temps réel

Après m’être rendu fin avril à Lyon pour assister à l’excellente session 2013 de la Realtime Conference Europe, et comme il est d’usage dans pareil cas, je m’apprêtais à délivrer à chaud, sans latence, un compte-rendu circonstancié d’un évènement qui se sera avéré riche d’enseignements. Mais voilà, mon cerveau n’opérant pas, et croyez bien que je le regrette, en temps réel, je préfère finalement profiter de l’occasion pour dresser un petit état des lieux de ce qui sera comme nous l’avions pressenti en lançant le projet Hubiquitus il y’a deux ans un des principaux sujets d’innovation des années à venir dans l’univers du digital.

Mais de quel temps réel parle-t-on ici lorsque l’on évoque le temps réel ?

Supprimer les latences indésirables 

En informatique, la notion de temps réel fait traditionnellement référence à des « systèmes pour lesquels le respect des contraintes temporelles dans l’exécution des traitements est aussi important que le résultat de ces traitements ». L’important réside donc dans la prédictibilité temporelle, ce qui permet d’envisager des systèmes synchrones avec leur environnement, en général le monde physique, avec de nombreuses applications critiques (pilote automatique d’un Airbus par exemple). On parle aussi de temps réel strict ou « dur » (hard real time).

Mais dans l’écosystème du digital, le vocable « temps réel » est plutôt employé dans son acceptation courante, humaine du terme, soit « l’absence de latence perçue dans une interaction », comme par exemple dans la vidéoconférence ou dans le jeu en réseau. C’est ce que l’on appelle le temps réel souple ou « mou » (soft real time).

En fait, le temps réel dont nous parlons désigne deux choses distinctes:

  • la suppression de toute latence indésirable perçue par l’utilisateur
  • la fraîcheur des données utilisées

Ne pas trop en faire

Une attention toute particulière doit donc être portée à l’ergonomie des interfaces des applications temps réel. Notons au passage que la réactivité d’une interface peut être mal perçue. Si la sensation d’instantanéité améliore généralement  l’expérience utilisateur (c’est particulièrement le cas quand elle est implicitement recherchée comme dans la messagerie instantanée), à contrario une interface temps réel mal pensée peut également la dégrader: un rafraichissement trop rapide des données en empêchant la lecture ou encore des notifications interrompant l’utilisateur à tout bout de champ auront plutôt tendance à perturber voire exaspérer ce dernier. Si les latences indésirables doivent disparaître, conserver voire introduire d’autres latences (un effet de transition entre deux écrans par exemple) amélioreront l’expérience générale.

Penser « hors ligne »

Cela peut paraître curieux de parler du mode hors ligne dans un article sur le temps réel, mais c’est finalement bien la première des contraintes à prendre en compte à l’heure où nous utilisons toujours plus nos applications en mobilité. Parce que les réseaux mobiles ne sont pas un cadeau : couverture incomplète, débit pratique très loin du théorique, latence parfois effarante, frais d’itinérance confiscatoires, sont autant de réalités avec lesquelles il faut composer.

Le temps réel est une « perception », rappelons-le encore. L’interface d’une application temps réel doit donc être aussi réactive connectée que hors ligne. Cela signifie qu’il faut concevoir des interfaces qui exploitent le réseau de façon asynchrone :

  • En effectuant toutes les interactions réseau en tâche de fond
  • En stockant certaines données en local de façon à les rendre toujours disponibles pour l’utilisateur
  • En autorisant la modification hors ligne de ces données (écrire un mail par exemple)
  • En resynchronisant l’état de l’interface en tâche de fond lorsque la connexion est rétablie

Penser « messages »

La façon dont nous concevons usuellement les applications digitales est dominée par les interactions synchrones de type « requête-réponse » : une interface cliente émet une requête auprès d’un serveur distant qui lui renvoie après traitement une réponse. Dans ce modèle, l’utilisateur est souvent contraint d’attendre que la réponse lui parvienne en retour pour poursuivre son utilisation.

Ce modèle ne permet pas d’atteindre la perception du temps réel. Si un évènement temporel survient, le serveur n’est pas en mesure d’en avertir l’interface et doit attendre qu’elle émettre une nouvelle requête, ce qui introduit une latence indésirable. Il est bien sûr possible de gommer cette latence perçue en augmentant la fréquence des requêtes (ce que fait par exemple un site web comme lequipe.fr) mais cela n’est guère satisfaisant.

Pour parvenir à une réduction significative de la latence perçue, il nous faut pouvoir notifier l’interface sans attendre une nouvelle requête : il faut pouvoir lui envoyer un message.

Utiliser les protocoles adaptés

Plusieurs protocoles de messagerie temps réel ont ainsi vu le jour permettant d’activer un canal de messagerie bidirectionnel persistant entre un client et un serveur, et parfois directement entre deux clients :

  • Comet: Comet désigne une famille de protocoles qui détournent HTTP de sa fonction première pour émuler une connexion bidirectionnelle ; très utilisés car compatibles avec pratiquement tous les navigateurs web, ces protocoles induisent cependant une surconsommation importante en ressources qui les rend peu adaptés à un usage en mobilité.
  • XMPP. Standard de la messagerie instantanée, XMPP est le pionnier des standards du temps réel; les clients peuvent communiquer directement entre eux à l’aide de messages XML via une passerelle serveur. XMPP s’appuie sur un protocole de transport spécifique (deux connexions TCP persistantes, une pour le trafic montant et l’autre pour le trafic descendant) mais peut également être employé sur le web à l’aide d’un protocole de type Comet appelé BOSH.
  • WebSockets. Standard supporté par la majeure partie des navigateurs web modernes, WebSockets est le plus simple de ces protocoles ; les clients se connectent simplement à un serveur à l’aide d’une unique connexion TCP bidirectionnelle (full-duplex) qui permet de transmettre des messages descendants et montants.
  • WebRTC: standard émergent pour la communication audiovisuelle sur IP à l’aide d’un simple navigateur web sans plugin, WebRTC privilégie quant à lui des connexions paire-à-pair directe entre clients destinées à véhiculer des flux binaires et non des messages (WebRTC inclut cependant un canal data complémentaire pour ce besoin spécifique).
  • MQTT: issu du monde du M2M, ce protocole est maintenant utilisé par certains acteurs du digital comme Facebook qui l’exploite notamment pour ses applications mobiles (Facebook Messenger); il ne peut pas être exploité sur le web.

Parmi tous ces protocoles, WebSockets est à ce jour le protocole qui remporte le plus d’adhésion de la part de la communauté qui plébiscite sa simplicité et ses excellentes performances. Supporté nativement par les navigateurs web, il peut d’ores et déjà être employé pour construire les applications digitales temps réel d’aujourd’hui, qu’il s’agissent de webapps ou non.

Pour autant, WebSockets se heurte à un environnement réseau pour le moins hostile:

  • Proxies et firewalls bloquent environ dans 1 cas sur 4 les connexions WebSockets
  • Les réseaux cellulaires interdisent très souvent son utilisation, ce qui le rend difficilement exploitable en mobilité

C’est là que des frameworks comme SocketIO ou SockJS interviennent. Ces bibliothèques réseau multi-protocoles sélectionnent dynamiquement la meilleure option de façon transparente pour le développeur qui n’aura qu’une seule API à implémenter: lorsque la liaison WebSocket ne fonctionne pas, des techniques de contournement basées le plus souvent sur Comet sont employées (Flash polling, XHR polling, HTTP Long polling, JSON padding, etc.).

Se constituer un framework temps réel

Disposer d’un protocole temps réel pour pousser des messages aux utilisateurs ne suffit  pas à concevoir une application temps réel.

L’architecture d’une application temps réel doit être centrée sur le traitement et la propagation sans latence de flux d’évènements, ce qui nécessite d’employer des solutions différentes de celles que nous avons l’habitude d’utiliser.

On trouve ainsi sur le marché de plus en plus de solutions, souvent open source, qui intègrent spécifiquement cette contrainte du temps réel :

  • Des bibliothèques réseau (ZeroMQ, Boost.io, Netty, Mina)
  • Des middlewares de messagerie (ejabberd, RabbitMQ)
  • Des caches de données (Redis, Memcached)
  • Des framework orientés flux d’évènements (Esper, Storm, S4, Dempsy, Hubiquitus)
  • Des serveurs web asynchrones (NodeJS, Mongrel2)
  • Des framework web temps réel (SocketStream, XSockets)

Qu’on se le dise : l’architecture des applications temps réel n’aura plus grand chose à voir avec celle des applications web et mobiles des années passées !

Conclusion

L’écosystème du temps réel progresse à grande vitesse et il ne fait aucun doute que la profusion des outils désormais disponibles a réduit significativement le coût d’implémentation de ses applications.

Pour autant, les applications temps réel ne sont pas légion. Le terrain nous l’a montré, la problématique du temps réel réside désormais moins dans la difficulté technique qu’elle occasionne que dans la capacité des développeurs à imaginer des cas d’usage pertinents…et à convaincre leurs utilisateurs.

On en reparle l’année prochaine pour la session 2014.

Categories: Mobile, Web Tags:
  1. Pas encore de commentaire
  1. Pas encore de trackbacks


+ 8 = neuf