Brevet FR3003717A1 — publié le 20140926

Domaine de l'invention La présente invention concerne d'une façon générale les environnements informatiques permettant à une pluralité d'utilisateurs de partager des espaces (de travail collaboratif, de jeu, etc.) de façon virtuelle et 5 synchronisée. Etat de la technique On connaît déjà dans l'état de la technique un certain nombre d'initiatives et de solutions permettant de travailler de façon collaborative sur 10 un document, de jouer eu réseau, etc. Ces solutions sont toutefois le plus souvent mono-plateforme et mono-environnement. En outre, elles exigent généralement des ressources dédiées et spécialisées en fonction du type d'application visée. Ainsi on ne connaît aucun environnement qui permette de partager 15 des activités numériques de types variés, de supporter des variétés d'équipements numériques et de systèmes d'exploitation, et également de créer de nouvelles activités numériques à partager, tout en gardant des couches de communication simples et faciles à gérer. 20 Résumé de l'invention La présente invention vise à pallier tout ou partie des limitations des plateformes existantes. Elle propose à cet effet un environnement informatique, comprenant un ensemble de postes clients reliés en réseau à des moyens serveurs, ledit 25 environnement étant apte à exécuter de façon partagée sur les postes clients des applications mettant en jeu des objets et des ressources, caractérisé en ce qu'il comprend : - des moyens de synchronisation de comportements aptes à synchroniser en temps réel ou quasi-réel les comportements d'objets 30 restitués dans une application donnée au niveau des différents postes clients, - des moyens de gestion d'objets aptes à organiser la création, la modification et la suppression d'objets à l'initiative de postes clients, et - un système de messagerie de bas niveau commun apte à véhiculer l'ensemble des informations entre les postes clients et les moyens serveurs, relatives à la synchronisation des comportements et à la gestion des objets. L'invention propose également de façon préférentielle mais facultative les caractéristiques additionnelles suivantes, prises isolément ou en toutes combinaison techniquement compatibles : * les moyens de synchronisation sont aptes à mettre en oeuvre un mécanisme de verrouillage/déverrouillage des objets. les moyens de synchronisation comprennent un mécanisme d'arbitrage entre requêtes de verrouillage d'objets à partir de postes clients différents. * le mécanisme d'arbitrage comprend des moyens d'ordonnancement temporel des requêtes par rapport à une échelle de temps serveur propagée aux postes clients en prenant en compte le temps de propagation des messages du système de messagerie des moyens serveurs vers les postes clients. * l'un des objets consiste en un gestionnaire d'objets, et le mécanisme de verrouillage/déverrouillage des objets est apte à verrouiller le gestionnaire d'objet en vue de la création et de la modification d'objets. * les moyens de synchronisation sont aptes à véhiculer des commandes d'entrée standard, et il est prévu au niveau des postes clients des moyens pour convertir lesdites commandes standard en commandes 25 adaptées aux systèmes d'exploitation des postes clients. * l'environnement comprend en outre des moyens de gestion de session aptes à gérer l'entrée de postes clients dans un partage d'application et la sortie desdits postes clients dudit partage d'application, les informations mises en jeu par lesdits moyens de gestion de session étant également 30 véhiculées par le serveur de messagerie de bas niveau. * lequel l'entrée d'un poste client dans un partage d'application est mise en oeuvre par transfert des objets non verrouillés vers ledit poste client, puis transfert des objets qui étaient verrouillés vers ledit poste client après leur déverrouillage. * l'environnement comprend en outre des moyens pour propager des moyens serveurs vers les postes clients des paquets applicatifs à partager, un paquet applicatif comprenant un fichier de description d'application, un ou plusieurs fichiers de description de comportements, de préférence en langage interprété, et des fichiers de ressources. * l'environnement comprend en outre des moyens de partage d'applications exécutées localement sur un poste client donné, aptes à recopier une représentation graphique d'une application exécutée localement sur un poste client vers d'autres postes clients participant au partage, et des moyens pour contrôler les commandes d'entrée sur ladite application exécutée localement de façon à y appliquer sélectivement des commandes d'entrée générées sur ledit poste client et des commandes d'entrée générées par d'autres postes clients participant au partage et véhiculées via ledit système de messagerie de bas niveau. 2 0 Brève description des dessins D'autres aspects, buts et avantages de la présente invention apparaîtront mieux à la lecture de la description détaillée suivante d'une forme de réalisation préférée de celle-ci, donnée à titre d'exemple non limitatif et faite en référence aux dessins annexés, sur lesquels : 25 La Figure 1 est un schéma de l'architecture globale de l'environnement de partage selon l'invention, La Figure 2 illustre les fonctionnalités d'un poste client en liaison avec l'environnement, de façon organisée en couches de différents niveaux logiques, La Figure 3 illustre les fonctionnalités de moyens serveurs en liaison avec l'environnement, de façon organisée en couches de différents niveaux logiques, La Figure 4 illustre un processus de synchronisation de certaines 5 commandes par trames de messagerie entre des clients et les moyens serveurs selon l'invention, Les Figures 5 et 6 sont des organigrammes illustrant la gestion d'une demande de verrouillage et d'une demande de déverrouillage ou relâchement d'un objet par un client, 10 La Figure 7 est un organigramme illustrant un processus d'entrée d'un client dans une session partagée, et La Figure 8 illustre un processus de prise/relâchement de verrou pour la création ou la modification d'objet par un client. 15 Description détaillée d'une forme de réalisation préférée 1) Définitions Espace Virtuel : Espace logique pouvant représenter n'importe quelle espace réel autour duquel se rassemblent plusieurs personnes (participants) par le 20 biais d'équipements ou terminaux intelligents (ordinateur individuel, tablette, assistant numérique personnel, téléviseur intelligent, etc.). Monde Virtuel : Espace graphique virtuel prédéfini (par exemple un plateau d'échecs comportant le plateau, les pièces, une horloge et deux participants, ou bien une salle de classe avec un tableau, des « post-it » (marque 25 déposée), une application informatique partagée, un professeur et plusieurs élèves, etc.). Plateforme : Ensemble des outils (applications, machines clientes et serveurs, base de données,..) agissant de façon communicante et synchronisée dans un espace virtuel. 30 Synchronisation temps réel : Communication en temps réel de toutes les interactions des participants dans l'espace virtuel. Représentation commune de l'espace virtuel pour tous les participants en temps réel ou quasi-réel (c'est-à-dire aux latences de traitement et de réseau près). Client: Application sur l'équipement ou terminal d'un participant, permettant la représentation de l'espace virtuel et les actions dans cet espace, soit automatiques (typiquement par des scripts), soit en réponse à des commandes de participant au niveau de dispositifs d'entrée (clavier, souris, capteurs, etc.). Serveur: Application hébergée sur une machine distante qui permet la connexion et la communication de tous les clients entre eux. Il contrôle les 10 actions des clients quand nécessaire et assure leur synchronisation. Objet: Entité virtuelle dans l'espace virtuel. Ressource: Donnée permettant la représentation d'un objet (Image, texte, flux vidéo, son, etc.). 15 2) La plateforme La plateforme se compose d'application clients (multi-environnements) et de différents types de serveurs. Elle permet de mettre en oeuvre simplement des applications dans lesquels différents utilisateurs peuvent communiquer dans un espace virtuel 20 (Webcam, voix, messagerie, ...), interagir avec cet espace virtuel, partager des fichiers numériques ou partager des applications exécutées sur leur poste de travail. La Figure 1 des dessins illustre l'architecture globale de la plateforme. Elle comprend : 25 - un serveur de session SS : il gère l'authentification et les droits des différents utilisateurs et permet de créer et rejoindre des sessions de communication. C'est le point d'entrée de tout client et il permet la régulation des autres serveurs en démarrant les sessions sur les servers les moins chargés. Il communique avec une base de données d'utilisateurs DB, locale 30 ou distante. - un serveur logique SL : c'est un serveur temps réel qui gère la synchronisation de tous les objets virtuels. - un serveur de partage d'applications SPA : c'est un serveur temps réel, qui gère les flux visuels des applications partagées. - un serveur de flux SF (« streaming » en terminologie anglo- saxonne) : il s'agit d'un serveur temps réel qui diffuse des flux vidéo et audio. - un serveur de transfert de fichiers STF : ce serveur permet aux utilisateurs de s'échanger des fichiers. L'une des fonctions de la plateforme est de pouvoir diffuser de façon simple et rapide, puis partager, des applications de types variés vers des clients de différents types (ordinateurs, tablettes, assistants numériques personnels, etc.), ayant des caractéristiques matérielles différentes et des systèmes d'exploitation différents. 3) Le client La configuration d'un poste client est illustrée sur la Figure 2. Dans une description en couches, partant de la couche de plus haut niveau et allant vers la couche de plus bas niveau, on trouve : - Couche 1 : couche « Monde », incluant tous les éléments d'un « monde virtuel », à savoir principalement les utilisateurs et la description de chaque monde et de son comportement (application). Cette couche ne fait pas partie de la plateforme mais l'utilise en étant interfacée avec elle. L'application est codée dans le langage de script offert par la plateforme et est indépendante de l'environnement d'exécution (type de machine, de système d'exploitation, etc.) - Couche 2 : couche d'interaction. Elle comprend notamment des moteurs de rendu (visuel, sonore, etc.), en fonction des capacités de restitution du la plateforme matérielle. Il comprend également les interfaces avec les dispositifs d'entrée (et le cas échéant sortie) à disposition de l'utilisateur (clavier, souris, « trackpad », manette de jeu, écran tactile, etc.) pour la plateforme matérielle. Couche 3 : interpréteur de monde virtuel. C'est le module qui permet l'interprétation de l'application et offre le système de développement. Couche 4 : couche logique. Elle est composée d'un certain nombre de modules logiques pour la gestion des objets, des applications et de leur partage, et des ressources. Couche 5 : couche de communication. Elle contient notamment un module de messagerie temps réel, un module de distribution de contenus en flux, et un module de gestion du transfert de fichiers. Ces modules interagissent avec l'extérieur selon des protocoles spécifiques adaptés à la synchronisation d'un espace virtuel. - Couche 6 : couche réseaux. Couche de plus bas niveau dans l'architecture présentée, elle implémente les différents protocoles de communications nécessaires au transfert des données par le réseau Internet. (Socket TCP, HTTP, FTP, etc.). 4) Les serveurs La figure 3 illustre l'architecture générale d'un serveur logique utilisé dans la présente invention. On y retrouve les même couches 4, 5 et 6 du que celles du client. La plus grande différence réside dans le fait que la couche logique (couche 4) du serveur est en charge de la synchronisation des objets et des ressources. La couche de communication ne comprend quand à elle que le module de messagerie, les flux et transferts de fichiers étant gérés séparément. Ainsi l'environnement de l'invention comprend également un certain 25 nombre d'autres autres serveurs, avec là encore cette architecture en trois couches, et des modules propres dédiés à la fonction ou aux fonctions qu'ils implémentent (streaming, transfert de fichiers, etc.). 5) Espace virtuel 30 5.1) Description générale Chaque poste client, doté d'un dispositif d'affichage, est apte à afficher sur celui-ci une vue d'un l'espace virtuel partagé entre une pluralité de postes clients. Cet espace virtuel est composé de différents types d'objets obéissant à des règles de synchronisation différentes : - des objets locaux : ils sont propres à un client et ne nécessitent aucune synchronisation. En règle générale, le serveur de les connaît même pas. - des objets globaux : les participants peuvent agir sur ces objets 10 (par exemple les déplacer, changer leur état), ces actions sont synchronisées entre les différents clients. - des objets système : ils possèdent chacun leurs propres règles de synchronisation. Les divers objets peuvent être des objets parents ou enfants d'autres 15 objets. 5.2) Objets locaux Comme on l'a indiqué, aucune synchronisation de ces objets n'est nécessaire. Ils sont initialisés par le client, et aucune information concernant 20 ces objets n'est à communiquer aux autres clients. Seul le client hébergeant un tel objet peut interagir avec lui. Il peut s'agir par exemple de menus d'interface, de ressources locales de différents types, etc. 25 5.3) Objets globaux Ces objets peuvent être modifiés par les différents clients. Chaque changement d'état d'un objet global doit être synchronisé entre les différents clients. C'est le serveur qui est maître de ces objets et connait leur propriétés à un instant t, et les clients possèdent une copie de l'objet. 30 Des exemples d'objets globaux sont : - dans des environnements de jeu en réseau, un pion déplaçable sur un plateau de jeu, une carte d'un jeu de cartes, un dé, etc. ; - dans un environnement collaboratif, un élément de type « PostIt » virtuel, etc. ; - une conversation de messagerie écrite instantanée, - un fichier d'un environnement de bureautique (fichier texte, tableur, présentation, etc. - tous autres objets susceptibles d'avoir des propriétés ou états que les différents participants, au niveau de leur client, doivent pouvoir 10 modifier. 5.4) Objets système L'environnement selon l'invention inclut différents types d'objets système. On trouve en particulier les objets système suivants : 15 - Objet MAIN: un objet système de type « Main » (curseur en forme de main) est prévu au niveau de chaque client. Chaque utilisateur peut ainsi contrôler son objet Main pour agir sur les objets représentés sur son dispositif d'affichage ; la main permet d'agir sur les objets, chaque client contrôle sa main et ne peut interagir avec les autres mains. Les positions 20 des mains et leurs états sont synchronisés en permanence. - Objet PARTICIPANT : un tel objet rassemble toutes les informations relatives à un participant. Certaines de ces informations peuvent avoir à être synchronisées, mais définies par le système (pseudo, id, propriétaire, etc.), tandis que d'autres informations peuvent être rajoutées et 25 modifiées par les participants (nom d'un personnage, d'une équipe, etc.) - Objet CONTROLEUR D'OBJETS : cet objet gère la création et la suppression de tous les autres objets. Cet objet est synchronisé et donc connu du serveur. Il est dupliqué vers un client qui souhaite en prendre le contrôle. Objet CONTROLEUR DE RESSOURCES : il gère la création et la suppression des ressources. Cet objet est synchronisé et donc connu du serveur. 5.5) Attributs des objets Un objet comprend notamment les différents attributs suivants : Portée (local, global ou système) : cet attribut est unique et fixe. Type (dé, bouton, carte, pion, etc.) : unique et invariable. ID : identifiant de l'objet dans l'environnement, par exemple nombre entier, unique et invariable. - Parent : identifiant ID de l'objet parent, unique mais variable. - Propriétaire : identifiant du participant maître de l'objet, unique et variable. - Ressource graphique : ID d'une ressource visuelle, unique et 15 variable. - Ressource sonore : ID d'une ressource audio, qui peut être multiple et variable. - Valeur déterministe : un objet peut avoir n'importe quelle fnombre de ces propriétés, elles sont de type simple (entier, flottant, booléen, 20 chaine caractère de taille maximum définie) et sont modifiables par un client. (Exemple : coordonnées X/Y, face d'une carte, dernières phrases d'une conversation, etc.). - Valeur aléatoire : de type simple mais générée aléatoirement ; le client ne peux pas calculer/définir cette valeur (exemple : face d'un dé lors 25 d'un tirage de dé virtuel) ; c'est le serveur qui la génère. - Valeur temporelle : une durée, date, etc. ; à nouveau, cette propriété ne peut pas être définie par le client et est définie uniquement par le serveur. - Local : Propriété pouvant être de n'importe quel type, qui n'est 30 jamais synchronisée avec les autres clients. - A un instant t, le client doit pouvoir déterminer tout ce qui est nécessaire pour représenter l'objet localement à partir de ses propriétés. 5.6) Ressources Les ressources sont aptes à être être créées à l'aide de l'objet CONTROLEUR DE RESSOURCES. Il peut s'agir : d'un fichier local intégré à l'application, présent sur tous les clients ; - d'un flux audio ; - d'un flux vidéo ; - d'un flux d'application partagée (voir plus loin) ; - d'un fichier local sur un poste client, à partager avec les autres clients. Les flux audio et vidéo transitent par les serveurs de flux. Le flux d'application partagée transite via le serveur dédié de partage d'application. Les fichiers transitent par le serveur de transfert de fichiers. 5.7) Paquets Les applications sont définies dans des « paquets » (« package » en terminologie anglo-saxonne), un paquet étant un répertoire de données indépendant contenant toutes les ressources nécessaires à l'exécution de la plateforme sur un poste client. Un paquet contient : - un fichier de description de l'application ; - un ou plusieurs fichiers de description de comportements, de préférence en langage interprété ; - des fichiers de ressources multimédia (sons, vidéos, images, notamment images graphiques d'objets déplaçables et image graphique 30 d'une « table » ou environnement graphique de la plateforme - par exemple un échiquier, etc.). La plateforme définit le formalisme : - du fichier de description ; - de l'interfaçage des comportements avec la plateforme ; - des formats compatibles pour les ressources. Le lancement d'une application met en jeu trois fonctions principales qui sont définies dans le paquet : - Tlnit() pour initialiser les données et objets présents sur la table ; - TFrameUpdate() pour mettre a jour de façon cyclique, ou 10 déclenchée par des évènements, les objets, selon des comportements programmés ; - TShut() pour détruire les objets créés et mis à jour par les fonctions Tin«) et TFramelUpdate() respectivement. Les interactions entre les moyens serveurs et les clients sont 15 matérialisées par des trames, comme on le décrira dans la suite. 6) Représentation et interaction 6.1) Rendu Avantageusement, la plateforme peut proposer des interfaces de 20 programmation d'applications (API) de bas niveau dont les rendus sonores et visuels sont identiques quel que soit le système d'exploitation. 6.1.1) Rendu visuel La représentation graphique d'un monde virtuel est fondée sur le 25 rendu des objets en fonction de leurs propriétés et de leurs ressources. La plateforme possède son propre moteur de rendu, indépendant du type de machine et de système d'exploitation, exécutable en s'appuyant sur une couche logicielle intermédiaire d'adaptation, l'ensemble étant contenu dans le paquet. 30 Le moteur de rendu choisi est capable s'adapter aux résolutions d'écran des différentes machines et intègre, pour toutes les tailles ou définitions d'écran ne permettant pas l'affichage global lisible de l'ensemble du monde virtuel, des fonctionnalités de zoom et de déplacement (scroli) dans le monde virtuel. De préférence, ces fonctionnalités opèrent selon les règles suivantes : - lorsque l'écran est trop petit pour afficher la table, on peut appliquer un facteur de zoom 1 pour agrandir l'image et afficher les objets dans une taille satisfaisante pour l'utilisateur. - lorsque la table affichée n'est pas représentée en intégralité, l'utilisateur peut faire défiler la partie affichée sur l'écran dans la direction souhaitée et ainsi visualiser n'importe quelle partie de la table. 6.1.2) Autres rendus Les objets peuvent être composés de différents types de ressources qui seront rendus par différent moteurs selon ce que permettent les 20 équipements matériels des différentes machines (sons, vibrations, etc.) Ainsi une application n'a pas à se préoccuper de savoir quel type de matériel est présent, la plateforme gérant tous les rendus d'un objet en fonction des possibilités de la machine. 25 6.2) Interaction Chaque participant peut interagir avec l'environnement partagé en disposant de sa propre « main » virtuelle (un objet système MAIN) pour contrôler tout objet. Un clavier (physique ou virtuel) permet de saisir du texte notamment pour un service de messagerie texte instantanée entre 30 utilisateurs. La plateforme convertit les entrées (clavier, souris, écran tactile, etc.) du matériel du poste client pour en faire des actions génériques permettant de contrôler les objets. Un premier type d'entrée permet de sélectionner un objet pour le déplacer (type « click and drag » en terminologie anglo-saxonne). Des actions des objets respectifs peuvent également être sélectionnées, avec des actions primaires opérables par des gestes simples (double-click, etc.) et des actions secondaires opérables par sélection dans une liste apparaissant par exemple dans un menu surgissant (pop-up). Plus précisément, la plateforme définit des codes d'action correspondant respectivement à ces actions, et des correspondances entre les pilotes du système d'exploitation, qui permettent de récupérer l'état des entrées de la machine, et ces codes d'action. Ces correspondances permettent : - d'intégrer tout type de périphérique de saisie (clavier, souris, écran tactile, webcam avec reconnaissance de mouvement, gant équipé de capteurs, etc.), - de disposer des mêmes capacités d'interaction quels que soient le matériel et le système d'exploitation du poste client, sous réserve des équipements matériels disponibles, - de retranscrire a distance une action d'un utilisateur sur un type de machine, pour action identique sur un autre type de machine (fonction utilisable notamment dans le partage d'applications, décrit plus loin). 7) Description et interprétation du monde virtuel La couche 3 de chaque client offre des interfaces de programmation dans un langage de script défini pour pouvoir écrire les différentes applications correspondant à différents espaces virtuels. Elle comprend un interpréteur de scripts (ainsi que d'autres interpréteurs le cas échéant) et des fonctionnalités permettant d'accéder aux objets du monde virtuel (lecture et écriture de leurs propriétés notamment). Il est ainsi possible de créer simplement différents espaces virtuels à l'aide d'un fichier de scripts et des ressources locales nécessaires, soit préexistantes, soit à créer pour les besoins (fichiers graphiques, etc.). 8) Messages 8.1.) Généralités Chaque message est composé : - d'un identifiant du message (par exemple entier sur 16 bits), - d'un identifiant d'émetteur (par exemple entier sur 32 bits), - d'une information de taille du message (par exemple entier sur 32 bits), et - de l'information spécifique au message. Avantageusement, les messages font l'objet d'une sérialisation binaire pour diminuer leur taille. Un message peut contenir des objets. Dans ce cas, le message est complété par la structure suivante : - identifiant de l'objet (entier sur 16 bits), - identifiant du propriétaire (entier sur 32 bits), correspondant à un identifiant d'émetteur, - liste de propriétés : bloc binaire contenant les informations de propriétés, destinées à être interprétées par les différents par les clients. Ce bloc est sérialisé de la façon suivante : - nombre de propriétés (16 bits), - identifiant de la propriété No. 1 (16 bits), - Taille de propriété No. 1 (16 bits), - Valeur de la propriété No. 1 (bloc de données de la taille indiquée précédemment), - identifiant de la propriété No. 2 (16 bits), - Taille de propriété No. 2 (16 bits), - Valeur de la propriété No. 2 (bloc de données de la taille indiquée précédemment), - et ainsi de suite pour les propriétés suivantes. Pour les messages contenant des objets, il est également avantageux de leur appliquer une sérialisation binaire pour réduire leur taille. 8.2) Types de messages Dans la présente implémentation, le protocole se compose des messages suivants : 10 8.2.1) messages de session ASK CONNECT_SESSION Information de session et d'utilisateur SESSION CONNECTED Connexion accepté/refusé 15 INFORMATION SESSION Information sur la session (participant, durée,..) UPDATE SESSION Modification sur la session (pseudo d'un user, configuration, etc.) 20 8.2.2) messages de synchronisation des objets ASK ACQUIRE Liste d'identifiants d'objets pour demande de verrou, marqueur de temps de la demande 25 RET ACQUIRE Verrou accepté/refusé, objets verrouillés sérialisés ASK RELEASE Identifiant d'objet à relâcher RET_RELEASE 30 Identifiant d'objet relâché, objet sérialisé relâché. ADD ITEM Objet sérialisé à ajouter ITEM_ADDED Objet sérialisé ajouté U PDATE ITEM Propriétés de l'objet à modifier ITEM UPDATED Propriétés de l'objet modifiées REMOVE ITEM Identifiant d'objet à supprimer ITEM_REMOVED Identifiant d'objet supprimé ASK_INIT_TABLE Demande d'initialisation du monde TABLE_ALL_OBJECT Sérialisation du monde (tous les objets et leurs propriétés) ACK TABLE_ALL_OBJECT Valide la fin d'initialisation du monde LOGICAL_FRAME Trame contenant l'identifiant de trame, le temps serveur et un ensemble de messages ACK LOGICAL_FRAME Accusé de réception de trame 8.2.3) Messages de son SOUND_BUFFER Information d'encodage, contenu sonore 8.2.4) Messages de vidéo VIDEO_BUFFER Information d'encodage, contenu vidéo 8.2.5) Messages de fichiers FILE BUFFER Identifiant de fichier, offset, bloc de donné du fichier à l'offset spécifié ASK FILE_BUFFER Identifiant de fichier, offset 8.2.6) Messages de textures dynamiques TEXTURE BUFFER Identifiant de texture, offset, encodage, bloc de données de la texture à l'offset spécifié ASK TEXTURE_BUFFER Identifiant de texture, offset 8.2.7) Messages pour le partage d'applications TEXTURE_BLOCK Identifiant de texture, Identifiant de bloc, encodage, bloc de texture APPLICATION INPUT Identifiant d'application, type entrée, valeur entrée. 8.3) Envoi des messages Un client et le serveur sont connectés en permanence via un connecteur logiciel (socket) TCP et communiquent par l'envoi et la réception 25 de messages, ceci étant géré par les modules de messagerie respectifs dans la couche 5 (voir Figures 2 et 3). Le serveur envoie tous ces messages à chaque client par trames LOGICAL_FRAME numérotées chronologiquement à une fréquence régulière. A chaque réception de trame, un client répond au serveur par un 30 accusé de réception ACK LOGICAL_FRAME lui signalant que la trame a été prise en compte. Ce système de trames permet de : - synchroniser le temps serveur (seul le message LOGICAL_FRAME contient le temps du serveur), à des fins notamment expliquées dans la suite ; - stocker les messages non envoyés à un client (lors de la phase d'initialisation ou si un client ne répond pas à une trame) et les renvoyer si besoin ; - optimiser les écritures du serveur ; - connaître la charge du serveur : si la période d'écriture dépasse celle 10 fixée, le serveur est identifié comme surchargé et les demandes de sessions peuvent être dirigées sur un autre serveur. Les messages de flux (audio, vidéo, etc.) sont transmis directement aux clients via des messages spécifiques sans être stockés dans les trames ; ce sont des messages qui n'ont pas besoin d'être renvoyés. 15 De plus chaque message de flux est aiguillé par le serveur seulement au client nécessaire. Par exemple : - SOUND BUFFER est envoyé seulement aux clients différents de l'émetteur ayant une caractéristique de son active (par exemple un drapeau mémorisé dans le serveur) ; 20 - TABLE_ALL_OBJECT est envoyé seulement à l'utilisateur qui en a fait la requête ; - ADD ITEM est envoyé à tous les utilisateurs différents de l'émetteur. 9) Règles de synchronisation 25 9.1) Cohérence Le serveur est en charge de déterminer et de maintenir l'état global de du monde virtuel perçu par les différents participants au niveau de leurs clients respectifs. Pour garantir la cohérence des données entre les différents clients, l'environnement de la présente invention se fonde sur un système de verrous logiques opérant selon les principes suivants : - un objet global ne peut être modifié que par un seul participant à la fois, pour pouvoir modifier un objet l'objet est verrouillé (opération effectuée par le serveur), le participant devient alors le propriétaire de cet objet et il peut ensuite modifier ses propriétés. - lors d'un changement de propriétaire toutes les propriétés sont synchronisées. La cohérence à l'entrée est obtenue par la mise à jour de la copie d'un objet lors de la prise de verrou par un client, et la cohérence au relâchement est assurée par la mise à jour de toutes les copies d'un objet lors de la libération de verrou. 9.1) Arbitrage pour le verrouillage d'un objet Le serveur doit être à même de déterminer quel client a verrouillé un objet en premier, lorsque plusieurs requêtes de verrouillage lui parviennent. A cet effet, chaque trame contient un indicateur temporel qui permet à chaque client d'utiliser le même temps de référence : le temps t sur un client est déterminé par : t = ts + dt où ts est le temps de référence serveur de la dernière trame et dt est le temps écoulé depuis que le client l'a reçue. Les clients envoient leurs messages au serveur avec l'indicateur temporel calculé comme ci-dessus. La latence des communications client/serveur n'est pas prise en compte dans le calcul du temps, pour que tous les participants puissent agir équitablement quel que soit le débit de leur connexion réseau. Un exemple de cas de synchronisation est illustré sur la Figure 4 des dessins, dans l'hypothèse d'un jeu en réseau où il faut déterminer quel participant a demandé un verrou en premier (message ASK_ACQUIRE) sur un objet Oi avec son objet MAIN. Le serveur envoie les trames T1, T2 aux temps respectifs t1 et t2 (temps serveur), avec des durées de propagation différentes vers les clients 5 CLIENT1 et CLIENT2. Le client CLIENT1 saisit l'objet à tc1 = t2 + 6 (avec t2 côté client CLIENT1), ce qui correspond au temps serveur t2 + 7, tandis que le client CLIENT2 saisit l'objet à tc2 = t2 + 5 (t2 côté CLIENT2), ce qui correspond ici aux temps serveur t2 + 8. C'est toutefois le client CLIENT2 qui dans ce cas 10 prend possession de l'objet (même si en temps réel il a saisit l'objet en second), car par rapport à la réception de la trame t2 au niveau de son poste, c'est lui qui a été le plus rapide à saisir l'objet. Pour réaliser cette fonctionnalité, le serveur attend la fin d'un délai, dont la durée dépend de la fréquence des trames, avant de traiter les 15 messages de saisie d'objet renvoyés par les clients et effectuer les arbitrages, et effectue l'arbitrage à partir de l'indicateur temporel contenu dans la trame. Le délai en question dépend de la fréquence d'envoi de trames ; préférentiellement, un message reçu après la trame Tn est traité lors de 20 l'envoi de la trame Tn+2. Le délai minimum est ainsi d'une période, et si la période de trame est supérieure à la latence maximum de tous les clients, l'équité entre les clients est garantie. 9.3) Verrouillage et modifications 25 Une copie d'un objet global peut être modifiée localement (généralement de façon automatique par un script, par exemple pour animer un objet). Toute modification locale ne peut avoir lieu que si l'objet n'a pas de verrou, le script vérifiant avant son exécution le statut verrouillé ou relâché de l'objet. 30 Ces modifications locales ne sont pas à proprement parler synchronisées. Il est toutefois important que ces modifications soit les mêmes sur tous les clients. Toute modification automatique doit donc être déterminée en fonction du temps synchronisé délivré par le serveur avec les trames. La Figure 5 illustre la logique de prise de verrou plus en détail, avec tout d'abord la vérification générale d'une demande de prise de verrou non traitée (boîte 502), puis dans l'affirmative la vérification du fait que cette demande précédente non traitée concerne ou non le même objet (boîte 503). Ensuite, le processus vérifie (boîte 504) si l'objet n'est pas déjà verrouillé. Exemple - temps serveur tn (temps réception trame Tn) : réception d'une Trame Tn par les clients. - tn+10 : demande de verrou sur objets a, b, c par un client Cx, - la demande est insérée par le serveur dans une liste triée temporellement - temps serveur tn+1 (temps réception trame Tn+1) : traitement des demandes de verrous reçus à tn-1 (temps réception de la trame Tn-1) - tn+9 : demande de verrou sur un objet c par un client Cy - Insertion de la demande dans la liste précitée, avant celle sur a,b,c car tn+9 S S : SESSION CONNECTED->U1 S: INFORMATION SESSION->U1 S: RET_ACQUIRE(itemManager)->U1 U1: ADDITEM(Item X)->S Ul:ASK RELEASE(itemManager)->S S: ITEM_ADDED(Item X)->U1 S: RET_RELEASE(ItemManager)-> U1 U2 : ASK CONNECT_SESSION -> S S : SESSION CONNECTED->U2 S: INFORMATION_SESSION->U1,U2 U2 :ASK_INIT_TABLE->S U1:ASK_ACQUIRE(item X) S: TABLEALL_OBJECT->U2 S:RET_ACQUIRE(Item X)->U1 envoyé à U2 durant son envoyé à U2 durant son U1 :UPDATE _ITEM(Item X)->S S:UPDATE ITEM(Item X)->U1 U2:ACK_TABLE_ALL_OBJECT->S U1:ASKRELEASE(Item X)->S S:RET_ACQUIRE(Item X)->U2 (message non initialisation) S: UPDATE ITEM(Item X)->U2 (message non initialisation) S:RET_RELEASE(Item X)->U1,U2 9.5) Création d'éléments Pour la création d'un élément (objet ou ressource) au niveau d'un client, ce dernier doit acquérir le contrôleur nécessaire. Il en va de même pour la suppression d'un élément. Un exemple de processus associé est illustré sur la Figure 8. IM désigne le contrôleur d'objets (Item Manager en terminologie anglo-saxonne). Oi(x) désigne l'objet d'identifiant i, ayant un attribut de valeur x. ASK ACQUIRE(...) désigne la demande de prise de verrou sur le contrôleur d'objets (IM) ou sur un objet (Oi(x)). ASK_RELEASE(...) désigne le relâchement d'un tel verrou. p désigne la propagation d'un objet modifié après relâchement. p' désigne une nouvelle propagation de l'objet modifié après relâchement. Dans une première phase, le client CLIENT1 prend un verrou sur le contrôleur d'objets IM (qui est un objet système) au niveau du serveur, en vue de l'ajout d'un objet global 01(x) (commande ADD_ITEM(O1(x))) au niveau du client CLIENT1, objet qui est envoyé alors au serveur. Le contrôleur d'objets est ensuite relâché. Ultérieurement, le client CLIENT1 prend un verrou sur l'objet 01 au niveau du serveur (commande ASK ACQUIRE(01)) pour le modifier. La modification est transférée au serveur (on notera qu'il est possible soit de recopier l'objet dans CLIENT1 pour le modifier localement et le renvoyer ensuite au serveur, soit d'envoyer directement au serveur des ordres de modification de l'objet 01, ordres appliqués sur l'objet 01 tel que mémorisé dans le serveur). L'objet 01 est ensuite relâché (commande ASK_RELEASE(01)). Si pendant la phase de modification de 01, un client CLIENT2 envoie une requête d'initialisation ASK INIT_TABLE pour participer à l'environnement (autrement dit accéder au monde, à la table, etc.), la lecture de l'objet 01 faisant partie de cet environnement par le client CLIENT2 (une commande qu'on désigne par READ(01(x))) ne peut s'effectuer que sur la version de 01 avant modification. Vers la fin de la lecture de 01 par CLIENT2, le serveur propage (p) la nouvelle valeur de 01 vers les clients (dont CLIENT2) lors du relâchement du verrou sur 01 qui avait été demandé par CLIENT1 (relâchement intervenant après que CLIENTI ait achevé la modification de 01(x) pour le transformer en 01(y)). Or CLIENT2 accusant réception du monde (ACK_TABLE_ALL_OBJECT) seulement après la propagation p de l'objet modifié 01(y), le serveur prend alors l'initiative de propager à nouveau (en p') l'objet modifié 01(y). Ensuite, dès qu'un client (ici à nouveau CLIENTI) modifie l'objet 01 selon le même processus, ici pour le transformer de 01(y) en 01(z), l'objet modifié, après réception par le serveur, est automatiquement propagé aux postes clients concernés, à savoir ceux participant à la session dont CLIENT2. 9.6) Tolérance aux erreurs 9.6.1) Message non reçu par un client Le serveur de messagerie conserve en mémoire toutes les trames envoyés aux clients, jusqu'à recevoir la confirmation des clients de la bonne 30 prise en compte des trames. Lors de l'envoi d'une trame, le serveur de messagerie renvoie également toutes les trames depuis la dernière confirmation reçue. Au bout d'un certain nombre de trames sans réponse de la part d'un client (mise en oeuvre d'une routine de comptage), l'information est passée du serveur de messagerie au serveur de session, pour que le client en question soit déclaré déconnecté. Il devra alors repasser par une phase d'initialisation pour accéder à l'environnement. 9.6.2) Message non reçu par le serveur Si une demande de verrou n'est pas reçue par le serveur de messagerie, le client n'obtient pas le verrou et ne peut agir sur l'objet ou le gestionnaire considéré. Si un relâchement de verrou n'est pas reçu par le serveur de messagerie, alors : - soit le client est toujours en attente de relâchement et réitère son message ; - soit le client à été déconnecté (voir plus haut), auquel cas tous ses verrous pris par ce client sont relâchés. 10) Partage d'une application La plateforme offre la possibilité de partager une application (de bureautique notamment) exécutée localement sur un poste client. Le poste client qui exécute l'application est appelé client hôte. L'application partagée peut être non seulement visualisée, par d'autres clients, mais également contrôlée par d'autres clients, pour ainsi réaliser un environnement collaboratif sur la base d'une application exécutée localement. On notera également que l'invention permet à plusieurs applications d'être partagées simultanément. L'application partagée devient un objet de l'environnement partagé sur tous les clients n'exécutant pas eux mêmes l'application. Toutefois le client hôte interagit directement avec celle-ci et aucun objet n'est créé dans la copie du monde virtuel de ce client (le code de l'application, ou les fichiers ouverts, ne sont pas transférés). Le partage peut s'effectuer entre différents environnements matériels et logiciels, et pour des applications très diverses. 10.1) Capture de l'application Pour rendre visible aux autres utilisateurs l'environnement visuel de l'application, celle-ci est capturée de la façon suivante : - choix de la fenêtre de document à partager ; - détermination de toutes les fenêtre filles de l'application (notamment palettes d'outils, etc.) ; - création d'un masque de capture déterminé par les positions des fenêtres ci-dessus - Capture de toutes les fenêtres considérées avec le masque de 15 capture. Chaque image capturée est ensuite utilisée pour crée un flux visuel d'application à destination des autres postes clients. La mise à jour de la capture s'effectue à une cadence choisie notamment en fonction de la taille de la zone capturée et du débit de 20 communication disponible dans l'environnement client/serveur. 10.2) Diffusion du flux De manière à limiter le volume d'informations à diffuser vers chaque client partageant l'application, chaque image capturée est découpée en 25 blocs. Chaque bloc est comparé au bloc précédemment envoyé, avec les règles suivantes : - Si aucun bloc précédent n'a été envoyé ou si le bloc précédent était différent : le bloc est envoyé dans un format de qualité réduite. - Si le bloc précédent est identique mais de qualité réduite : le 30 bloc envoyé est envoyé sans perte. - Si le bloc précédent est identique est envoyé sans perte : le bloc n'est pas envoyé. L'historique des envois de blocs peut être effacé pour renvoyer l'ensemble des blocs de la capture, notamment lors de l'initialisation du poste client d'un participant lors de son arrivée. Au niveau des autres clients (clients « récepteurs »), ceux-ci reconstituent Les clients récepteur du flux reconstitue l'image bloc par bloc. Le flux transite par le serveur de partage d'applications qui effectue la distribution en fonction des utilisateurs inscrits au partage. 10.3) Contrôle de l'application Lorsqu'un participant contrôle une application partagée, ce sont les dispositifs d'entrée du client hôte qui commandent l'application, de la façon normale. Dans le cas où un autre client souhaite prendre le contrôle de l'application, une requête est envoyée par celui-ci au serveur de partage d'applications. Après éventuel processus d'habilitation et/ou d'autorisation, toutes les actions dudit autre client (souris, clavier, écran tactile, etc.), encodées dans des messages d'actions dédiés, sont envoyés au client hôte via le serveur de messagerie de l'environnement (utilisation du système de messagerie en couche 5). Avantageusement, toutes les actions d'entrée sont converties en un format générique, et reconverties dans le format de la machine hôte, soit au niveau des moyens serveurs, soit au niveau du client. Dans le présent exemple, c'est le client hôte qui reconvertit les actions au format d'entrés de sa machine, les positions étant recalculées par rapport aux fenêtres de l'application sur le client hôte. Puis les entrées sont simulées sur la machine hôte via les routines disponibles dans les systèmes d'exploitation du marché. De préférence, on prévoit qu'à tout moment le client hôte peut interrompre le partage de son application. On peut prévoir au niveau du client hôte soit un forçage de l'application active sur l'application en cours de partage (l'utilisateur du client hôte perdant la main, il est nécessaire de circonscrire les actions possibles de l'utilisateur tiers sur le client hôte), soit un filtrage des entrées simulées reçues, qui ne seront actives que lorsque c'est l'application partagée qui est active. Par ailleurs on prévoit avantageusement que dès que l'hôte utilise un de ses dispositifs d'entrée, il reprend automatiquement la main et les entrées externes sont neutralisées. 10.4) Implémentation Dans un exemple d'implémentation, le partage d'application s'effectue de la façon suivante : - Choix par l'utilisateur de l'application à partager, réalisé au niveau du client par un système de sélection des applications partageables en cours d'exécution ; - création d'un objet logique de par application partage et du flux visuel de l'application (texture) par le processus suivant : - verrouillage du gestionnaire d'objets (message ASK ACQUIRE) ; - ajout d'un objet application et d'un objet texture d'application 20 (messages ADD_ITEM) ; - déverrouillage du gestionnaire d'objets ; - envoi par le client hôte (celui qui héberge l'application) de la texture de l'application, avec une compression forte (par n messages de type TEXTURE_BLOCK) ; 25 - mise à jour périodique de la texture par le client hôte : - avec des messages de type TEXTURE_BLOCK avec contenu graphique de bonne qualité/faible compression pour un bloc graphique non modifié) ; - avec des messages TEXTURE_BLOCK avec contenu 30 graphique plus fortement compressé pour un bloc graphique modifié) ; - puis un client (le client hôte ou un autre client) choisit de prendre le contrôle de l'application par un message de type ASK ACQUIRE (objet logique d'application) ; - ce client agit sur l'application par ses dispositifs d'entrée : - s'il s'agit du client hôte, il agit localement sur son application et la texture continue de se mettre à jour ; - s'il s'agit d'un autre client, il envoie ses actions sur l'application par des messages de type APPLICATION_INPUT, par exemple : APPLICATION_INPUT, Déplacement (x,y) APPLICATION_INPUT, clic (x,y) APPLICATION_INPUT clavier (touche) etc. ; - le client hôte reçoit des messages APPLICATION_INPUT et les transmet à l'application. 11) Partage de fichiers La plateforme peut offrir un service de partage de fichiers entre les utilisateurs. Lorsqu'un utilisateur souhaite partager un fichier mémorisé localement dans son client (ou sur un support accessible par le client), une action sur son interface d'entrée (par exemple à l'aide d'un menu) convertit le fichier en un « fichier partagé » exploitable dans le monde virtuel. Ce fichier est transféré vers le serveur Le partage d'un fichier par un client entraine la création d'un objet « fichier partagé » dans le monde virtuel. Selon le type de fichier il est possible de créer une ressource graphique à partir du fichier en question (par exemple s'il s'agit d'une image), sinon l'objet sera représenté par une icône. L'objet fichier et sa ressource (icône ou image) sont d'abord synchronisés par le serveur logique, à l'aide de messages d'ajout d'objet et de texture dynamique, la ressource graphique (texture) étant transférée en priorité car elle est nécessaire à la représentation de l'objet. Le fichier 'est ensuite transféré via le serveur de transfert de fichiers à la demande d'un utilisateur sur l'objet fichier. Le serveur conserve un cache 5 des fichiers transférés pour pouvoir fournir à nouveau le même fichier à tout autre client qui en ferait la demande. 12) Création d'applications La plateforme permet à toute personne de créer très rapidement une 10 application reflétant un environnement réel (par exemple un environnement de jeu). 12.1) Contenu des packages Comme on l'a vu, un package est un répertoire sous forme d'archive 15 qui contient tout ce qui est nécessaire à l'exécution de l'application sur chaque poste client, et contient : - des ressources, à savoir l'ensemble des ressources multimédia statiques qui seront utilisées au niveau application (images, sons, textes, vidéos, etc.) 20 - un ou plusieurs fichiers de comportement en langage de script, par exemple réalisés sur la base d'un langage interprété tel que LUA (voir www. I ua. orq). 12.2) Interfaces de programmation d'applications API 25 Des interfaces de programmation d'applications (APIs pour « Application Programming Interfaces » en terminologie anglo-saxonne) sont fournies par la plateforme ; par exemple, on peut prévoir les APIs suivantes, qui peuvent être appelées par le langage de script : - création de ressource : cette API charge une ressource du 30 package en mémoire et retourne un identifiant ID de la ressource au script ; - création d'objets globaux (synchronisés) ou locaux (non synchronisés) ; ces objets sont créés soit dans l'environnement graphique partagé ou monde virtuel (objets globaux), soit dans l'interface propre à un utilisateur (objets locaux), - création de propriétés associées aux objets : ces propriétés sont soit des propriétés système, par exemple liées à l'affichage (affectation à un objet d'un ID de ressource), soit des propriétés propres à l'application ; - verrouillage/déverrouillage d'un objet : cette API permet de prendre ou de relâcher le contrôle sur un objet global ; si le poste contrôle un objet global, il peut alors modifier ses propriétés ; - manipulation des propriétés des objets (en lecture ou écriture) : si un objet est verrouillé par un poste client, le script peut alors écrire et modifier ces propriétés et le système se charge de synchroniser ces modifications sur les autres postes ; - récupération des états des entrées : il s'agit d'un groupe de fonctions permettant de récupérer les entrées de l'utilisateur sous deux grands groupes : * la position de la main virtuelle par interprétation de la position de la souris, des doigts de l'utilisateur sur une surface tactile, ou d'un autre périphérique de saisie X/Y, - la saisie de texte sur un clavier physique ou virtuel, selon le type de machine cliente. 12.3) Programmation des comportements Les fonctions de programmation des comportements doivent être présentes dans chaque script et elles sont appelées automatiquement par le système dans l'ordre suivant : 1) fonction TInitLocal() : cette fonction est appelée par le système un fois sur chaque poste client pour créer les objets locaux qui doivent être présent les postes respectifs ; 2) fonction TInitOwner() : cette fonction est appelée uniquement sur le poste du créateur d'une session pour qu'il crée les objets globaux ; 3) fonction TInitStarted() : cette fonction est appelée par le système un fois par poste lorsqu'un client rejoint une session active ; elle permet de créer les objets locaux liés à la présence de l'utilisateur (par exemple sa webcam, sa main virtuelle, etc.), chacun de ces objets étant crée en local sur chaque poste respectif. Ensuite durant le déroulement d'une session, les fonctions suivantes sont appelées par le système : - fonction TFrameUpdate() : elle est appelée cycliquement par le système, avec les modalités suivantes : - avant l'appel, le système récupère les états des entrées ainsi que les modifications des objets globaux par les autres postes clients (modifications qui sont synchronisées par le serveur via le réseau) ; - la fonction est appelée pour que le script puisse gérer les comportements en fonction des inputs et des objets globaux modifiés ; les comportements agissent soit sur les objets locaux, soit sur des objets globaux avec le mécanisme de verrouillage/déverrouillage de ces objets ; - suite a cette exécution de la fonction, le système procède a la synchronisation des modifications sur le réseau, et ensuite aux différents rendus sur le poste client (audio, vidéo, etc. - fonction OnUserChange() : cette fonction est appelée à chaque fois qu'un utilisateur rejoint ou quitte la session en cours, ou change ses paramètres tels que le surnom. Les valeurs modifiées sont délivrées par la 25 fonction elle-même. 12.4) Librairies fournies La plateforme peut également fournir un mécanisme de librairies de scripts qui ont notamment les deux objectifs suivants : 30 - factorisation du code par regroupement des comportements souvent utilisés ; - simplification du code par fourniture de librairies de codes complexes qui réalisent des fonctionnalités basiques et directement utilisables par un développeur qui souhaite avoir un développement rapide de son application. Ces librairies sont indépendantes de la plateforme et peuvent donc être développées par des tierces personnes. Bien entendu, la présente invention n'est nullement limitée au mode de réalisation décrit ci-dessus et représenté sur les figures, mais l'homme du métier saura y apporter de nombreuses variantes et modifications. REVENDICATIONS1. Système informatique, comprenant un ensemble de postes clients 5 reliés en réseau à des moyens serveurs, ledit système étant apte à exécuter de façon partagée sur les postes clients des applications mettant en jeu des objets et des ressources, caractérisé en ce qu'il comprend : - des moyens de synchronisation de comportements aptes à synchroniser en temps réel ou quasi-réel les comportements d'objets 10 restitués dans une application donnée au niveau des différents postes clients, - des moyens de gestion d'objets aptes à organiser la création, la modification et la suppression d'objets à l'initiative de postes clients, et - un système de messagerie de bas niveau commun apte à véhiculer 15 l'ensemble des informations entre les postes clients et les moyens serveurs, relatives à la synchronisation des comportements et à la gestion des objets. 2. Système selon la revendication 1, dans lequel les moyens de synchronisation sont aptes à mettre en oeuvre un mécanisme de 20 verrouillage/déverrouillage des objets. 3. Système selon la revendication 2, dans lequel les moyens de synchronisation comprennent un mécanisme d'arbitrage entre requêtes de verrouillage d'objets à partir de postes clients différents. 25 4. Système selon la revendication 3, dans lequel le mécanisme d'arbitrage comprend des moyens d'ordonnancement temporel des requêtes par rapport à une échelle de temps serveur propagée aux postes clients en prenant en compte le temps de propagation des messages du système de 30 messagerie des moyens serveurs vers les postes clients. 5. Système selon l'une des revendications 2 à 4, dans lequel l'un des objets consiste en un gestionnaire d'objets, et le mécanisme de verrouillage/déverrouillage des objets est apte à verrouiller le gestionnaire d'objet en vue de la création et de la modification d'objets. 6. Système selon l'une des revendications 1 à 5, dans lequel les moyens de synchronisation sont aptes à véhiculer des commandes d'entrée standard, et il est prévu au niveau des postes clients des moyens pour convertir lesdites commandes standard en commandes adaptées aux 10 systèmes d'exploitation des postes clients. 7. Système selon l'une des revendications 1 à 6, comprenant en outre des moyens de gestion de session aptes à gérer l'entrée de postes clients dans un partage d'application et la sortie desdits postes clients dudit partage 15 d'application, les informations mises en jeu par lesdits moyens de gestion de session étant également véhiculées par le serveur de messagerie de bas niveau. 8. Système selon les revendications 2 et 7 prises en combinaison, dans 20 lequel l'entrée d'un poste client dans un partage d'application est mise en oeuvre par transfert des objets non verrouillés vers ledit poste client, puis transfert des objets qui étaient verrouillés vers ledit poste client après leur déverrouillage. 25 9. Système selon l'une des revendications 1 à 8, comprenant en outre des moyens pour propager des moyens serveurs vers les postes clients des paquets applicatifs à partager, un paquet applicatif comprenant un fichier de description d'application, un ou plusieurs fichiers de description de comportements, de préférence en langage interprété, et des fichiers de 30 ressources. 10. Système selon l'une des revendications précédentes, comprenant en outre des moyens de partage d'applications exécutées localement sur un poste client donné, aptes à recopier une représentation graphique d'une application exécutée localement sur un poste client vers d'autres postes clients participant au partage, et des moyens pour contrôler les commandes d'entrée sur ladite application exécutée localement de façon à y appliquer sélectivement des commandes d'entrée générées sur ledit poste client et des commandes d'entrée générées par d'autres postes clients participant au partage et véhiculées via ledit système de messagerie de bas niveau.10