FR 2868644 A1 20051007 FR 0403339 A 20040330 Méthode de découverte d'appareils connectés à un réseau IP et appareil implémentant la méthode. La présente invention concerne les réseaux IP ( Internet Protocol en anglais décrit dans la RFC791 et plus particulièrement les réseaux locaux, par exemple les réseaux domestiques. Elle concerne la façon dont les appareils connectés à de tels réseaux obtiennent et gardent à jour la connaissance des autres appareils compatibles connectés au réseau. Dans le domaine des réseaux domestiques utilisant la technologie IEEE 1394, un bus de haute performance décrit dans le document: "IEEE Std 13941995 High Performance Bus, 1996-08-30", la connexion ou la déconnexion d'un appareil du réseau provoque la réinitialisation du bus et par-là même une phase de découverte des appareils connectés. Sur un réseau de type IP la connexion ou la déconnexion d'un appareil ne provoque aucune activité particulière sur le réseau susceptible d'être détectée par les autres appareils. Certaines applications ou certains protocoles nécessitent pour un appareil connecté à un réseau de connaître les autres appareils participant à cette application ou implémentant le même protocole. Nous pouvons citer par exemple le protocole de protection anticopie de contenus numériques SmartRight décrit par exemple dans la demande de brevet européen publiée sous le numéro EP 1 253 762 Al. Les appareils implémentant ce protocole se doivent de détecter l'arrivée d'un nouvel appareil compatible avec ce protocole sur le réseau de façon à pouvoir lancer une étape de gestion des clés assurant la cohérence du réseau. Des protocoles de découverte de services existent sur le réseau IP, comme le protocole simple de découverte de services SSDP (pour Simple Services Discovery Protocol en anglais), décrit dans le document draft-cai-ssdp-v1-03.txt disponible auprès de l'IETF ( Engineering Internet Task Force en anglais). Mais ce protocole, outre le fait qu'il est orienté vers la découverte de services et en particulier de services HTTP et non d'appareils, ne garantit pas la détection rapide et à coup sûr de l'arrivée d'un appareil sur le réseau. En effet, cette détection est basée sur l'envoi d'un message d'annonce par l'appareil arrivant sur le réseau, ce message étant envoyé en utilisant le protocole de transmission de datagrames UDP ( User datagram Protocol en anglais décrit dans la RFC768). Or ce message d'annonce peut ne jamais être reçu par les appareils du réseau car le protocole UDP est non sécurisé et ne garantit pas contre la perte possible du message. De plus ce protocole repose généralement sur un événement signalant la connexion, cet événement étant généré par la couche de contrôle de l'accès au support (MAC pour Medium Access Control en anglais). D'autres protocoles, comme le protocole de configuration dynamique d'hôte DHCP (pour Dynamic Host Configuration Protocol en anglais), permettent à un appareil arrivant sur le réseau d'obtenir des informations sur celui-ci. Mais outre que ces protocoles n'offrent pas le moyen, une fois connecté, d'être averti de la connexion ultérieure de nouveaux appareils, ces protocoles ont un fonctionnement client serveur, classique dans le monde IP mais non pertinent dans notre cas. En effet il est souhaitable qu'aucun appareil ne joue de rôle privilégié pour notre application excluant l'utilisation d'un serveur centralisant la gestion du réseau. Le problème se pose donc de trouver une méthode, sur IP, indépendante des couches réseau sous jacentes et permettant de détecter l'arrivée sur le réseau et le départ du réseau d'appareils implémentant la même méthode. Cette méthode ne peut reposer sur la présence d'un serveur assumant un rôle de gestion du réseau de façon à pouvoir fonctionner entre tous les appareils implémentant la méthode sans configuration préalable de manière simple et immédiate. L'invention permet donc à des appareils implémentant la méthode de découvrir rapidement sa propre connexion au réseau ainsi, qu'une fois connecté, l'arrivée d'un nouvel appareil compatible sur le réseau. L'invention permet également, dans un mode particulier de réalisation, de maintenir la liste des appareils compatibles connectés et de découvrir le départ d'appareils compatibles du réseau. 2868644 3 L'invention concerne une méthode de découverte, par un appareil destiné à être connecté à un réseau IP, des appareils implémentant ladite méthode et connectés audit réseau. Cette invention comporte une étape où l'appareil étant considéré dans un état déconnecté, il envoie des requêtes de manière répétée et automatique sur le réseau IP. L'invention comporte également une étape où le basculement dans un état connecté sur la réception, par l'appareil, d'au moins un message selon la méthode de la part d'un autre appareil. Selon un mode particulier de l'invention, sur réception d'une requête en provenance d'un autre appareil, l'appareil envoie une réponse sur le réseau. Selon un mode particulier de l'invention l'appareil, étant dans un état connecté, et ne recevant pas de message selon la méthode pendant un premier temps donné, va envoyer une requête sur le réseau IP et basculer dans un état d'attente de message. Selon un mode particulier de l'invention l'appareil, étant dans un état d'attende de message, et ne recevant pas de message selon la méthode pendant un second temps donné, va basculer dans l'état déconnecté. Selon un mode particulier de l'invention l'appareil, étant dans un 25 état d'attente de message et recevant un message selon la méthode, va basculer dans l'état connecté. Selon un mode particulier de l'invention l'appareil envoie les messages selon la méthode selon un mode de diffusion multipoint à une adresse et un port connu et où l'appareil écoute à cette adresse et sur ce port. Selon un mode particulier de l'invention l'appareil, étant dans l'état d'attente de message et ne recevant pas de messages selon la méthode, va réitérer un nombre donné de fois l'envoi de la requête et l'attente de message pendant le second temps donné, avant de basculer dans l'état déconnecté. Selon un mode particulier de l'invention les requêtes envoyées alors que l'appareil est dans l'état déconnecté, appelées premières requêtes, sont différentes des requêtes envoyées alors que l'appareil est dans l'état connecté et où la première réponse envoyée après avoir quitté l'état déconnecté est différente des suivantes. Selon un mode particulier de l'invention l'appareil notifie l'arrivée d'un nouvel appareil sur le réseau lors de la réception d'une première 10 requête ou d'une première réponse. Selon un mode particulier de l'invention l'appareil maintient une liste des appareils connectés. Selon un mode particulier de l'invention l'appareil compare les réponses reçues à une requête avec la liste des appareils pour retirer de cette liste les appareils n'ayant pas répondu. L'invention concerne également un appareil destiné à être connecté à un réseau IP possédant des moyens d'émission de requêtes et des moyens d'émission de réponses sur le réseau IP, des moyens de déclencher des compteurs de temps caractérisé en ce qu'il possède des moyens pour basculer entre un état déconnecté, un état connecté et un état d'attente en fonction de la réception d'une requête ou d'une réponse de la part d'un autre appareil ou de l'expiration de compteurs de temps. L'invention sera mieux comprise, et d'autres particularités et avantages apparaîtront à la lecture de la description qui va suivre, la description faisant référence aux dessins annexés parmi lesquels: La figure 1 représente la méthode sous la forme d'un automate d'état. La figure 2 représente l'architecture typique d'un appareil implémentant la méthode. L'invention repose sur le principe d'une machine d'état permettant à l'appareil de savoir s'il est connecté, déconnecté ou en attente de réponses. Les changements d'état ont lieu sur réception de messages de la part des autres appareils ou sur l'expiration de compteur de temps. Un appareil démarrant va se placer dans l'état déconnecté puis va envoyer une requête sur le réseau demandant à d'éventuels appareils compatibles de répondre. II va ensuite attendre une réponse. En cas de non-réponse dans un temps donné, il va réitérer sa requête en restant dans l'état déconnecté. S'il reçoit une réponse signalant la présence d'un appareil sur le réseau il bascule dans l'état connecté et se met à écouter le réseau. La réception d'un message, requête ou réponse, indiquant la présence d'un appareil lui confirme son statut d'appareil connecté. Sur réception d'une requête il va lui-même envoyer une réponse. S'il ne reçoit aucun message pendant un temps déterminé, il peut basculer dans un état d'attente de messages. Cet état indique que l'appareil ne sait plus s'il est toujours connecté au réseau. Il va donc chercher à le savoir. Pour ce faire il va envoyer une requête sur le réseau demandant à tous les appareils présents de répondre. S'il ne reçoit aucune réponse, éventuellement après avoir renouvelé sa requête, il bascule dans l'état déconnecté, dans lequel il envoie des requêtes périodiques pour détecter une nouvelle connexion au réseau. Sur réception d'un message dans l'état d'attente, l'appareil bascule de nouveau dans l'état connecté. L'utilisation de cet état d'attente est utile pour ne pas interpréter une perte de réception de messages momentanée à une déconnexion. Ceci peut être particulièrement utile dans le cas où le réseau serait un réseau sans fil où de courtes perturbations dans la réception radio peuvent provoquer des interruptions momentanées du réseau sans réelle perte de connexion. La détection des nouveaux appareils peut se faire, par exemple, en différenciant les requêtes selon qu'elles sont une première requête après connexion ou une requête suivante. De même, les réponses qu'un appareil envoie sur réception d'une requête vont être différenciées selon qu'elles sont une première réponse après connexion ou une réponse suivante. De cette façon tout appareil recevant une première requête ou une première réponse saura qu'un nouvel appareil s'est connecté au réseau. La figure 1 décrit l'automate d'état d'un exemple de réalisation de l'invention. Au démarrage de l'appareil, il commence par envoyer une requête Who_is_there ( Qui_est_là ), référencé Al, sur le réseau. Par cette action il se met dans l'état déconnecté, référencé E1. L'entrée dans cet état provoque le déclenchement d'un compteur de temps Ti, dont la valeur peut par exemple être de 1 seconde. Cette valeur peut être réduite pour augmenter la réactivité du système à détecter la connexion de l'appareil. Dans l'état déconnecté El, si le compteur de temps Ti expire, on considère que l'appareil est toujours déconnecté. Il renvoie donc une requête Who_is_there et reboucle sur l'état E1, de ce fait il réinitialise le compteur de temps Ti. Dans l'état déconnecté El, si l'appareil reçoit une réponse I_am_alive ( Je_suis_vivant ) d'un autre appareil sur le réseau, ce message lui indique qu'il est connecté, il va notifier cet événement, par exemple par l'intermédiaire d'un gestionnaire d'événement accessible à l'application de haut niveau de l'appareil. L'appareil va donc envoyer un événement Connected ( Connecté ). Il passe donc dans l'état connecté, référencé E2. L'entrée dans l'état E2 déclenche un nouveau compteur de temps T2, typiquement de l'ordre de quelques minutes, du moins si l'on n'est pas intéressé par une détection rapide de la déconnexion des appareils du réseau. Dans l'état déconnecté El, si l'appareil reçoit une réponse I_am_here (Je_suis_là ) d'un autre appareil sur le réseau, il va réagir comme dans le cas précédent où il recevait un message I_am_alive ( Je_suis_vivant ). La seule différence entre les deux est que la réponse 1_am_here au lieu de I_am_alive signale que l'appareil auteur de cette réponse vient de se connecter et que c'est sa première réponse. On détecte donc ainsi l'arrivée d'un nouvel appareil dans le réseau, événement que l'on va notifier par l'envoi d'un événement New_device ( Nouvel_appareil ) en sus de l'événement Connected . Dans l'état déconnecté El, si l'appareil reçoit une requête Who_is_here ou Who_is_alive d'un autre appareil sur le réseau, ce message lui indique qu'il est connecté et qu'un autre appareil cherche à savoir qui est sur le réseau. l'appareil va donc basculer dans l'état connecté E2. Il y aura notification d'un événement Connected signalant la connexion de l'appareil au réseau. L'appareil va répondre à la requête par une réponse I_am_here signalant sa présence sur le réseau et le fait que c'est la première réponse qu'il émet depuis sa connexion. Dans le cas d'une requête who_is_here un événement New_device sera également notifié, l'appareil à l'origine de la requête venant de se connecter au réseau. L'entrée dans l'état connecté E2 va déclencher un compteur de temps T2. Sur expiration de ce compteur de temps T2 sans avoir reçu de messages de la part du réseau, l'appareil va se considérer comme potentiellement déconnecté du réseau. Pour confirmer cette déconnexion il va envoyer une requête Who_is_alive sur le réseau et se mettre en attente d'une réponse dans l'état d'attente E3. Dans l'état connecté E2, sur réception d'une réponse I_am_alive l'appareil va se remettre dans l'état E2 et donc réinitialiser le compteur de temps T2. Dans l'état connecté E2, sur réception d'une requête Who_is_alive l'appareil va se remettre dans l'état E2 et donc réinitialiser le compteur de temps T2. Il va de plus émettre une réponse I_am_alive signalant sa présence sur le réseau. Dans l'état connecté E2, sur réception d'une requête Who_is_there l'appareil va se remettre dans l'état E2 et donc réinitialiser le compteur de temps T2. Il va de plus émettre une réponse I_am_alive signalant sa présence sur le réseau. Il va également émettre un événement New_device signalant l'arrivée sur le réseau de l'appareil à l'origine de la requête. Dans l'état connecté E2, sur réception d'une réponse I_am_here l'appareil va se remettre dans l'état E2 et donc réinitialiser le compteur de temps T2. Il va également émettre un événement New_device signalant l'arrivée sur le réseau de l'appareil à l'origine de la requête. L'entrée dans l'état d'attente de message E3, va déclencher un compteur de temps T3, typiquement de l'ordre de quelques secondes. Une requête Who_is_alive venant d'être envoyée, cet état est un état d'attente des réponses des appareils connectés au réseau. Sur expiration de ce compteur de temps sans avoir reçu de réponse, l'appareil va se considérer comme déconnecté du réseau. Il va émettre un événement Disconnected ( Déconnecté ) pour signaler cet état et basculer dans l'état déconnecté E1. Dans l'état d'attente E3, sur réception d'une réponse I_am_alive signalant la présence d'un autre appareil connecté au réseau, l'appareil va basculer dans l'état connecté E2. Dans l'état d'attente E3, sur réception d'une réponse I_am_here signalant la présence d'un autre appareil connecté au réseau, l'appareil va basculer dans l'état connecté E2. La réponse 1_am_here signalant de plus que l'appareil émetteur de ladite réponse vient de se connecter au réseau, l'appareil va donc émettre un événement New_device signalant l'arrivée du nouvel appareil. Dans l'état d'attente E3, sur réception d'une requête Who_is_alive signalant la présence d'un autre appareil connecté au réseau, l'appareil va basculer dans l'état connecté E2. L'appareil va également émettre une réponse I_am_alive pour signaler sa présence sur le réseau. Dans l'état d'attente E3, sur réception d'une requête Who_is_here signalant la présence d'un autre appareil connecté au réseau, l'appareil va basculer dans l'état connecté E2. L'appareil va également émettre une réponse 1_am_alive pour signaler sa présence sur le réseau. Il va également émettre un événement New_device signalant l'arrivée sur le réseau de l'appareil émetteur de la requête. Pour l'envoi des requêtes plusieurs alternatives sont possibles. Une première façon de faire est d'envoyer ces messages en diffusion générale sur le réseau ( Broadcast en anglais). De cette façon les messages émis sur le réseau vont être délivrés à tous les appareils présents sur le réseau, qu'ils soient compatibles ou non avec la méthode décrite. Une autre manière de faire est de définir une adresse de diffusion multiple ( multicast en anglais) et un port qui soit connus de tous. Ce peut être un paramètre commun à tous les appareils du réseau ou une adresse et un port bien connu défini auprès de l'IANA l'autorité gérant l'assignation de nombres pour Internet ( Inernet Assigned Number Authority en anglais). La dernière solution étant préférée. Une fois cette adresse et ce port définis, toutes les requêtes seront émises sur cette adresse de diffusion multiple, chaque appareil implémentant la méthode se devant d'écouter le trafic sur cette adresse de diffusion multiple. De cette façon seuls les appareils concernés vont recevoir les messages relatifs à ce protocole. On choisira de préférence d'émettre les réponses selon un mode de diffusion point à point ( Unicast en anglais) directement de la source à destination de l'émetteur de la requête. Une façon d'être plus tolérant à des pertes de requêtes ou de réponses, toujours possibles, est de définir qu'un appareil n'est considéré comme déconnecté qu'après sa non-réponse à un nombre donné de requêtes successives. Le choix de ce nombre va influer sur la rapidité de la détection de la déconnexion d'un appareil du réseau et également sur la fiabilité de cette détection. Plus ce nombre va être petit, plus la détection va être rapide, mais avec le risque de déclarer un appareil comme déconnecté alors que sa réponse se sera simplement perdue. Plus ce nombre va être grand, plus le risque que toutes les réponses émises par un appareil se perdent alors que l'appareil est toujours connecté va être faible, mais le temps de détection d'une réelle déconnexion va s'allonger d'autant. En pratique le choix de ce nombre va dépendre de la fiabilité du réseau utilisé, il sera, par exemple plus grand, typiquement 3, pour un réseau sans fil, et de 1 pour un réseau Ethernet câblé très fiable. On peut étendre l'algorithme pour maintenir la liste des appareils connectés à un moment donné. On choisira de préférence une modification simple de l'algorithme qui consiste à ne pas réinitialiser le compteur de temps T2 dans l'état connecté E2 lors de réception de messages. Ensuite il faut ajouter dans la liste des appareils l'identifiant (par exemple adresse IP) de tout appareil qui envoie une requête ou une réponse. Régulièrement, tous les T2, l'appareil va émettre une requête Who_Is_Alive et entrer dans l'état E3 de façon à vérifier la présence sur le réseau des appareils de la liste ainsi que sa propre déconnexion. La non-réponse de la part d'un appareil dans un temps donné, par exemple T4, est interprétée comme sa déconnexion du réseau. A ce moment là, il faut supprimer cet appareil de la liste. Si aucun appareil ne répond au bout de T3, l'appareil est considéré comme étant déconnecté du réseau. Il entre alors dans l'état El et doit vider sa liste d'appareils connectés. D'autres variantes peuvent être développées par l'homme du métier par exemple pour optimiser le trafic réseau en utilisant des réponses selon un mode de diffusion multiple ou générale ( multicast ou broadcast ). Par contre ces variantes peuvent nécessiter d'autres modifications de l'algorithme. Le mécanisme, tel que décrit, peut posséder l'inconvénient de provoquer une vague d'émission de requêtes Who_is_alive sur le réseau si le temps T2 est le même pour tous les appareils. En effet, après la circulation du dernier message sur le réseau, tous les appareils vont, à l'expiration de T2, envoyer de telles requêtes. Une façon de résoudre ce problème consiste en un choix aléatoire de T2 dans une plage définie. De cette façon, seul l'appareil ayant le T2 le plus court va envoyer une requête qui sera reçue par tous les appareils du réseau et qui va provoquer la réinitialisation des compteurs de temps T2 de tous les appareils. Il est également possible, par exemple en cas de surcharge du réseau, que des messages soient perdus entraînant le basculement dans l'état déconnecté d'un appareil alors que, de fait, l'appareil sera toujours connecté mais n'aura pas reçu de messages pendant le temps T3. Pour diminuer le risque de fausse détection de la déconnexion d'un appareil, il est possible de réitérer plusieurs fois l'envoi de la requête Who_is_alive dans le cas d'une non-réponsee avant de considérer l'appareil comme déconnecté. Les messages sont envoyés en utilisant préférentiellement le protocole de datagrammes utilisateurs UDP ( User Datagram Protocol en anglais). En effet, l'utilisation du mode de diffusion multiple implique l'utilisation de UDP, il paraît donc raisonnable de généraliser son utilisation pour toute l'application quel que soit le mode de diffusion adopté. Pour ce qui est du format des messages, les adresses sources et destination étant contenues dans l'entête IP du message, un simple octet codant le type du message suffit à la bonne marche de la méthode décrite. Il va de soi que l'on peut enrichir le contenu des messages sans sortir de l'invention. Un exemple de codage est de transmettre dans le corps du message un octet ayant la valeur 0x0 pour les requêtes Who_is_there , 0x1 pour les réponses I_am_here , 0x2 pour les requêtes Who_is_alive et 0x3 pour les réponses I_am_alive . La figure 2 représente un exemple d'architecture générale d'un appareil, référencé 2.1, destiné à implémenter la méthode. Un tel appareil comporte une interface réseau, référencée 2.6, destinée à connecter l'appareil au réseau référencé 2.7. II comporte également une mémoire permanente, référencée 2.5, destinée à stocker les programmes nécessaires à l'exécution de la méthode dont la pile gérant la communication IP, la couche de gestion de l'interface réseau ainsi que les programmes gérant les échanges de messages selon la méthode décrite. Ces programmes seront chargés dans la mémoire vive, référencée 2.3, pour l'exécution par le processeur central référencé 2.2. Tous ces éléments seront reliés entre eux par un bus de communication référencé 2.4. II est évident pour l'homme du métier, que cette architecture peut varier dans l'agencement de ces moyens et n'est qu'un exemple d'architecture d'un appareil à même d'implémenter la méthode. Il va de soi que l'invention, bien que décrite dans le cadre de messages envoyés en diffusion multipoint utilisant UDP, l'homme du métier pourra varier les modes d'émission et le protocole utilisé, par exemple TCP ( Transport Control Protocol en anglais), sans sortir du cadre de l'invention. REVENDICATIONS 1. Méthode de découverte, par un appareil destiné à être connecté à un réseau IP, des appareils implémentant ladite méthode et connectés audit réseau, caractérisée en ce qu'elle comporte au moins les étapes suivantes: - l'appareil étant considéré dans un état déconnecté (El), il envoie des requêtes de manière répétée et automatique sur le réseau IP; - le basculement dans un état connecté (E2) sur la réception, par l'appareil, d'au moins un message selon la méthode de la part d'un autre appareil. 2. Méthode selon la revendication 1 où sur réception d'une requête en provenance d'un autre appareil, l'appareil envoie une réponse 15 sur le réseau. 3. Méthode selon la revendication 2 où l'appareil, étant dans un état connecté (E2), et ne recevant pas de message selon la méthode pendant un premier temps donné (T2), va envoyer une requête sur le réseau IP et basculer dans un état d'attente de message (E3). 4. Méthode selon la revendication 3 où l'appareil, étant dans un état d'attende de message (E3), et ne recevant pas de message selon la méthode pendant un second temps donné (T3), va basculer dans l'état déconnecté (El). 5. Méthode selon la revendication 4 où l'appareil, étant dans un état d'attente de message (E3) et recevant un message selon la méthode, va basculer dans l'état connecté (E2). 6. Méthode selon l'une quelconque des revendications précédentes où l'appareil envoie les messages selon la méthode selon un mode de diffusion multipoint à une adresse et un port connu et où l'appareil écoute à cette adresse et sur ce port. 7. Méthode selon l'une quelconque des revendications précédentes où l'appareil, étant dans l'état d'attente de message (E3) et ne recevant pas de messages selon la méthode, va réitérer un nombre donné de fois l'envoi de la requête et l'attente de message pendant le second temps donné (T3), avant de basculer dans l'état déconnecté (El). 8. Méthode selon l'une quelconque des revendications précédentes où les requêtes envoyées alors que l'appareil est dans l'état déconnecté (El), appelées premières requêtes, sont différentes des requêtes envoyées alors que l'appareil est dans l'état connecté (E2) et où la première réponse envoyée après avoir quitté l'état déconnecté (El) est différente des suivantes. 9. Méthode selon l'une quelconque des revendications précédentes où l'appareil notifie l'arrivée d'un nouvel appareil sur le réseau lors de la réception d'une première requête ou d'une première réponse. 10. Méthode selon l'une quelconque des revendications précédentes où l'appareil maintient une liste des appareils connectés. 11. Méthode selon la revendication 10 où l'appareil compare les 20 réponses reçues à une requête avec la liste des appareils pour retirer de cette liste les appareils n'ayant pas répondu. 12. Appareil destiné à être connecté à un réseau IP possédant des moyens d'émission de requêtes et des moyens d'émission de réponses sur le réseau IP, des moyens de déclencher des compteurs de temps caractérisé en ce qu'il possède des moyens pour basculer entre un état déconnecté (El), un état connecté (E2) et un état d'attente (E3) en fonction de la réception d'une requête ou d'une réponse de la part d'un autre appareil ou de l'expiration de compteurs de temps.