L'interopérabilité correspond aux possibilités de plusieurs systèmes à communiquer, partager et fonctionner ensemble. Il s'agit ici des interactions possibles entre les périphériques que nous utilisons.
Je suis parti d'une simple mais triste constatation. Nous utilisons au quotidien plusieurs périphériques tous plus ou moins intelligents comme notre ordinateur (de bureau et/ou portable), notre tablette, notre smartphone, notre smart TV. Nous pouvons faire d'incroyables choses avec ces périphériques, mais dès qu'il s'agit de transférer des données entre eux, tout devient compliqué. Qui ne s'est jamais envoyé un mail pour transférer un fichier d'une machine à l'autre ? Qui ne s'est jamais retrouvé en galère de clé USB au moment de transférer des données importantes ?
A l'heure où toutes nos machines sont interconnectées grâce à Internet où grâce à notre chère Box sur le réseau local, il est difficile voire impossible de transférer efficacement et automatiquement des fichiers, des contacts, des messages ou toute autre donnée.
J'ai écrit cet article pour faire l'état des lieux des techniques disponibles permettant la communication entre périphériques. Cela me permettra de commencer à réfléchir puis à développer un système qui apportera une solution à ces problématiques.
Commençons par établir une liste des périphériques où le problème de l'interopérabilité peut se poser. On peut évidemment y compter l'ensemble des machines « intelligentes », c'est-à-dire les systèmes où il est possible d'ajouter et de développer des applications supplémentaires.
On peut également y ajouter des périphériques « connectés » à l'aide d'un réseau ou d'un protocole existant, comme par exemples les téléviseurs compatibles DLNA, ou encore certaines Box offrant des services FTP, SMB ou autres. Bien que le développement et l'ajout de composants soient impossibles sur ces plateformes, il serait néanmoins très intéressant de les intégrer dans notre système de périphériques interconnectés.
Voici une liste non exhaustives des périphériques que je viens de décrire :
Passons maintenant aux données concernées par ces échanges. On citera tout de suite les fichiers que j'ai donnés en exemple tout à l'heure. Voici une liste non exhaustive des interactions possibles lors de ces échanges :
Bien que pour la plupart des utilisateurs, l'intérêt d'un tel travail résiderait uniquement dans les échanges de fichiers et de médias, il me paraît très intéressant de penser à inclure les autres interactions de cette liste. Certains auraient une utilité directe, comme le partage de la souris et du clavier, mais d'autres, comme les capteurs et les évènements, permettraient de développer de nouvelles applications assez intéressantes.
Certains d'entre vous me dirons qu'ils connaissent de nombreuses solutions comme les logiciel de synchronisation comme Drop Box ou Google Drive, ou encore l'utilisation d'un disque réseau comme intermédiaire. Il existe certes des solutions à certaines des interactions citées ci-dessus, mais aucune d'entre elle ne les propose ensemble et bien intégrées aux systèmes que nous utilisons. Voici divers exemples de solutions apportées :
C'est pour le transfert de fichiers qu'il existe le plus de solutions tierces. En effet, si l'on a deux périphériques connectés sur un réseau commun, il existe de nombreux protocoles permettant les échanges de fichiers : SMB, FTP, WebDAV, NFS, SFTP, HTTP. En cas de connexion directe entre deux appareils, il existe d'autres protocoles : MTP, PTP pour les connexions filaires et OBEX par exemple pour les connexions sans-fils.
Chaque périphérique supporte ainsi ses protocoles, et lorsque deux d'entre eux supportent un protocole commun, ils peuvent alors interagir.
Pour les fichiers, il existe également d'autres méthodes consistant à utiliser un stockage tiers. Les logiciels de synchronisations, les serveurs de fichiers en font partie. Il ne s'agît pas de transferts directs, mais ils proposent néanmoins une solution en proposant une interface commune entre les périphériques.
En ce qui concerne les médias, un protocole s'est largement développé ces dernières années, permettant ainsi aux consoles de jeux, aux téléviseurs, aux ordinateurs de partager des contenus audio et vidéo de façon simplifiée, il s'agit du DLNA. La problématique est ici le manque de compatibilité de certains flux audio et vidéo entre périphériques, mais aussi le fait que certains périphériques ne supportent tout simplement pas le DLNA.
Quelques autres protocoles permettent le partage multimédia, comme HTTP, MMS, RTMP. Certains peuvent être moins connus, mais ils sont tout de même très utilisés sur internet, par exemple pour la diffusion de programmes de télévision et de radios.
Pour les autres interactions, il n'existe pas forcément de protocoles normalisés et utilisés. Comme il s'agit de transmettre plusieurs types d'informations, on pourra citer les protocoles classiques permettant l'envoi de données comme TCP, UDP, ou encore des protocoles plus haut niveau comme SOAP, REST ou WCF.
Ici, le travail reste à faire. Néanmoins, certaines des interactions restantes peuvent être assimilées à des services et donc traitées comme tel, grâce à des Web Services par exemple.
Maintenant que nous avons les protocoles et les techniques utilisés pour les différentes interactions et les problématiques qu'ils soulèvent, il serait intéressant de réfléchir à la solution à apporter pour harmoniser le tout si cela est possible.
Il existe de nombreuses façons de connecter des périphériques entre eux, et toutes ont leurs avantages et leurs inconvénients. Voici un petit tableau récapitulatif pour donner une idée des différentes connexions et de leur potentiel. Je ne garantis pas l'exactitude des données dans tous les cas, mais c'est à peu près ce que j'ai pu constater en général.
| Nom | Latence | Vitesse | Disponibilité | Fiabilité |
|---|---|---|---|---|
| Internet | Moyenne | Basse | Haute | Faible |
| Réseau local | Basse | Moyenne | Haute | Haute |
| Bluetooth | Haute | Basse | Moyenne | Moyenne |
| Wi-Fi direct | Moyenne | Haute | Moyenne | Moyenne |
| USB | Basse | Haute | Ponctuelle | Haute |
On peut remarquer que les connexions les plus communes ne sont pas les plus rapides, ni même les plus fiables. L'idéal serait donc d'adapter le type de connexion en fonction de l'utilisation souhaitée. Il n'est pas forcément important de toujours avoir la meilleure vitesse. Pour transférer de faibles quantités de données comme des notifications ou des messages, il est beaucoup plus intéressant de miser sur une faible latence que sur une haute vitesse.
La solution devrait donc utiliser la meilleure connexion au moment où l'on en a besoin. Il serait alors intéressant d'avoir une idée en temps réel des propriétés d'une connexion donnée. Par exemple, la connexion au réseau local dépend grandement de son utilisation par d'autres périphériques connectés, et son éventuelle utilisation par la solution idéale peut nuire à la connexion des autres périphériques du réseau.
De même, lorsque plusieurs connexions sont disponibles, il serait très intéressant de pouvoir en changer à la volée si une autre s'avère plus rapide. Par exemple, si lors du transfert d'un gros fichier entre un téléphone portable et un ordinateur en Wi-Fi, on connecte les deux grâce à un câble USB, il faudrait utiliser automatiquement l'USB plutôt que le réseau, pour plus de vitesse et une charge moins importante du réseau local.
Cette technique nécessiterait donc l'utilisation d'un protocole commun aux différentes connexions. Ce ne serait pas forcément possible en utilisant les protocoles connus à l'heure actuelle, mais il serait très intéressant de l'implémenter dans un nouveau protocole commun.
La première étape afin que deux périphériques puissent communiquer entre eux est la découverte, il faut que les périphériques aient conscience l'un de l'autre et de la méthode pour communiquer entre eux. Pour la connexion USB, cela est évident, il suffit que le câble soit connecté pour pouvoir communiquer. Pour d'autres connexions comme le Bluetooth ou encore le Wi-Fi Direct qui disposent déjà de systèmes de découverte et d'association, il n'y a pas de problèmes. Dans le cadre d'un réseau local, il faudra faire une découverte manuelle grâce au broadcast, on envoie un message sur l'ensemble du réseau et les périphériques qui le reçoivent retournent une réponse à l'expéditeur.
Ces différentes techniques devraient être automatisées au sein d'une même solution qui pourra répertorier les périphériques accessibles, les différentes connexions pour accéder à chacun d'entre eux.
Ensuite, il faut s'attarder sur la création d'un système d'authentification unifié. En effet, si un seul utilisateur physique utilise plusieurs machines, chacune d'entre elles auront un utilisateur correspondant. En général, chaque machine, et chaque service possède sa base d'utilisateurs. L'idéal serait ici d'avoir un unique utilisateur représentant l'utilisateur physique, qui servirait à se connecter à l'ensemble des machines et de leurs services avec les droits correspondants.
J'ai parlé du fait qu'il serait intéressant d'intégrer les périphériques « non intelligents » comme les Smart TV, les box et certains NAS dans la solution. Concernant les périphériques avec partage de fichiers du style SMB ou FTP, mon idée est de créer un périphérique « virtuel » passif exposant les services configurés manuellement en fonction des partages.
Si le périphérique « non intelligent » est découvrable sur le réseau, le périphérique « virtuel » correspondant sera créé automatiquement et les services seront exposés automatiquement. Aussi, ils apparaîtront comme les autres et seront accessibles normalement. Cela permet de ne pas avoir à gérer des cas particuliers dans la solution.
Pour cette partie, je n'évoquerais que le partage de fichiers, et plus précisément l'exploration. Alors que la plupart des logiciels fournissent leur propre interface pour la gestion des fichiers, je souhaite intégrer le mieux possible la solution au système d'exploitation sur lequel elle est exécutée.
Sous les plateformes Unix (Mac OS X et autres linux), il existe un outil appelé FUSE permettant de développer ses propres systèmes de fichier et de les monter. Il s'agit alors ici de créer un système de fichier virtuel entièrement géré par la solution. Un service s'exécutant sur une machine Unix peut s'occuper de la découverte et de la gestion des protocoles, et monter automatiquement les périphériques détectés. Dès qu'un utilisateur ou un programme tente d'accéder à ce point de montage, les échanges avec le périphérique physique sont alors exécutés.
Il existe des équivalents de FUSE sous les plateformes Windows comme CBFS ou encore Dokan, qui reste à mon avis la meilleure solution open-source à l'heure actuelle même si les développeurs ne sont plus actifs. Mais n'hésitez pas à réagir si vous en connaissez de meilleurs. Dokan, tout comme FUSE, permet de monter un lecteur sous Windows avec un système de fichier virtuel, géré par une application. En suivant le même principe, le service faisant tourner la solution s'occuperait de monter automatiquement les périphériques détectés, ou simplement les favoris. Le service s'occuperait alors d'échanger avec le périphérique physique au besoin.
Concernant les périphériques mobiles Android, il est nécessaire d'avoir un kernel compilé avec FUSE pour faire fonctionner de telles solutions. Heureusement, depuis la version 4.4 KitKat sortie récemment, Android met à disposition le « Storage Access Framework » qui permet à l'utilisateur une façon unifiée de parcourir les fichiers. Ainsi, une application ou un service peut fournir au système un « fournisseur de document » personnalisé et géré dynamiquement pour parcourir les fichiers. La meilleure solution serait d'ajouter un fournisseur qui référence les différents périphériques accessibles.
La prochaine étape est le développement d'un prototype. Je vais me concentrer sur les échanges de fichiers entre un ordinateur sous Windows 8.1 et un smartphone sous Android 4.4, le matériel que je possède actuellement. Au niveau des interfaces, je traiterais le réseau en premier lieu et je tenterai ensuite d'intégrer les communications USB, qui n'ont pas l'air si simples.
Vous pourrez trouver ci-dessous quelques idées et pistes de réflexion pour l'implémentation que je vais réaliser.
L'idée ici est de créer des groupes d'utilisateurs physiques pour n'avoir qu'un utilisateur virtuel. Lorsqu'un périphérique A se connecte à un périphérique B, A précise l'utilisateur physique et l'utilisateur virtuel. Si la personne utilisant B veut s'associer à l'utilisateur virtuel, il l'enregistre et notifie A de son choix. Dès lors, A et B possèdent tous deux leurs utilisateurs physiques associés au même utilisateur virtuel. Du fait que l'utilisateur virtuel soit identifié de manière unique, chaque nouveau périphérique pourra aisément s'associer aux autres utilisateurs. Les périphériques n'auront qu'à utiliser l'unique utilisateur virtuel dans les bases d'utilisateurs.
Par exemple, prenons les périphériques et les utilisateurs physiques suivants (il s'agit d'une seule personne nommée Alice utilisant des périphériques et ayant des comptes sur chacun d'eux) :
| Ordinateur portable | Lili |
|---|---|
| Smartphone | Alice Rondeau |
| Ordinateur de bureau | Alice R. |
Voici un scénario pour illustrer la notion d'utilisateurs virtuels :
A cette étape, l'Ordinateur portable et le Smartphone savent qu'Alice comprend Lili et Alice Rondeau
Ici, l'Ordinateur de bureau et le Smartphone savent qu'Alice comprend Alice Rondeau et Alice R.
Cette vision permet alors de diffuser simplement des utilisateurs virtuels sans pour autant devoir reconfigurer l'ensemble des périphériques concernés. Ainsi, nous disposons d'une base d'utilisateurs unifiés et chaque périphérique se contentera de gérer les droits de ces utilisateurs virtuels.
Ici, nous nous situons dans le cadre des communications entre un périphérique hôte (l'ordinateur par exemple) et un périphérique accessoire (un smartphone). Par défaut sur la plupart des smartphone, le protocole MTP est activé de base. Il s'agit donc d'établir un canal de communication en parallèle du protocole par défaut. Voici les quelques pistes que j'ai pu rassembler jusqu'à présent :
Voilà un bon résumé des recherches que j'ai fait jusqu'à présent. J'ai écrit cet article afin de montrer les limites des solutions existantes et que l'interopérabilité entre les systèmes existants est vraiment limité à l'heure actuelle. Il est vraiment dommage de constater ça alors que de nos jours, tous nos périphériques sont interconnectés.
J'ai également un autre projet de développement d'un système d'exploitation. Je ne sais pas s'il sera utilisable un jour, mais il serait particulièrement intéressant de voir une solution à ces problèmes intégrée directement au cœur d'un OS.
J'espère pouvoir continuer sur cette lancée et apporter une solution fonctionnelle, tout d'abord pour apporter une solution aux besoins de partage de fichiers, puis en proposant de nouveaux outils pour développer plus efficacement des projets basés sur plusieurs périphériques.
Je cherche également à travailler sur cette problématique ou d'autres liées pour un sujet de recherche par exemple. Je suis actuellement à la recherche de professeurs ou d'autres personnes intéressées par l'architecture logicielle en général pour collaborer au cours d'un stage ou autre. N'hésitez pas à me contacter à l'adresse suivante : julien.batonnet (at) gmail (dot) com
En espérant que ce sujet vous ai intéressé, merci à tous de votre lecture !