FR2864871A1 - Methode de decouverte d'un reseau domestique et appareil implementant la methode - Google Patents
Methode de decouverte d'un reseau domestique et appareil implementant la methode Download PDFInfo
- Publication number
- FR2864871A1 FR2864871A1 FR0400072A FR0400072A FR2864871A1 FR 2864871 A1 FR2864871 A1 FR 2864871A1 FR 0400072 A FR0400072 A FR 0400072A FR 0400072 A FR0400072 A FR 0400072A FR 2864871 A1 FR2864871 A1 FR 2864871A1
- Authority
- FR
- France
- Prior art keywords
- network
- devices
- description information
- address
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 15
- 230000004044 response Effects 0.000 claims abstract description 12
- 238000004891 communication Methods 0.000 claims abstract description 6
- 230000006870 function Effects 0.000 description 13
- 230000007246 mechanism Effects 0.000 description 8
- 238000005516 engineering process Methods 0.000 description 6
- 230000006978 adaptation Effects 0.000 description 5
- 239000011800 void material Substances 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 241000212384 Bifora Species 0.000 description 1
- 206010012812 Diffuse cutaneous mastocytosis Diseases 0.000 description 1
- 230000010391 action planning Effects 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000001541 differential confocal microscopy Methods 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
- H04L12/2805—Home Audio Video Interoperability [HAVI] networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
- H04L12/2807—Exchanging configuration information on appliance services in a home automation network
- H04L12/2809—Exchanging configuration information on appliance services in a home automation network indicating that an appliance service is present in a home automation network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Automation & Control Theory (AREA)
- Computer Security & Cryptography (AREA)
- Multimedia (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Small-Scale Networks (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
L'invention concerne plus particulièrement une méthode de découverte, par un appareil connectable à un réseau de communication, des autres appareils connectés qui comporte une étape de connexion de l'appareil audit réseau, une étape d'envoi d'un message d'annonce contenant des informations d'auto description décrivant l'appareil à destination de tous les autres appareils connectés à ce réseau, une étape d'envoi d'un message de demande d'informations d'auto description à tous les autres appareils connectés à ce réseau et une étape de réception d'un message de réponse de chacun des autres appareils du réseau contenant les informations d'auto description de cet autre appareil.L'invention concerne également un appareil connectable à un réseau qui possède des moyens d'envoyer un message d'annonce, contenant des informations d'auto description le décrivant, à tous les autres appareils du réseau, des moyens d'envoi d'un message de demande d'informations d'auto description à tous les autres appareils du réseau et des moyens de réception des messages de réponses contenant des informations décrivant chacun des autres appareils du réseau.
Description
2864871 1
Méthode de découverte d'un réseau domestique et appareil implémentant la méthode.
L'interopérabilité audio et vidéo domestique (HAVi pour Home Audio Video interoperability en anglais) est une spécification développée par des entreprises d'électronique grand public qui permet l'interconnexion d'appareils audio et vidéo dans un environnement domestique basé sur un réseau utilisant la technologie des bus IEEE 1394. La version courante (version 1.1, disponible auprès de HAVi, Inc. 2694 Bishop Drive, Suite 275 San Ramon, CA 94583, USA) n'est pas prévue pour fonctionner sur des réseaux basés sur d'autres technologies que les bus IEEE 1394, dont la référence est le standard IEEE 1394-2000.
En l'état actuel du marché des appareils domestiques, il apparaît que les réseaux qui sont développés dans le cadre domestique sont généralement hétérogènes et font intervenir des technologies diverses autres que IEEE 1394. On peut citer, par exemple, l'importance prise par les réseaux respectant le protocole Internet (IP pour Internet Protocol en anglais) dont on peut trouver une référence sous la forme d'une requête pour commentaires (RFC pour request for comment en anglais) sous le numéro RFC 791, ces requêtes étant maintenues par le groupe de travail d'ingénierie Internet (IETF pour Internet Engineering Task Force en anglais). La spécification HAVi ayant été conçue dans le cadre d'une application sur un bus 1394, son utilisation sur un réseau d'une autre technologie pose le problème de son adaptation à cette autre technologie.
L'invention concerne I'interopérabilité audio et vidéo sur des réseaux basé sur d'autres technologies de réseau que le bus 1394.
L'invention concerne plus particulièrement une méthode de découverte, par un appareil connectable à un réseau de communication, des autres appareils connectés qui comporte une étape de connexion de l'appareil audit réseau, une étape d'envoi d'un message d'annonce contenant des informations d'auto description décrivant l'appareil à destination de tous les autres appareils connectés à ce réseau, une étape d'envoi d'un message de demande d'informations d'auto description à tous 2864871 2 les autres appareils connectés à ce réseau et une étape de réception d'un message de réponse de chacun des autres appareils du réseau contenant les informations d'auto description de cet autre appareil.
Selon un mode particulier de réalisation de l'invention le message de demande et le message d'annonce sont confondus.
Selon un mode particulier de réalisation de l'invention les informations d'auto description décrivant un appareil contiennent l'adresse sur le réseau de l'appareil.
Selon un mode particulier de réalisation de l'invention les informations d'auto description décrivant un appareil contiennent un identificateur global unique, différent de l'adresse, identifiant l'appareil sur le réseau.
Selon un mode particulier de réalisation de l'invention les informations d'auto description décrivant un appareil contiennent les caractéristiques d'un module logiciel permettant de contrôler cet appareil.
Selon un mode particulier de réalisation de l'invention le message d'annonce est envoyé en diffusion générale sur le réseau.
Selon un mode particulier de réalisation de l'invention le message 25 d'annonce est envoyé en diffusion multipoint sur une adresse de diffusion multipoint prédéfinie à laquelle les autres appareils doivent être abonnés.
L'invention concerne également un appareil connectable à un réseau qui possède des moyens d'envoyer un message d'annonce, contenant des informations d'auto description le décrivant, à tous les autres appareils du réseau, des moyens d'envoi d'un message de demande d'informations d'auto description à tous les autres appareils du réseau et des moyens de 2864871 3 réception des messages de réponses contenant des informations décrivant chacun des autres appareils du réseau.
Selon un mode particulier de réalisation de l'invention l'appareil comporte des moyens permettant de générer un identificateur global unique, différent de l'adresse de l'appareil, sur le réseau.
Selon un mode particulier de réalisation de l'invention l'appareil comporte des moyens d'envoi du message d'annonce en diffusion générale sur le réseau.
Selon un mode particulier de réalisation de l'invention l'appareil comporte des moyens d'envoi du message d'annonce en diffusion multipoint sur une adresse de diffusion multipoint prédéfinie à laquelle les autres appareils doivent être abonnés.
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 l'architecture de la pile HAVi telle que définie sur un réseau 1394.
La figure 2 représente l'architecture de la pile HAVi telle qu'implémentée dans l'exemple de réalisation de l'invention.
La figure 3 représente le format du paquet d'annonce tel que défini dans l'exemple de réalisation de l'invention.
La figure 4 représente le format du paquet de demande des SDD tel que défini dans l'exemple de réalisation de l'invention.
La figure 5 représente les étapes de la phase de découverte du réseau dans le cadre de l'exemple de réalisation de l'invention.
La figure 6 représente l'architecture matérielle d'un appareil supportant HAVi sur un réseau IP.
L'exemple de réalisation de l'invention qui va suivre se place dans le contexte de l'adaptation de HAVi à un réseau de type IP, mais il est évident 2864871 4 que l'invention n'est pas limitée à ce type de réseau et qu'elle peut être utilisée pour adapter HAVi à tout autre type de réseau. L'invention peut aussi être utilisée dans le cadre d'une spécification autre que HAVi, dès que l'on va rechercher à découvrir les appareils connectés à un réseau.
La figure 1 représente l'architecture de la pile HAVi telle qu'elle est définie dans la spécification HAVi sur un réseau constitué de bus 1394. La pile HAVi est programmable en JAVA via l'API ( Application programming interface en anglais) 1.1. La pile d'un appareil peut comprendre des modules de contrôle de l'appareil (DCM pour Device Control Module en anglais) ou des modules de contrôle de fonctionnalités de l'appareil (FCM pour Function Control Module en anglais) 1.7. La pile peut aussi comprendre des modules natifs 1.8. Une base de registres 1.2 ( Registry en anglais) maintient une base de tous les appareils sur le réseau. Un gestionnaire d'événements 1.3 ( Event Manager en anglais) est responsable de la diffusion sur le réseau des événements résultant d'un changement d'état d'un appareil. Un gestionnaire de ressources 1.4 ( Resource Manager ) permet le partage de ressources et la planification d'actions. Un gestionnaire de module de contrôle d'appareil 1.5 ( Device Control Module Manager en anglais) permet d'installer et de retirer des modules permettant le contrôle d'autres appareils sur le réseau. Un gestionnaire de flux 1.6 ( Stream Manager en anglais) permet de gérer les flux de transfert en temps réel des contenus audio et vidéo sur le réseau. Un système de messages ( Messaging System en anglais) 1.9 est responsable du passage de messages entre les différents composants du système. Un module d'adaptation à la couche de transport 1.10 (TAM pour Transport Adaptation Module en anglais) permet l'assemblage et la fragmentation des messages HAVi. Le gestionnaire du support de transmission 1.11 (CMM pour Communication Media Manager en anglais) permet aux autres éléments du système d'utiliser directement le support de transmission sans passer par le gestionnaire de messages. C'est nécessaire, en particulier pour pouvoir implémenter des modules de contrôle d'appareils non HAVi où le contrôle repose sur un protocole propriétaire. Le gestionnaire de flux, le TAM ou le CMM dialoguent avec les pilotes du réseau 1.12, en l'occurrence 1394.
2864871 5 La figure 2 représente l'architecture de la pile HAVi dans le cadre de l'exemple de réalisation de l'invention. On retrouve les mêmes éléments que dans la figure précédente à l'exception du module d'adaptation à la couche de transport 2.10. Ici nous retrouvons le protocole TCP qui tient lieu de TAM.
Le gestionnaire de support de transmission doit être adapté à IP et non plus à 1394. Nous avons donc un CMMIP 2.11. Ces modules interagissent avec la couche IP 2.12. Le gestionnaire de flux quant à lui va interagir avec la couche 802.1 p/Q 2.13 apportant la qualité de service sur IP pour l'échange de flux.
La spécification HAVi définit un identificateur unique sur le réseau pour un composant logiciel, cet identificateur est appelé le SEID pour Software Element Identifier en anglais. Cet identificateur est codé sur 80 bits et est composé de deux éléments distincts, un premier identificateur correspondant à un identificateur unique de l'appareil hébergeant le composant logiciel sur le réseau. Cet identificateur est sur 64 bits et est appelé le GUID pour Global Unique Identifier en anglais. Ce GUID est défini par la norme IEEE 1394 pour identifier de manière unique les appareils 1394, c'est l'EUI-64 du composant 1394 stocké dans la mémoire morte de tout appareil 1394. Rappelons qu'un EUI- 64, tel que défini par l'IEEE dans son document Guidelines for 64-bit Global Identifier (EUI-64TM) Registration Authority , est composé d'un identifiant d'entreprise de 24 bits suivi d'une extension de 40 bits.
Le second élément composant ce SEID est un identificateur de 16 bits permettant d'identifier le composant au sein de l'appareil qui l'héberge. Le fait de concaténer un identificateur unique pour l'appareil sur le réseau et un identificateur du composant sur l'appareil permet donc d'identifier de manière unique tout composant logiciel au sein du réseau HAVi.
Mais il n'existe pas d'identificateur équivalent sur 64 bits sur un réseau IP. Sur ce réseau, seuls existent les adresses IP de 32 bits en IP version 4 et 128 bits en IP version 6, voire les adresses MAC de 48 bits lorsque le réseau est un réseau Ethernet. Une première idée est de construire le SEID en concaténant l'identificateur naturel du réseau sur lequel on se trouve avec un identificateur local à l'appareil complétant celui-ci pour construire un SEID de 80 bits. En fait cette solution ne fonctionne pas dans le 2864871 6 cas où un réseau hétérogène connecterait, par exemple, un bus basé sur du 1394 et un autre sur IP. Dans ce cas, la coexistence de SEID construit sur la base d'un GUID de 64 bits et d'un identifiant local sur 16 bits avec d'autres construits, par exemple, sur la base d'une adresse IP de 32 bits et d'un identifiant local de 48 bits, peut mener à la non-unicité des identificateurs. En effet, un SEID de 0xA9FE6410000000123456 correspondant à une adresse IP de 169.254.100.16 et un identificateur local de 0x000000123456 peut entrer en collision avec un SEID composé d'un GUID deOxA9FE641000000012 et un identificateur local de 0x3456. Donc, quel que soit le type de réseau sur lequel on veut gérer HAVi, il convient de garder la structure du SEID en un identificateur, le GUID, sur 64 bits et un identificateur local sur 16 bits.
Il faut donc trouver le moyen de créer des GUID sur le réseau visé qui n'interfèrent pas avec les GUID standard sur 1394, donc avec les EUI-64 de l'IEEE. Ces EUI-64 sont la concaténation d'un identificateur d'entreprise sur 24 bits identifiant l'entreprise à l'origine de l'appareil et d'une extension de 40 bits gérée par l'entreprise à l'origine du EUI-64 qui est responsable de son unicité dans l'ensemble des identificateurs dont elle est à l'origine. Les identificateurs d'entreprise étant gérés de manière centralisée par l'autorité d'enregistrement de l'IEEE. Un premier moyen de construire un tel GUID sur un réseau IP version 4 est de prendre OxFFFFFFFE concaténé avec l'adresse IP en question sur 32 bits. Comme la valeur OxFFFFFF ne doit pas être allouée par l'IEEE comme identificateur d'entreprise, on est certain que cette méthode de construction du GUID produira des identificateurs qui ne vont pas entrer en collision avec les GUID formés d'un EUI-64.
Une autre manière de faire est d'utiliser la méthode préconisée par l'IEEE pour la construction d'un EUI-64 par extension d'une adresse MAC de 48 bits, c'est à dire de choisir une construction de la forme OxccccccFFFFeeeeee où Oxcccccc représente la partie identifiant l'entreprise dans l'adresse MAC et Oxeeeeee l'extension dans l'adresse MAC. Dans ce cas, la non-collision avec des EUI-64 est assuré par le fait que l'IEEE restreint l'attribution des extensions de 40 bits qui ne doivent pas commencer par OxFFFFFF, ni par OxFFFFFE, qui sont respectivement réservés comme marque d'une extension d'une adresse MAC-48 et d'un EUI-48.
2864871 7 Le tableau suivant récapitule les différents formats d'adresses ou d'identificateurs dont il est fait état dans les paragraphes précédents.
Adresse MAC-48 { entreprise_id 24 bits extension 24 bits EUI- 48 { entreprise_id 24 bits extension 24 bits EUI-64 { entreprise_id 24 bits extension 40 bits SEID { GUID 80 bits Local id 16 bits Dans le cas du réseau IP version 6, le problème est un peu différent. En effet, cette version de IP préconise des adresses sur 128 bits. Les adresses IP version 6 sont composées de deux parties de 64 bits, le préfixe et l'identificateur d'interface. Ce dernier est conçu pour correspondre à un EUI-64 à la différence du u/l bit dans l'identificateur d'entreprise. Mais cette différence ne remet pas en cause l'unicité de l'EUI-64. On peut donc directement prendre les 64 derniers bits de l'adresse IP version 6 pour constituer le GUID de l'appareil HAVi.
Dans le cas d'un appareil bi compatible IP version 4 et IP version 6, nous prendrons l'identificateur défini par l'adresse IP version 6 de l'appareil. Pour un appareil démarrant sur le réseau en suivant IP version 4 et devenant par la suite compatible version 6, il sera considéré que l'appareil est déconnecté et reconnecté, il lui sera donc attribué un identificateur issu de son adresse version 6.
2864871 8 Quand un appareil HAVi se connecte au réseau, il entame une phase de découverte du réseau lui permettant de connaître les autres appareils disponibles sur ce réseau. Dans le cas classique où le réseau sous-jacent est un bus 1394, la phase de réinitialisation du bus entraînée par le branchement d'un nouvel appareil, se termine par l'obtention par chaque appareil de la liste des adresses sur le bus de chacun des autres appareils connectés au bus. Ensuite, le nouvel appareil peut interroger chaque appareil du réseau de façon à lire dans sa mémoire morte les données d'auto description de l'appareil (SDD pour Self Describing Device ). En effet la spécification HAVi impose que chaque appareil possède de telles données adressables en suivant la norme IEEE 1212.
Le problème se pose donc de transposer cette phase de découverte sur un réseau autre qu'un bus 1394. D'une part nous n'avons pas de mécanisme naturel permettant à un appareil du réseau de récupérer la liste des adresses de tous les appareils connectés au réseau. D'autre part, il n'est généralement pas possible d'aller lire dans la mémoire d'un appareil distant comme cela se fait si l'on suit la norme IEEE 1212. Le réseau IP, par contre, possède un mécanisme de diffusion générale ( broadcast en anglais) qui permet d'envoyer un message sur le réseau sans destinataire précis, chaque appareil connecté recevant ledit message. II est donc possible que chaque appareil se connectant au réseau envoie un message en diffusion générale sur le réseau pour s'annoncer.
Il existe également un mécanisme de diffusion multipoint ( multicast en anglais). Ce mécanisme définit des adresses de diffusions multipoint. Par ce mécanisme tout paquet émis vers cette adresse de diffusion multipoint est reçu par tout appareil s'étant abonné à cette adresse de diffusion. Il est donc possible de définir une adresse connue de diffusion multipoint dédiée à l'annonce sur le réseau des appareils HAVi. Chaque appareil se connectant au réseau s'annonce à cette adresse de diffusion multipoint et tous les autres appareils du réseau, abonnés à cette adresse dédiée, recevront l'annonce.
Ce message peut de plus comporter les informations d'auto description contenues dans la SDD, de cette façon chaque appareil du réseau peut mettre à jour ses tables avec ses informations comme s'il était 2864871 9 allé les lire dans la mémoire de l'appareil. Ce message peut par exemple utiliser le protocole UDP au-dessus de IP. De cette façon, nous bénéficions de la détection d'erreur d'UDP. Il est également possible de définir un port UDP dédié à HAVi. Un exemple de ces informations est donné figure 3. On y trouve: Version de message HAVi: comme dans la spécification HAVi 1.1, il donne la version de système HAVi supporté par cet appareil.
o Le premier octet est réservé et doit être 0x00 o Le second octet est le numéro de version majeur o Le troisième octet est le numéro de version mineur Code opération: les valeurs sont o 0: vivant o 1: quittant o 2: demande o 3 à 255: réservé - Identificateur de mise à jour: un champ de 8 bits initialisé à 0 et incrémenté à chaque fois qu'une valeur change dans le message. Ceci permet de savoir si un changement dans le message est apparu sans avoir à comparer toutes les valeurs.
- Classe d'appareil: définit la classe de l'appareil, peut être: o Ob0000: réservé o Ob0001: audio vidéo de base (BAV pour Basic Audio Video en anglais) o Ob0010: audio vidéo intermédiaire (IAV pour Intermediate Audio Video en anglais) o Ob0011: audio vidéo complet (FAV pour Full Audio Video en anglais) o Ob0lOO à Ob1111: réservé DM: ce bit spécifie pour les appareils IAV si un gestionnaire de DCM est implémenté, doit être à 0 pour un appareil BAV et à 1 pour les appareils FAV.
- SM: ce bit spécifie pour les appareils IAV si un gestionnaire de flux est implémenté, doit être à 0 pour un appareil BAV et à 1 pour les appareils FAV. 15
2864871 10 RM: ce bit spécifie pour les appareils IAV si un gestionnaire de ressources est implémenté, doit être à 0 pour un appareil BAV et à 1 pour les appareils FAV.
- DC: ce bit spécifie pour un appareil IAV si un contrôleur d'interactions dirigées par les données (DDI pour Data Driven Interaction en anglais) est implémenté et pour un appareil FAV si un contrôleur DDI et une interface utilisateur de niveau 2 est implémenté, doit être à 0 dans le cas d'un appareil BAV.
- DS: ce bit spécifie le statut, actif ou inactif, de l'appareil, dans le cas d'appareil HAVi sur un réseau IP doit être à 1, car le fait de s'annoncer sur le réseau signifie que l'appareil est actif. Br: ce bit spécifie si l'appareil est un pont.
- GUID: l'identificateur global unique de l'appareil.
- IPV4 adresse: l'adresse IP version 4 de l'appareil, doit être à 0 si celle-ci n'est pas définie.
IPV6 adresse: l'adresse IP version 6 de l'appareil, doit être à 0 si celle-ci n'est pas définie.
Vendeur ID: Identificateur du vendeur, défini de manière globale et unique par l'IEEE, permet d'identifier le fabricant de l'appareil; Longueur vendeur: spécifie la longueur du texte identifiant le vendeur, chaque caractère étant codé en unicode sur 16 bits. Texte vendeur: chaîne de caractères identifiant le vendeur, limité à 50 caractères par la spécification HAVi.
- Modèle ID: identifie le modèle d'appareil, défini par le fabricant de l'appareil.
- Longueur modèle: spécifie la longueur du texte identifiant le modèle, chaque caractère étant codé en unicode sur 16 bits.
- Texte modèle: chaîne de caractère identifiant le modèle, limité à 50 caractères par la spécification HAVi.
Les champs suivants sont disponibles uniquement pour les appareils BAV. Pour les appareils IAV, FAV et les appareils BAV qui ne fournissent pas ces informations et donc pas d'unité de code DCM ( Device Control Module en anglais), ces champs doivent exister et doivent être mis à zéro 2864871 11 jusqu'au champ Taille DCU URL suivi de deux octets de complément à zéro.
Taille DCU: Taille en octet de l'unité de code DCM transférée.
- Espace DCU installée: taille de mémoire requise pour l'installation de l'unité sans compter l'espace de travail.
- Espace de travail DCU: estimation de l'espace de travail requis par l'unité de code.
- Taille DCU URL: taille en octet de l'adresse de la DCU Données URL: La chaîne de caractères formant l'adresse où trouver l'unité de code.
On vient de voir comment un appareil se connectant au réseau s'annonçait auprès des autres appareils du réseau. Il faut maintenant définir comment cet appareil découvre les autres appareils du réseau. Pour ce faire, l'appareil envoie une requête sur le réseau. Cette requête peut être envoyée de la même manière que le message d'annonce décrit précédemment, c'est-à-dire en diffusion générale ou en diffusion multipoint avec une adresse connue. Cette adresse peut être la même que celle définie pour les messages d'annonce ou une autre spécifique pour ce message. Chaque appareil du réseau qui reçoit cette requête répond par un message diffusé en unipoint ( unicast en anglais). Ce message de réponse est donc envoyé uniquement à l'appareil nouvellement connecté. Ce message de réponse doit contenir, comme l'annonce, les informations d'auto description normalement lues dans la SDD. Ce message de réponse peut prendre la même forme que le message d'annonce avec le champ code opération mis à 0 pour vivant . Le format de la requête peut être le format décrit à la figure 3 où le champ version de message HAVi a le même sens que dans l'annonce et où le champ code opération est mis à 2. Il est également envisageable que le message de réponse soit envoyé directement en réponse au message d'annonce lors de la connexion du nouvel appareil au réseau. Dans ce cas les messages d'annonce et les messages de demande sont confondus.
Les étapes de la phase de découverte du réseau par un appareil se connectant sur ce réseau sont récapitulées figure 5. L'appareil se connecte au réseau, étape 5.1. Une fois connecté, il envoie un message d'annonce contenant les informations d'auto description le concernant à destination des appareils déjà connectés sur le réseau, étape 5.2. Ces informations d'auto 10 2864871 12 description sont le reflet des informations contenues dans la SDD des appareils 1394. Une fois que l'appareil s'est annoncé sur le réseau, il envoie une demande à destination de tous les autres appareils 5.3 par une diffusion générale ou une diffusion multipoint. Les autres appareils du réseau répondent à cette demande par l'envoi de messages de réponse contenant les informations d'auto description les concernant à l'émetteur de la demande, étape 5.4.
La spécification HAVi prévoit dans son architecture la présence d'un gestionnaire de support de communication, CMM pour Communication Media Manager en anglais. Le CMM est une entité dépendante du réseau sousjacent sur lequel est utilisée la spécification HAVi. Ce gestionnaire apporte une interface vers le réseau de façon à ce que des composants HAVi puisse interagir avec des appareils qui ne seraient pas totalement contrôlables par des échanges de messages HAVi. En apportant une interface permettant l'utilisation directe du réseau sous-jacent on permet à un module HAVi de piloter tout appareil sur le réseau quel que soit son mode de fonctionnement et le protocole qu'il utilise, même propriétaire. Une autre fonctionnalité apportée par ce gestionnaire est de faire le lien entre les identificateurs uniques globaux des appareils HAVi sur le réseau (GUID) et leur adresse IP. Ce gestionnaire permet également d'implémenter un mécanisme d'indications sur le réseau. Grâce à ce mécanisme d'indications, il sera possible à un appareil de s'abonner à des indications émises par un autre appareil sur le réseau. II va donc pouvoir recevoir ces indications sous la forme de messages et gérer ces abonnements comme on va le voir dans la description des différentes fonctions constituant ce gestionnaire. L'abonnement à ces indications correspond au filtrage des paquets IP reçus en fonction de leur origine et du protocole au dessus d'IP auquel ce paquet participe. Le gestionnaire adapté au réseau IP (CMMIP) est constitué des fonctions suivantes: Cmmip::GetGuidList Status Cmmip::GetGuidList(out sequence<GUID> guidList) guidList est la liste des GUID de tous les appareils du réseau.
Cette fonction permet de récupérer la liste des GUID de tous les appareils HAVi du réseau.
2864871 13 Cmmip::GetlPAddress Status Cmmip::GetlPAdress( In GUID guid, Out sequence<IpAddress> ipAddressList) guid est le GUID de l'appareil HAVi.
InAddressList est la liste des adresses IP de l'appareil dont le GUID est guid sur le réseau. Un appareil pouvant avoir au plus une adresse IP version 4 et une adresse IP version 6.
La fonction rend l'adresse IP de l'appareil identifié par son GUID.
Cmmip::GetGuid Status Cmmip::GetGuid( in IpAdress ipAdress, out GUID guid) ipAdress est l'adresse IP de l'appareil.
guid est le GUID de l'appareil.
La fonction rend le GUID de l'appareil identifié par son adresse IP.
Cmmip::Send Status Cmmip::Send( In Boolean useGuid, In GUID guid, In IpAddress ipAdress, In uchar hopLimit, In uchar upperProtocol, In sequence<octet> data) useGuid est un booléen déterminant si l'on utilise le GUID ou l'adresse IP de l'appareil destination pour l'identifier.
guid est le GUID de l'appareil destination du message si useGuid est à vrai.
2864871 14 ipAdress est l'adresse IP de l'appareil destination du message si useGuid est à faux.
hopLimit est le nombre maximum de routeurs que peut traverser le message avant d'être détruit.
upperProtocol est le code du protocole contenu dans la paquet IP, par exemple le code pour UDP est 17.
data représente la suite d'octets des données que l'on veut envoyer.
Cette fonction permet d'envoyer un paquet IP à un appareil identifié soit par son GUID, soit par son adresse IP.
Cmmip::Enrolllndication Status Cmmip::Enrolllndication( in Boolean useGuid, in GUID guid, in IpAdresse ipAdress, in OperationCode opCode, in uchar upperProtocol, out Boolean conflicts) useGuid est un booléen déterminant si l'on utilise le GUID ou l'adresse IP de l'appareil destination pour l'identifier.
guid est le GUID de l'appareil destination du message si useGuid est à vrai.
ipAdress est l'adresse IP de l'appareil destination du message si useGuid est à faux.
opCode est le code opération fourni par l'appelant, c'est la valeur que le gestionnaire CMMIP va placer dans le champ code opération du message de notification qu'il enverra au client.
upperProtocol est le protocole utilisé par les indications que l'on souhaite recevoir.
conflicts a la valeur vrai si cet abonnement ( enrollment en anglais) entre en conflit avec un autre abonnement, faux sinon.
Cette fonction permet à un client du gestionnaire CMMIP de s'abonner à des indications envoyées par un appareil sur le réseau en utilisant un protocole donné. Ce mécanisme permet de filtrer les paquets IP reçus par 2864871 15 l'interface de l'appareil en fonction de l'émetteur et du protocole utilisé au-dessus de IP. Une adresse IP où tous les bits sont à 1 (Oxffffffff en IP version 4 ou Ox en IP version 6) ou un GUID où tous les bits sont à 1 permet d'indiquer que l'on ne veut pas filtrer surl'adresse de l'émetteur et que l'on veut recevoir tous les paquets reçus ayant le bon protocole indifféremment de l'émetteur. Le gestionnaire CMMIP va stocker le SEID du client à l'origine du Cmmip::Enrolllndication qu'il obtient du système de gestion des messages, ce qui va lui permettre ensuite quand il recevra un paquet IP correspondant à cet abonnement de lui renvoyer le paquet en question via un message grâce à la fonction Cmmipindication que nous verrons plus loin. Un même paquet IP peut correspondre à plusieurs abonnements et sera, dans ce cas, envoyé à tous les modules abonnés. Le CMMIP est également responsable de la mise à jour des filtres lorsqu'un client est retiré ou qu'un appareil est débranché du réseau.
Cmmip::Dropindication Status Cmmip::Dropindication( in Boolean useGuid, in GUID guid, in IpAdresse ipAdress, in uchar upperProtocol) useGuid est un booléen déterminant si l'on utilise le GUID ou l'adresse IP de l'appareil destination pour l'identifier.
guid est le GUID de l'appareil destination du message si useGuid est à vrai.
ipAdress est l'adresse IP de l'appareil destination du message si useGuid est à faux.
upperProtocol est le protocole utilisé par les indications que l'on ne souhaite plus recevoir.
Cette fonction permet à un client de se désabonner.
<Client>::Cmmipindication Status <Client>::Cmmipindication( in Boolean useGuid, in GUID guid, 2864871 16 in IpAdresse ipAdress, in uchar upperProtocol, in ushort dataSize, in sequence<octet> indicationData) useGuid est un booléen déterminant si l'on utilise le GUID ou l'adresse IP de l'appareil destination pour l'identifier.
guid est le GUID de l'appareil destination du message si useGuid est à vrai.
ipAddress est l'adresse IP de l'appareil destination du message si useGuid est à faux.
upperProtocol est le protocole utilisé par l'indications que l'on souhaite envoyer.
dataSize est la taille des données en octet que l'on compte envoyer. 15 indicationData, c'est une séquence d'octets représentant les données effectives constituant l'indication.
Cette fonction est utilisée par le CMMIP pour envoyer à un client le message correspondant à un paquet IP répondant aux critères d'un abonnement. Sur réception d'un paquet IP le CMMIP teste les différents abonnements en cours pour les clients présents sur l'appareil. Si l'origine et le protocole du paquet IP correspondent aux critères fixés par l'abonnement d'un client, le paquet lui est envoyé par cette fonction.
NewDevice void NewDevices(in sequence<GUID> guidList) guidList est la liste des GUID des nouveaux appareils.
Cet événement est généré par le CMMIP lorsqu'un ou plusieurs nouveaux appareils s'annoncent sur le réseau. Cet événement n'est délivré que localement sur l'appareil hébergeant le CMMIP, en effet chaque appareil HAVi sur le réseau possédant son propre CMMIP, une diffusion générale de l'événement n'est pas nécessaire.
GoneDevices void GoneDevices(in sequence<GUID> guidList) guidList est la liste des GUID des appareils ayant été déconnectés.
Cet événement est généré par le CMMIP lorsqu'un ou plusieurs appareils sont déconnectés du réseau. La déconnexion d'un appareil du réseau est détectée soit par l'envoi d'un message signalant la déconnexion, soit par l'expiration de délais dans les tentatives de communication avec l'appareil en question ou lors de la phase de découverte. Dans ce cas, le CMMIP envoie un événement via le gestionnaire d'événements signalant les GUID des appareils ayant quitté le réseau. Cet événement n'est délivré que localement sur l'appareil hébergeant le CMMIP, en effet chaque appareil HAVi sur le réseau possédant son propre CMMIP, une diffusion générale de l'événement n'est pas nécessaire.
ChangedDevices void ChangedDevices(in sequence<GUID> guidList) guidList est la liste des GUID des appareils ayant changé d'adresse Cet événement est généré par le CMMIP lorsqu'un ou plusieurs appareils du réseau ont changé d'adresse IP. Ce changement peut provenir de la détection d'une collision entre adresses IP ou autre. Le CMMIP envoie un événement via le gestionnaire d'événements signalant les GUID des appareils ayant changé d'adresse IP. Cet événement n'est délivré que localement sur l'appareil hébergeant le CMMIP, en effet chaque appareil HAVi sur le réseau possédant son propre CMMIP, une diffusion générale de l'événement n'est pas nécessaire. Les clients qui le désirent peuvent, sur réception de cet événement, demander via la fonction Cmmip::GetlpAddress la nouvelle adresse du ou des appareils en question.
GuidListReady void GuidListReady( in sequence<GUID> guidList, in sequence<GUID> goneDevices, in sequence<GUID> newDevices, in sequence<GUID> changedDevices) IP.
2864871 18 guidList est la liste des GUID de tous les appareils HAVi connectés au réseau.
goneDevices est la liste, éventuellement vide, des GUID des appareils disparus du réseau lors de la reconfiguration.
newDevices est la liste, éventuellement vide, des GUID des appareils apparus sur le réseau lors de la reconfiguration.
changedDevices est la liste, éventuellement vide, des GUID des appareils ayant changé d'adresse IP lors de la reconfiguration.
Cet événement est généré par le CMMIP quand la liste des GUID des appareils du réseau est disponible. En effet, lors d'une reconfiguration du réseau, cette liste n'est plus disponible via la fonction Cmmip::GetGuidList le temps que le CMMIP achève la phase de découverte du réseau nouvellement reconfiguré. Cet événement est un événement local à l'appareil.
ProxyGuidCreated void ProxyGuidCreated( in GUID proxyGuid, in sequence<IpAddress> ipAddressList) proxyGuid est le GUID créé pour l'appareil non HAVi.
ipAddressList est la liste des adresses IP de l'appareil non HAVi. 25 Lorsqu'un appareil HAVi du réseau souhaite interagir avec un appareil non HAVi sur le réseau (LAV pour Legacy Audio Video device ) il peut installer un module de contrôle d'appareil (DCM) capable de gérer cette interaction. Pour l'identification de cet appareil dans le monde HAVi, il est nécessaire de lui attribuer un GUID sachant qu'un appareil non-HAVi ne possède pas un tel identificateur. L'appareil HAVi souhaitant agir avec lui va donc lui attribuer un GUID et va servir de relais dans le monde HAVi pour cet appareil adressé par ce GUID (proxy en anglais). La création de ce GUID relais va être signalée sur le réseau par cet événement, non local, signalant le GUID relais créé et les adresses IP de l'appareil ainsi identifié.
2864871 19 Le module CMMIP, ainsi implémenté, permet donc de construire la liste des GUID des appareils du réseau et de faire le lien entre les GUID et les adresses IP de ces appareils. Il permet aussi d'envoyer des messages IP sur le réseau à un appareil connu par son GUID ou son adresse IP. Il offre également la possibilité de s'inscrire pour recevoir des messages IP caractérisés par leur origine et le protocole utilisé au-dessus de IP.
Un appareil 6.1 capable de supporté HAVi sur un réseau IP possède une architecture décrite dans la figure 6. Il doit posséder un bus interne 6. 4 reliant un processeur 6.2 qui va exécuter les modules décrits de la pile HAVi. Ces programmes stockés dans la mémoire morte 6.3 de l'appareil vont se charger dans la mémoire vive 6.5 pour l'exécution. Les échanges avec le réseau IP 6.7 vont se faire via l'interface réseau IP 6.6.
Claims (13)
1. Méthode de découverte, par un appareil connectable à un réseau 5 de communication, des autres appareils connectés à ce réseau caractérisée en ce qu'elle comporte les étapes suivantes: - connexion de l'appareil audit réseau; envoi d'un message d'annonce contenant des informations d'auto description décrivant l'appareil à destination de tous les autres appareils connectés à ce réseau; - envoi d'un message de demande d'informations d'auto description à tous les autres appareils connectés à ce réseau; - réception d'un message de réponse de chacun des autres appareils du réseau contenant les informations d'auto description de cet autre appareil.
2. Méthode selon la revendication 1 où le message de demande et le 20 message d'annonce sont confondus.
3. Méthode selon l'une des revendications 1 ou 2 où les informations d'auto description décrivant un appareil contiennent l'adresse sur le réseau de l'appareil.
4. Méthode selon l'une des revendications 1 à 3 où les informations d'auto description décrivant un appareil contiennent un identificateur global unique, différent de l'adresse, identifiant l'appareil sur le réseau.
5. Méthode selon l'une des revendications 1 à 4 où les informations d'auto description décrivant un appareil contiennent les caractéristiques d'un module logiciel permettant de contrôler cet appareil. 15
2864871 21
6. Méthode selon l'une des revendications 1 à 5 où le message d'annonce est envoyé en diffusion générale sur le réseau.
7. Méthode selon l'une des revendications 1 à 5 où le message d'annonce est envoyé en diffusion multipoint sur une adresse de diffusion multipoint prédéfinie à laquelle les autres appareils doivent être abonnés.
8. Appareil connectable à un réseau caractérisé en ce qu'il possède des moyens d'envoyer un message d'annonce, contenant des informations d'auto description le décrivant, à tous les autres appareils du réseau, des moyens d'envoi d'un message de demande d'informations d'auto description à tous les autres appareils du réseau et des moyens de réception des messages de réponses contenant des informations décrivant chacun des autres appareils du réseau.
9. Appareil selon la revendication 8 où les informations d'auto description décrivant un appareil contiennent l'adresse sur le réseau de l'appareil.
10. Appareil selon l'une des revendications 8 à 9 qui comporte des moyens permettant de générer un identificateur global unique, différent de l'adresse de l'appareil, sur le réseau.
11. Appareil selon l'une des revendications 8 à 10 où les informations d'auto description décrivant un appareil contiennent les caractéristiques d'un module logiciel permettant de contrôler cet appareil.
12. Appareil selon l'une des revendications 8 à 11 qui comporte des 30 moyens d'envoi du message d'annonce en diffusion générale sur le réseau.
2864871 22
13. Appareil selon l'une des revendications 8 à 11 qui comporte des moyens d'envoi du message d'annonce en diffusion multipoint sur une adresse de diffusion multipoint prédéfinie à laquelle les autres appareils doivent être abonnés.
Priority Applications (9)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0400072A FR2864871A1 (fr) | 2004-01-06 | 2004-01-06 | Methode de decouverte d'un reseau domestique et appareil implementant la methode |
| JP2006548296A JP4592707B2 (ja) | 2004-01-06 | 2005-01-04 | 家庭内ネットワークの発見方法及びその方法を実装する装置 |
| DE602005016214T DE602005016214D1 (de) | 2004-01-06 | 2005-01-04 | Discovery-verfahren eines häuslichen netzwerks und das verfahren implementierende einrichtung |
| CN2005800018894A CN1906895B (zh) | 2004-01-06 | 2005-01-04 | 家用网络的发现方法和实现该方法的设备 |
| KR1020067012900A KR101157575B1 (ko) | 2004-01-06 | 2005-01-04 | 가정용 네트워크의 발견 방법과 그러한 발견 방법을 구현하는 디바이스 |
| PCT/EP2005/050024 WO2005067210A1 (fr) | 2004-01-06 | 2005-01-04 | Procede de decouverte d'un reseau domestique et dispositif de mise en oeuvre dudit procede |
| BRPI0506450-3A BRPI0506450A (pt) | 2004-01-06 | 2005-01-04 | método de descoberta de uma rede doméstica e dispositivo implementando o método |
| EP05726201A EP1702436B1 (fr) | 2004-01-06 | 2005-01-04 | Procede de decouverte d'un reseau domestique et dispositif de mise en oeuvre dudit procede |
| US10/584,644 US7844660B2 (en) | 2004-01-06 | 2005-01-04 | Method of discovery of a domestic network and device implementing the method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0400072A FR2864871A1 (fr) | 2004-01-06 | 2004-01-06 | Methode de decouverte d'un reseau domestique et appareil implementant la methode |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2864871A1 true FR2864871A1 (fr) | 2005-07-08 |
Family
ID=34673857
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0400072A Pending FR2864871A1 (fr) | 2004-01-06 | 2004-01-06 | Methode de decouverte d'un reseau domestique et appareil implementant la methode |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US7844660B2 (fr) |
| EP (1) | EP1702436B1 (fr) |
| JP (1) | JP4592707B2 (fr) |
| KR (1) | KR101157575B1 (fr) |
| CN (1) | CN1906895B (fr) |
| BR (1) | BRPI0506450A (fr) |
| DE (1) | DE602005016214D1 (fr) |
| FR (1) | FR2864871A1 (fr) |
| WO (1) | WO2005067210A1 (fr) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2603380A1 (fr) | 2005-03-30 | 2006-10-05 | Welch Allyn, Inc. | Communication d'informations entre une pluralite d'elements d'un reseau |
| AU2007307196B2 (en) | 2006-10-04 | 2012-02-09 | Welch Allyn, Inc. | Dynamic medical object information base |
| JP2008097297A (ja) * | 2006-10-11 | 2008-04-24 | Nippon Telegr & Teleph Corp <Ntt> | 通信装置、通信方法および通信プログラム |
| US7730516B2 (en) | 2007-02-27 | 2010-06-01 | Sony Corporation | TV-centric system |
| WO2009035673A1 (fr) | 2007-09-12 | 2009-03-19 | Trustees Of Columbia University In The City Of Newyork | Compositions et procédés de traitement de la dégénérescence maculaire |
| US20120149471A1 (en) * | 2009-06-25 | 2012-06-14 | Pioneer Corporation | Mixer device, reproduction system, player, and program |
| WO2013091147A1 (fr) * | 2011-12-23 | 2013-06-27 | Intel Corporation | Procédé et appareil de suivi de localisation sans fil |
| GB2504725B (en) * | 2012-08-08 | 2017-01-11 | Samsung Electronics Co Ltd | Resource sharing between devices |
| JP2016513983A (ja) | 2013-02-06 | 2016-05-19 | ソナベーション， インコーポレイテッド | 指組織内に埋め込まれた皮下構造の３次元撮像のためのバイオメトリック感知デバイス |
| CN104618375B (zh) * | 2015-01-30 | 2018-09-28 | 普联技术有限公司 | 一种网络设备的发现方法及装置 |
| CN113587393B (zh) * | 2021-08-05 | 2022-11-29 | 青岛海信日立空调系统有限公司 | 中央空调控制系统 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2000077618A2 (fr) * | 1999-06-14 | 2000-12-21 | Sun Microsystems, Inc. | Service de decouverte de recherche |
| US20020062366A1 (en) * | 1998-11-25 | 2002-05-23 | Joydeep Roy | System for network device location |
| US20020120672A1 (en) * | 2001-02-27 | 2002-08-29 | Butt Alan B. | Network management |
| US6466549B1 (en) * | 1999-04-12 | 2002-10-15 | Intel Corporation | Broadcast discovery in a network having one or more 1394 buses |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5187787B1 (en) * | 1989-07-27 | 1996-05-07 | Teknekron Software Systems Inc | Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes |
| US6052750A (en) * | 1998-01-06 | 2000-04-18 | Sony Corporation Of Japan | Home audio/video network for generating default control parameters for devices coupled to the network, and replacing updated control parameters therewith |
| US8032833B1 (en) | 1999-07-27 | 2011-10-04 | Samsung Electronics Co., Ltd. | Home network device information architecture |
| US7200848B1 (en) * | 2000-05-09 | 2007-04-03 | Sun Microsystems, Inc. | Migrating processes using data representation language representations of the processes in a distributed computing environment |
| US7243356B1 (en) * | 2000-05-09 | 2007-07-10 | Sun Microsystems, Inc. | Remote method invocation with secure messaging in a distributed computing environment |
| US7260543B1 (en) * | 2000-05-09 | 2007-08-21 | Sun Microsystems, Inc. | Automatic lease renewal with message gates in a distributed computing environment |
| US7188251B1 (en) * | 2000-05-09 | 2007-03-06 | Sun Microsystems, Inc. | System and method for secure message-based leasing of resources in a distributed computing environment |
| US7016966B1 (en) * | 2000-05-09 | 2006-03-21 | Sun Microsystems, Inc. | Generating results gates in a distributed computing environment |
| US7577834B1 (en) * | 2000-05-09 | 2009-08-18 | Sun Microsystems, Inc. | Message authentication using message gates in a distributed computing environment |
| US6917976B1 (en) * | 2000-05-09 | 2005-07-12 | Sun Microsystems, Inc. | Message-based leasing of resources in a distributed computing environment |
| US6898618B1 (en) * | 2000-05-09 | 2005-05-24 | Sun Microsystems, Inc. | Client-specified display services in a distributed computing environment |
| JP2002099473A (ja) | 2000-09-25 | 2002-04-05 | Casio Comput Co Ltd | ネットワーク上のサービス情報収集方法、ネットワーク上のサービス情報収集装置及びネットワーク上のサービス情報収集プログラムを格納した記録媒体 |
| KR100681625B1 (ko) * | 2002-05-17 | 2007-02-09 | 레노보(베이징)리미티드 | 장치간 동적 네트워킹을 구성하여 리소스 공유를 구현하는 방법 |
-
2004
- 2004-01-06 FR FR0400072A patent/FR2864871A1/fr active Pending
-
2005
- 2005-01-04 WO PCT/EP2005/050024 patent/WO2005067210A1/fr not_active Application Discontinuation
- 2005-01-04 KR KR1020067012900A patent/KR101157575B1/ko active IP Right Grant
- 2005-01-04 BR BRPI0506450-3A patent/BRPI0506450A/pt not_active IP Right Cessation
- 2005-01-04 US US10/584,644 patent/US7844660B2/en not_active Expired - Fee Related
- 2005-01-04 DE DE602005016214T patent/DE602005016214D1/de active Active
- 2005-01-04 JP JP2006548296A patent/JP4592707B2/ja not_active Expired - Fee Related
- 2005-01-04 CN CN2005800018894A patent/CN1906895B/zh not_active Expired - Fee Related
- 2005-01-04 EP EP05726201A patent/EP1702436B1/fr not_active Ceased
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020062366A1 (en) * | 1998-11-25 | 2002-05-23 | Joydeep Roy | System for network device location |
| US6466549B1 (en) * | 1999-04-12 | 2002-10-15 | Intel Corporation | Broadcast discovery in a network having one or more 1394 buses |
| WO2000077618A2 (fr) * | 1999-06-14 | 2000-12-21 | Sun Microsystems, Inc. | Service de decouverte de recherche |
| US20020120672A1 (en) * | 2001-02-27 | 2002-08-29 | Butt Alan B. | Network management |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4592707B2 (ja) | 2010-12-08 |
| CN1906895B (zh) | 2010-12-15 |
| US7844660B2 (en) | 2010-11-30 |
| EP1702436A1 (fr) | 2006-09-20 |
| WO2005067210A1 (fr) | 2005-07-21 |
| DE602005016214D1 (de) | 2009-10-08 |
| BRPI0506450A (pt) | 2006-12-26 |
| JP2007518323A (ja) | 2007-07-05 |
| US20090019136A1 (en) | 2009-01-15 |
| KR101157575B1 (ko) | 2012-06-19 |
| CN1906895A (zh) | 2007-01-31 |
| KR20070028300A (ko) | 2007-03-12 |
| EP1702436B1 (fr) | 2009-08-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20220385658A1 (en) | Voice control of endpoint devices through a multi-services gateway device at the user premises | |
| CN101056310B (zh) | 通信装置 | |
| US7085814B1 (en) | Data driven remote device control model with general programming interface-to-network messaging adapter | |
| US8649386B2 (en) | Multi-interface wireless adapter and network bridge | |
| EP2271054B1 (fr) | Procédé de commande d'une entité d'un réseau distant à partir d'un réseau local | |
| US20020052966A1 (en) | Service discovery protocol server | |
| FR2857187A1 (fr) | Procede de configuration automatique d'un routier d'acces, compatible avec le protocole dhcp, pour effectuer un traitement automatique specifique des flux ip d'un terminal client | |
| EP2494747A1 (fr) | PROCÉDÉS ET DISPOSITIFS DE ROUTAGE DE PAQUETS DE DONNÉES ENTRE RÉSEAUX IPv4 ET IPv6 | |
| WO2020254766A1 (fr) | Procede et dispositif d'obtention d'une adresse ip | |
| FR2864871A1 (fr) | Methode de decouverte d'un reseau domestique et appareil implementant la methode | |
| EP2883341B1 (fr) | Dispositif et procede de mise a disposition de services dans un reseau de communication | |
| EP2543165B1 (fr) | Pilotage d'un dispositif d'un reseau distant a partir d'un reseau local | |
| FR3023098A1 (fr) | Procede et systeme de traitement d'une demande de resolution d'un nom d'un serveur, emise par une application cliente sur un reseau de communication. | |
| US20100166002A1 (en) | System and method of connecting two networks | |
| FR2837045A1 (fr) | SYSTEME ET PROCEDE DE GESTION DE TRANSFERT D'INFORMATIONS SUR UN RESEAU CONFORME A UNE NORME DE TRANSMISSION DE DONNEES, NOTAMMENT LA NORME UPnP, MACHINE D'INTERFACAGE ET D'EMULATION ET PROGRAMME D'ORDINATEUR CORRESPONDANTS | |
| EP2614630B1 (fr) | Traitement de données pour la notification d'un équipement | |
| EP1872530B1 (fr) | Procede de transfert d'un code d'information entre deux dispositifs de communication | |
| EP2080404B1 (fr) | Serveur descripteur de région et procédé de sélection d'un réseau sans fil | |
| EP2418821B1 (fr) | Procédé de commande d'une entité d'un premier réseau à partir d'un deuxième réseau | |
| EP1432213A1 (fr) | Plate-forme de médiation et réseau de transport de messages | |
| EP1128636A1 (fr) | Procédé pour constituer des répertoires dans des terminaux en réseau | |
| EP1649664A1 (fr) | Reseau de communications ip, a equipements a selection directe de service | |
| MXPA06007739A (en) | Method of discovery of a domestic network and device implementing the method | |
| WO2010086570A1 (fr) | DETECTION D'UN DISPOSITIF DE CONTROLE UPnP ET MISE EN RELATION AVEC UN TERMINAL | |
| FR2835370A1 (fr) | Systeme et procede de gestion d'une communication entre un module emetteur et au moins un module destinataire, au sein d'un reseau audiovisuel domestique |