FR3003717A1 - COMPUTER ENVIRONMENT FOR SHARED EXECUTION ON CLIENT POSITIONS OF CONTENT APPLICATIONS AND SYNCHRONIZED ACTIONS - Google Patents

Abstract

The invention relates to a computing environment, comprising a set of client stations networked to server means, said environment being able to execute shared applications on the client computers using objects and resources, characterized in that it comprises: means for synchronizing behaviors capable of synchronizing in real time or near real-time the behaviors of objects restored in a given application at the level of the various client stations; means for managing objects capable of organizing the creation, modification and deletion of objects on the initiative of client computers, and - a common low-level messaging system capable of conveying all the information between the client computers and the server means, relating to the synchronization of behaviors and the management of objects. Application to shared environments (games, work ...) multi-platform.

Description

Field of the Invention The present invention generally relates to computing environments enabling a plurality of users to share spaces (collaborative work, game, etc.) in a virtual and synchronized manner. State of the art There are already known in the state of the art a number of initiatives and solutions for working collaboratively on a document, playing a network, etc. These solutions are, however, most often mono-platform and mono-environment. In addition, they typically require dedicated and specialized resources depending on the type of application targeted. Thus we know no environment that allows to share digital activities of various types, to support varieties of digital equipment and operating systems, and also to create new digital activities to share, while keeping layers of communication simple and easy to manage. SUMMARY OF THE INVENTION The present invention aims at overcoming all or part of the limitations of existing platforms. To this end, it proposes a computing environment, comprising a set of client stations networked to server means, said environment being able to execute shared applications on the client computers using objects and resources, characterized in that what it comprises: means for synchronizing behaviors capable of synchronizing in real time or near real-time the behaviors of objects returned in a given application at the level of the various client stations; means for managing apt objects to organize the creation, the modification and the deletion of objects on the initiative of client computers, and - a common low level messaging system able to convey all the information between the client computers and the server means, relating to behavior synchronization and object management. The invention also proposes preferentially but optionally the following additional characteristics, taken individually or in any combination technically compatible: * the synchronization means are able to implement a mechanism for locking / unlocking objects. the synchronization means comprise an arbitration mechanism between object locking requests from different client stations. the arbitration mechanism comprises means for temporally scheduling the requests with respect to a server time scale propagated to the client stations, taking into account the propagation time of the messaging system messages from the server means to the client stations. * One of the objects consists of an object manager, and the locking / unlocking mechanism of objects is able to lock the object manager for the creation and modification of objects. the synchronization means are capable of conveying standard input commands, and there is provided at the level of the client computers means for converting said standard commands into commands adapted to the operating systems of the client stations. the environment furthermore comprises session management means able to manage the entry of client stations into an application sharing and the output of said client stations from said application sharing, the information put into play by said management means session also being conveyed by the low level mail server. * The entry of a client station into an application share is implemented by transferring unlocked objects to said client station, and transfer objects that were locked to said client station after unlocking. the environment further comprises means for propagating server means to the client stations of the application packets to be shared, an application packet comprising an application description file, one or more behavior description files, preferably in interpreted language. , and resource files. the environment further comprises means for sharing applications executed locally on a given client station, able to copy a graphical representation of an application executed locally on a client station to other client stations participating in the sharing, and means for controlling the input commands on said application executed locally so as to selectively apply input commands generated on said client station and input commands generated by other client stations participating in the share and conveyed via said system low level email. BRIEF DESCRIPTION OF THE DRAWINGS Other aspects, objects and advantages of the present invention will become more apparent upon reading the following detailed description of a preferred embodiment thereof, given by way of non-limiting example and made by way of example. with reference to the accompanying drawings, in which: FIG. 1 is a diagram of the overall architecture of the sharing environment according to the invention, FIG. 2 illustrates the functionalities of a client station in connection with the environment, in an organized manner in layers of different logical levels, Figure 3 illustrates the functions of server means in connection with the environment, organized in layers of different logical levels, Figure 4 illustrates a process of synchronization of certain frame controls Messaging between clients and the server means according to the invention, Figures 5 and 6 are flowcharts illustrating the management of a lock request Figure 7 is a flowchart illustrating a process for inputting a client into a shared session, and Figure 8 illustrates a process of taking / releasing an object from a client. Release of lock for creation or modification of object by a client. DETAILED DESCRIPTION OF PREFERRED EMBODIMENT 1) Definitions Virtual Space: Logical space that can represent any real space around which several people (participants) gather through intelligent equipment or terminals (personal computer, tablet , personal digital assistant, smart TV, etc.). Virtual World: predefined virtual graphic space (for example a chess board with the board, the pieces, a clock and two participants, or a classroom with a board, "post-it" (registered trademark), a shared computer application, a teacher and several students, etc.). Platform: Set of tools (applications, client machines and servers, database, ..) acting in a communicating and synchronized way in a virtual space. Real-Time Synchronization: Real-time communication of all participant interactions in the virtual space. Common representation of the virtual space for all participants in real-time or near real-time (ie, near processing and network latencies). Client: Application on the equipment or terminal of a participant, allowing representation of the virtual space and actions in this space, either automatic (typically by scripts), or in response to participant commands at the device level input (keyboard, mouse, sensors, etc.). Server: Application hosted on a remote machine that allows the connection and communication of all clients to each other. It controls the 10 actions of customers when necessary and ensures their synchronization. Object: Virtual entity in the virtual space. Resource: Data allowing the representation of an object (Image, text, video stream, sound, etc.). 15 2) The platform The platform consists of client applications (multi-environments) and different types of servers. It makes it possible to simply implement applications in which different users can communicate in a virtual space 20 (webcam, voice, messaging, ...), interact with this virtual space, share digital files or share applications executed on their computer. working. Figure 1 of the drawings illustrates the overall architecture of the platform. It includes: - an SS session server: it manages the authentication and the rights of the different users and makes it possible to create and join communication sessions. This is the entry point of any client and it allows the regulation of other servers by starting sessions on the least loaded servers. It communicates with a database of users DB, local 30 or remote. a logical server SL: it is a real-time server that manages the synchronization of all the virtual objects. - a SPA application sharing server: it is a real-time server, which manages the visual flows of shared applications. - A stream server SF ("streaming" in English terminology): it is a real-time server that broadcasts video and audio streams. - an STF file transfer server: this server allows users to exchange files. One of the functions of the platform is to be able to quickly and easily broadcast applications of various types to different types of clients (computers, tablets, personal digital assistants, etc.) with different hardware characteristics. and different operating systems. 3) The client The configuration of a client station is shown in Figure 2. In a layered description, starting from the layer of the highest level and going to the lowest layer, we find: - Layer 1: layer "World", including all the elements of a "virtual world", namely mainly the users and the description of each world and its behavior (application). This layer is not part of the platform but uses it interfacing with it. The application is coded in the scripting language offered by the platform and is independent of the runtime environment (type of machine, operating system, etc.) - Layer 2: interaction layer. It includes rendering engines (visual, sound, etc.), depending on the rendering capabilities of the hardware platform. It also includes the interfaces with the input devices (and possibly output) available to the user (keyboard, mouse, trackpad, joystick, touch screen, etc.) for the hardware platform.

Layer 3: virtual world interpreter. This is the module that allows the interpretation of the application and offers the development system. Layer 4: logical layer. It consists of a number of logical modules for managing objects, applications and their sharing, and resources. Layer 5: Communication layer. It contains in particular a real-time messaging module, a streaming content distribution module, and a file transfer management module. These modules interact with the outside according to specific protocols adapted to the synchronization of a virtual space. - Layer 6: network layer. As a layer of the lowest level in the presented architecture, it implements the various communication protocols necessary for the transfer of data over the Internet. (Socket TCP, HTTP, FTP, etc.). 4) Servers Figure 3 illustrates the general architecture of a logical server used in the present invention. We find the same layers 4, 5 and 6 as those of the client. The biggest difference is that the logical layer (layer 4) of the server is in charge of synchronizing objects and resources. The communication layer only understands the mail module, the streams and file transfers being managed separately. Thus, the environment of the invention also comprises a number of other other servers, with again this three-layer architecture, and specific modules dedicated to the function or functions they implement (streaming, file transfer). , etc.). 5) Virtual Space 30 5.1) General Description Each client station, equipped with a display device, is able to display on it a view of a shared virtual space between a plurality of client stations. This virtual space is composed of different types of objects obeying different synchronization rules: - local objects: they are specific to a client and do not require any synchronization. As a rule, the server does not even know them. global objects: the participants can act on these objects (for example move them, change their state), these actions are synchronized between the different clients. - system objects: they each have their own synchronization rules. The various objects can be parent objects or children of other objects. 5.2) Local objects As indicated, no synchronization of these objects is necessary. They are initiated by the client, and no information regarding these objects is to be communicated to other clients. Only the client hosting such an object can interact with it. This may be for example interface menus, local resources of different types, and so on. 5.3) Global objects These objects can be modified by the different clients. Each state change of a global object must be synchronized between the different clients. The server is the master of these objects and knows their properties at a time t, and the clients have a copy of the object. Examples of global objects are: in networked gaming environments, a movable pawn on a game board, a map of a deck of cards, a die, and so on. ; - in a collaborative environment, a virtual "PostIt" element, etc. ; - an instant written messaging conversation, - a file of an office environment (text file, spreadsheet, presentation, etc. - all other objects that may have properties or states that the different participants, at the level of their client, 5.4) System objects The environment according to the invention includes different types of system objects. In particular, the following system objects are found: MAIN object: a "Main" system object (hand cursor) is provided at each client. Each user can thus control his Main object to act on the objects represented on his display device; the hand acts on objects, each client controls his hand and can not interact with other hands. The positions of the hands and their states are continuously synchronized. PARTICIPANT object: such an object gathers all the information relating to a participant. Some of this information may have to be synchronized, but defined by the system (pseudo, id, owner, etc.), while other information may be added and modified by the participants (name of a character, a team, etc.) - OBJECT CONTROLLER object: this object manages the creation and deletion of all other objects. This object is synchronized and therefore known to the server. It is duplicated to a customer who wants to take control.

RESOURCE CONTROLLER object: It manages the creation and deletion of resources. This object is synchronized and therefore known to the server. 5.5) Attributes of the objects An object notably includes the following different attributes: Scope (local, global or system): this attribute is unique and fixed. Type (die, button, card, pawn, etc.): unique and invariable. ID: identifier of the object in the environment, for example integer, unique and invariable. - Parent: identifier ID of the parent object, unique but variable. - Owner: identifier of the master participant of the object, unique and variable. - Graphic resource: ID of a visual resource, unique and variable. - Sound resource: ID of an audio resource, which can be multiple and variable. Deterministic value: An object can have any number of these properties, they are of simple type (integer, float, boolean, character string of maximum size defined) and can be modified by a client. (Example: X / Y coordinates, face of a map, last sentences of a conversation, etc.). - Random value: simple type but generated randomly; the client can not calculate / set this value (example: face of a die during a virtual die draw); it is the server that generates it. - Time value: a duration, date, etc. ; again, this property can not be set by the client and is set only by the server. - Local: Property that can be of any type, which is never synchronized with other clients. - At a time t, the client must be able to determine all that is necessary to represent the object locally from its properties. 5.6) Resources Resources can be created using the RESOURCE CONTROLLER object. It can be: a local file integrated into the application, present on all the clients; - an audio stream; a video stream; - a shared application flow (see below); - a local file on a client workstation, to share with other clients. The audio and video streams pass through the feed servers.

The shared application flow passes through the dedicated application sharing server. The files go through the file transfer server. 5.7) Packages The applications are defined in "packages" ("package" in English terminology), a package being an independent data directory containing all the resources necessary to run the platform on a client station. A package contains: - a description file of the application; one or more behavior description files, preferably in interpreted language; multimedia resource files (sounds, videos, images, in particular graphic images of movable objects and graphic image of a "table" or graphic environment of the platform - for example a chessboard, etc.).

The platform defines the formalism: - of the description file; - interfacing behaviors with the platform; - compatible formats for resources.

Launching an application involves three main functions that are defined in the package: - Tlnit () to initialize the data and objects present on the table; TFrameUpdate () for cyclically updating, or event-triggered, objects, according to programmed behaviors; - TShut () to destroy objects created and updated by Tin ") and TFramelUpdate () functions respectively. The interactions between the server means and the clients are materialized by frames, as will be described later. 6) Representation and Interaction 6.1) Advantageously, the platform can provide low-level application programming interfaces (APIs) whose sound and visual renderings are identical regardless of the operating system. 6.1.1) Visual rendering The graphic representation of a virtual world is based on the rendering of objects according to their properties and their resources. The platform has its own rendering engine, independent of the type of machine and operating system, executable based on an intermediate software adaptation layer, the whole being contained in the package. The chosen rendering engine is able to adapt to the screen resolutions of the different machines and integrates, for all sizes or screen definitions that do not allow the global readable display of the entire virtual world, functionalities of zoom and move (scroli) in the virtual world. Preferably, these features operate according to the following rules: - when the screen is too small to display the table, you can apply a zoom factor <1 to reduce the image and display the entire table on the screen. The platform calculates, according to the positions and dimensions of the objects and according to the dimensions of the screen, the zoom factor allowing a complete display; when the pitch of the pixels is too small for a user-friendly visual rendering, a zoom factor of> 1 can be applied to enlarge the image and to display the objects in a size that is satisfactory for the user. - When the displayed table is not shown in full, the user can scroll the part displayed on the screen in the desired direction and thus view any part of the table. 6.1.2) Other renditions The objects can be composed of different types of resources that will be rendered by different engines as allowed by the 20 hardware devices of the different machines (sounds, vibrations, etc.). Thus an application does not have to worry about what kind of hardware is present, the platform managing all renderings of an object according to the possibilities of the machine. 6.2) Interaction Each participant can interact with the shared environment by having his own virtual "hand" (a MAIN system object) to control any object. A keyboard (physical or virtual) can enter text including an instant messaging service between 30 users.

The platform converts the inputs (keyboard, mouse, touch screen, etc.) of the hardware of the client workstation into generic actions to control the objects. A first type of entry makes it possible to select an object to move it (type "click and drag" in English terminology). Actions of the respective objects can also be selected, with primary actions operable by simple gestures (double-click, etc.) and secondary actions operable by selection in a list appearing for example in a pop-up menu.

More specifically, the platform defines action codes corresponding respectively to these actions, and correspondences between the operating system drivers, which make it possible to recover the state of the entries of the machine, and these action codes. These correspondences allow: - to integrate any type of input device (keyboard, mouse, touch screen, webcam with motion recognition, glove equipped with sensors, etc.), - to have the same interaction capabilities regardless of the hardware and the operating system of the client station, subject to available hardware, - remotely transcribe an action of a user on a type of machine, for identical action on another type of machine (function usable in particular in the application sharing, described later). 7) Description and interpretation of the virtual world Layer 3 of each client offers programming interfaces in a defined scripting language to be able to write the different applications corresponding to different virtual spaces. It includes an interpreter of scripts (as well as other interpreters if necessary) and functionalities allowing to access objects of the virtual world (reading and writing of their properties in particular).

It is thus possible to simply create different virtual spaces using a script file and local resources needed, either pre-existing or to create for the needs (graphic files, etc.). 8) Messages 8.1.) General Each message is composed of: - an identifier of the message (for example 16-bit integer), - a sender identifier (for example 32-bit integer), - an information message size (eg 32-bit integer), and - message-specific information. Advantageously, the messages are the subject of a binary serialization to reduce their size. A message can contain objects. In this case, the message is completed by the following structure: - identifier of the object (integer on 16 bits), - identifier of the owner (integer on 32 bits), corresponding to an issuer identifier, - list of properties: Binary block containing the property information, intended to be interpreted by the different by the customers. This block is serialized in the following way: - number of properties (16 bits), - identifier of property No. 1 (16 bits), - property size No. 1 (16 bits), - value of property No. 1 (data block of the size indicated previously), - identifier of the property No. 2 (16 bits), - Size of property No. 2 (16 bits), - Value of the property No. 2 (block of data of the size indicated above), - and so on for the following properties. For messages containing objects, it is also advantageous to apply a binary serialization to reduce their size. 8.2) Message Types In this implementation, the protocol consists of the following messages: 8.2.1) ASK session messages CONNECT_SESSION Session and user information SESSION CONNECTED Connection accepted / denied 15 INFORMATION SESSION Session information (participant , duration, ..) UPDATE SESSION Modification on the session (pseudo of a user, configuration, etc.) 8.2.2) synchronization messages of ASK objects ACQUIRE List of object identifiers for lock request, marker of request time 25 RET ACQUIRE Accepted / Denied lock, Serialized Locked Objects ASK RELEASE Object Identifier to Release RET_RELEASE 30 Object Identifier Released, Serialized Object Released. ADD ITEM Serialized object to add ITEM_ADDED Serialized object added U PDATE ITEM Object properties to modify ITEM UPDATED Modified object properties REMOVE ITEM Object ID to delete ITEM_REMOVED Object ID deleted ASK_INIT_TABLE Request to initialize the world TABLE_ALL_OBJECT Serialization of the world (all objects and their properties) ACK TABLE_ALL_OBJECT Validates the end of the initialization of the world LOGICAL_FRAME Frame containing the frame identifier, the server time and a set of messages ACK LOGICAL_FRAME Frame acknowledgment 8.2.3) Messages SOUND_BUFFER Encoding information, sound content 8.2.4) Video messages VIDEO_BUFFER Encoding information, video content 8.2.5) File messages FILE BUFFER File identifier, offset, data block of the file at the specified offset ASK FILE_BUFFER File ID, offset 8.2.6) Dynamic texture messages TEXTURE BUFFER Texture ID, off set, encoding, texture data block at the specified offset ASK TEXTURE_BUFFER Texture identifier, offset 8.2.7) Messages for application sharing TEXTURE_BLOCK Texture identifier, block identifier, encoding, texture block APPLICATION INPUT Identifier of application, type input, value entered. 8.3) Sending messages A client and the server are permanently connected via a TCP socket and communicate by sending and receiving messages, this being handled by the respective messaging modules in layer 5 (see FIG. Figures 2 and 3). The server sends all these messages to each client by LOGICAL_FRAME frames chronologically numbered at a regular frequency. At each frame reception, a client responds to the server by acknowledging ACK LOGICAL_FRAME that the frame has been taken into account.

This system of frames makes it possible to: - synchronize the server time (only the LOGICAL_FRAME message contains the time of the server), for purposes notably explained in the following; - store unsent messages to a client (during the initialization phase or if a client does not respond to a frame) and send them back if necessary; - optimize the writes of the server; - know the load of the server: if the writing period exceeds that fixed, the server is identified as overloaded and the requests for sessions can be directed to another server. Stream messages (audio, video, etc.) are transmitted directly to clients via specific messages without being stored in the frames; these are messages that do not need to be returned. In addition, each stream message is redirected by the server only to the required client. For example: - SOUND BUFFER is sent only to different clients of the transmitter having an active sound feature (eg a flag stored in the server); 20 - TABLE_ALL_OBJECT is sent only to the user who requested it; - ADD ITEM is sent to all different users of the sender. 9) Synchronization rules 25 9.1) Coherence The server is in charge of determining and maintaining the global state of the virtual world perceived by the different participants at the level of their respective customers.

To guarantee the coherence of the data between the different clients, the environment of the present invention is based on a system of logical locks operating according to the following principles: a global object can only be modified by one participant at a time, for to be able to modify an object the object is locked (operation carried out by the server), the participant then becomes the owner of this object and he can then modify his properties. - when a change of ownership all the properties are synchronized.

Consistency at the input is obtained by updating the copy of an object when a lock is taken by a client, and consistency when releasing is ensured by updating all the copies of an object when releasing lock. 9.1) Arbitration for Locking an Object The server must be able to determine which client has locked an object first, when more than one lock request arrives. For this purpose, each frame contains a time indicator which allows each client to use the same reference time: the time t on a client is determined by: t = ts + dt where ts is the server reference time of the last frame and dt is the time elapsed since the client received it.

Clients send their messages to the server with the time indicator calculated as above. The latency of client / server communications is not taken into account in the calculation of time, so that all participants can act fairly regardless of the speed of their network connection.

An example of a synchronization case is illustrated in Figure 4 of the drawings, assuming a network game where it is necessary to determine which participant requested a lock first (message ASK_ACQUIRE) on an object Oi with its object MAIN. The server sends the frames T1, T2 at the respective times t1 and t2 (server time), with different propagation times to the clients 5 CLIENT1 and CLIENT2. The CLIENT1 client enters the object at tc1 = t2 + 6 (with client side t2 CLIENT1), which corresponds to the server time t2 + 7, while the client CLIENT2 enters the object at tc2 = t2 + 5 (t2 CLIENT2 side ), which corresponds here to server times t2 + 8. However, it is the client CLIENT2 which in this case 10 takes possession of the object (even if in real time it has seized the object second), because compared when he received the t2 frame at his post, he was the quickest to grasp the object. To achieve this functionality, the server waits for the end of a delay, the duration of which depends on the frequency of the frames, before processing the object input messages returned by the clients and performing the arbitrations, and performs the arbitration from the time indicator contained in the frame. The delay in question depends on the frequency of sending frames; preferentially, a message received after the frame Tn is processed when the frame Tn + 2 is sent. The minimum delay is thus one period, and if the frame period is greater than the maximum latency of all clients, the equity between the clients is guaranteed. 9.3) Locking and modifications 25 A copy of a global object can be modified locally (usually automatically by a script, for example to animate an object). Any local modification can take place only if the object does not have a lock, the script checking before its execution the locked or released status of the object. These local modifications are not properly synchronized. It is important, however, that these changes be the same for all clients. Any automatic modification must therefore be determined according to the synchronized time delivered by the server with the frames. Figure 5 illustrates the lock taking logic in more detail, first with the general check of an untreated lock take request (box 502), and if so, with the verification that this previous request untreated concerns or not the same object (box 503). Then, the process checks (box 504) if the object is not already locked.

Example - server time tn (frame reception time Tn): reception of a Tn frame by the clients. - tn + 10: lock request on objects a, b, c by a client Cx, - the request is inserted by the server in a list sorted temporally - server time tn + 1 (reception time frame Tn + 1): processing of requests for locks received at tn-1 (reception time of the Tn-1 frame) - tn + 9: request for a lock on an object c by a customer Cy - Insertion of the request in the list above, before that on a, b , c because tn + 9 <tn + 10 - tn + 3 (frame reception time Tn + 3): processing of latches received at tn: c refused (more recent request) - lock on a, b, c refused - tn + 4 (reception time frame Tn + 4): processing of locks received at tn + 2 - lock on c accepted. The release of a lock, or unlocking, of an object is shown in FIG. 6. If there is a previous unprocessed lock request on the same object (box 601), this request is canceled. (box 602). If not, the process checks if the object was already locked by the same user (box 603). If yes, the lock is released. Example - tn: lock request on object a by client Cx - tn + 2: lock on accepted - Tn + 3: release request on object a by client Cx - object released - tn: lock request on objects a, b per client Cy-tn + 1: request for release on object a - cancellation of lock request on object a (a cancellation corresponds to the case where a request for release of lock is issued while the lock has not yet was accepted) - tn + 2: lock on b accepted 9.4) Initialization 20 The initialization of the system will be described with reference to Figure 7. When a participant (user x) wishes to join a networked gaming environment or "table The client of this participant sends the server a request (box 701) to obtain the entire table, namely all the objects that compose it. If the participant participates for the first time in the game (test 702), all the objects of the table (message TABLE_ALL_OBJECT) are sent (box 703) to the client (box 704). Once all the objects are correctly loaded into the client, an ACK_TABLE_ALL_OBJECT message is returned by the client to the server to signal that the entire table has been initialized. The server then returns all the information potentially missed by the client (box 705) during this initialization phase (typically all latches released and stored by the server since the request of the entire table). On the other hand, in the case where the user user x has already initialized the table in the past (box 702), the object manager is listening for reconnection requests. When this is the case, a lock is placed by user user x on all objects (box 706). If the user (box 707) wishes to add an object, it is added (box 708). If not, the unlocking is done (box 709). At the detailed level of the message exchanges, we will give below an example where a user U1 has connected to a session and added an object, then U2 makes a first connection on this same session and, during this connection , the user U1 already connected modifies an object. This sequence illustrates in particular how the modification is passed on to the user U2 after initialization. S is the server. U1: ASK CONNECT_SESSION -> SS: SESSION CONNECTED-> U1 S: INFORMATION SESSION-> U1 S: RET_ACQUIRE (itemManager) -> U1 U1: ADDITEM (Item X) -> S U: ASK RELEASE (itemManager) -> SS: ITEM_ADDED (Item X) -> U1 S: RET_RELEASE (ItemManager) -> U1 U2: ASK CONNECT_SESSION -> SS: 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 sent to U2 when sent to U2 during U1: UPDATE _ITEM (Item X) -> SS: UPDATE ITEM (Item X) -> U1 U2: ACK_TABLE_ALL_OBJECT-> S U1: ASKRELEASE (Item X) -> SS: RET_ACQUIRE (Item X) -> U2 (uninitialized message) S: UPDATE ITEM (Item X) -> U2 (uninitialized message) S: RET_RELEASE (Item X) ) -> U1, U2 9.5) Creation of elements For the creation of an element (object or resource) at the level of a client, the latter must acquire the necessary controller. The same goes for deleting an item.

An example of an associated process is shown in Figure 8. IM designates the object manager (Item Manager in English terminology). Oi (x) denotes the identifier object i, having an attribute of value x. ASK ACQUIRE (...) designates the request to take a lock on the object controller (IM) or on an object (Oi (x)). ASK_RELEASE (...) denotes the release of such a lock. p designates the propagation of a modified object after release. p 'denotes a new propagation of the modified object after release.

In a first phase, client CLIENT1 takes a lock on the IM object controller (which is a system object) at the server level, for the purpose of adding a global object 01 (x) (command ADD_ITEM (O1 (x))) at the client CLIENT1, which is then sent to the server. The object controller is then released.

Subsequently, the client CLIENT1 takes a lock on the object 01 at the server (command ASK ACQUIRE (01)) to modify it. The modification is transferred to the server (note that it is possible either to copy the object in CLIENT1 to modify it locally and then send it back to the server, or to send directly to the server modification orders of the object 01, orders applied to the object 01 as stored in the server). The object 01 is then released (command ASK_RELEASE (01)). If during the change phase of 01, a client CLIENT2 sends an initialization request ASK INIT_TABLE to participate in the environment (ie access the world, the table, etc.), the reading of the object 01 being part of this environment by the customer CLIENT2 (a command that is designated by READ (01 (x))) can only be done on the version of 01 before modification. Towards the end of the reading of 01 by CLIENT2, the server propagates (p) the new value of 01 to the clients (including CLIENT2) when releasing the lock on 01 that was requested by CLIENT1 (relaxation occurring after CLIENTI has completed changing 01 (x) to 01 (y). Now CLIENT2 acknowledging the world (ACK_TABLE_ALL_OBJECT) only after the propagation p of the modified object 01 (y), the server then takes the initiative to propagate again (in p ') the modified object 01 (y).

Then, as soon as a client (here again CLIENTI) modifies the object 01 according to the same process, here to transform it from 01 (y) to 01 (z), the modified object, after reception by the server, is automatically propagated to the client stations concerned, namely those participating in the session including CLIENT2. 9.6) Error tolerance 9.6.1) Message not received by a client The mail server stores all the frames sent to the clients in memory, until the confirmation of the clients that the frames have been taken into account. When sending a frame, the messaging server also returns all frames since the last received confirmation. After a certain number of unanswered frames from a client (implementation of a counting routine), the information is passed from the mail server to the session server, so that the client in question be declared disconnected. It will then have to go through an initialization phase to access the environment. 9.6.2) Message not received by the server If a lock request is not received by the mail server, the client does not obtain the lock and can not act on the object or manager considered. If a lock release is not received by the mail server, then: - either the client is still waiting for release and reiterates its message; - the client has been disconnected (see above), in which case all locks taken by this client are released. 10) Sharing an application The platform offers the possibility of sharing an application (particularly of office automation) run locally on a client computer. The client node that runs the application is called the client client. The shared application can be not only viewed by other clients, but also controlled by other clients, to achieve a collaborative environment based on a locally executed application. It will also be noted that the invention allows several applications to be shared simultaneously. The shared application becomes an object in the shared environment on all clients that are not running the application themselves. However, the host client interacts directly with it and no object is created in the copy of the virtual world of this client (the code of the application, or open files, are not transferred). Sharing can occur between different hardware and software environments, and for a variety of applications. 10.1) Capture of the application To make visible to the other users the visual environment of the application, this one is captured in the following way: - choice of the window of document to be shared; - determination of all the application's child windows (especially tool palettes, etc.); - Creation of a capture mask determined by the positions of the windows above. Capture of all the windows considered with the capture mask. Each captured image is then used to create a visual application flow to other client computers. The updating of the capture is carried out at a rate chosen in particular according to the size of the captured area and the communication rate available in the client / server environment. 10.2) Broadcasting the Stream In order to limit the amount of information to be broadcast to each client sharing the application, each captured image is divided into 25 blocks. Each block is compared to the block previously sent, with the following rules: - If no previous block was sent or if the previous block was different: the block is sent in a reduced quality format. If the previous block is identical but of reduced quality: the sent block is sent without loss. - If the previous block is identical is sent without loss: the block is not sent. The history of block uploads can be cleared to return all the blocks of the capture, especially during the initialization of a client's client station when it arrives. At the level of the other clients ("receiver" clients), these reconstitute the clients receiving the flow reconstitutes the block image by block. The flow passes through the application-sharing server that performs the distribution based on the users registered in the share. 10.3) Application Control When a participant controls a shared application, it is the host client input devices that control the application, in the normal way.

In the case where another client wishes to take control of the application, a request is sent by the latter to the application sharing server. After any authorization and / or authorization process, all the actions of said other client (mouse, keyboard, touch screen, etc.), encoded in dedicated action messages, are sent to the host client via the mail server. the environment (use of the layer 5 messaging system). Advantageously, all the input actions are converted into a generic format and converted back to the format of the host machine, either at the server means level or at the client level. In this example, it is the host client that converts the actions to the input format of its machine, the positions being recalculated relative to the windows of the application on the client host. Then the inputs are simulated on the host machine via the routines available in the operating systems of the market. Preferably, it is expected that at any time the host client can interrupt the sharing of its application. It can be provided at the host client level or forcing the active application on the application being shared (the user of the host client losing the hand, it is necessary to circumscribe the possible actions of the third-party user on the host client), which is a filtering of the received simulated inputs, which will be active only when the shared application is active.

Furthermore, it is advantageously provided that as soon as the host uses one of its input devices, it automatically resumes the hand and the external inputs are neutralized. 10.4) Implementation In an implementation example, the application sharing is carried out as follows: - Choice by the user of the application to be shared, realized at the client level by a system for selecting the applications that can be shared in running; - Creation of a logical object by shared application and the visual flow of the application (texture) by the following process: - Locking the object manager (ASK ACQUIRE message); adding an application object and an application texture object 20 (ADD_ITEM messages); - unlock the object manager; - sending by the host client (the one that hosts the application) the texture of the application, with a strong compression (by n messages TEXTURE_BLOCK type); 25 - periodic updating of the texture by the host client: - with messages of TEXTURE_BLOCK type with graphic content of good quality / low compression for an unmodified graphic block); with TEXTURE_BLOCK messages with more compressed graphic content for a modified graphic block); - then a client (the host client or another client) chooses to take control of the application by an ASK message ACQUIRE (logical object of application); - this client acts on the application by its input devices: - if it is the host client, it acts locally on its application and the texture continues to update; - if it is another client, it sends its actions on the application by messages of the type APPLICATION_INPUT, for example: APPLICATION_INPUT, Displacement (x, y) APPLICATION_INPUT, clic (x, y) APPLICATION_INPUT keyboard ( key) etc. ; - The host client receives APPLICATION_INPUT messages and passes them to the application. 11) File Sharing The platform can offer a file sharing service between users.

When a user wants to share a file stored locally in his client (or on a support accessible by the client), an action on its input interface (for example using a menu) converts the file into a " shared file 'exploitable in the virtual world. This file is transferred to the server Sharing a file by a client causes the creation of a "shared file" object in the virtual world. Depending on the type of file it is possible to create a graphic resource from the file in question (for example if it is an image), otherwise the object will be represented by an icon. The file object and its resource (icon or image) are first synchronized by the logical server, using add object messages and dynamic texture, the graphic resource (texture) being transferred as a priority because it is necessary for the representation of the object. The file 'is then transferred via the file transfer server at the request of a user on the file object. The server keeps a cache of the transferred files to be able to supply the same file again to any other client who requests it. 12) Creation of applications The platform allows anyone to quickly create an application that reflects a real environment (for example a game environment). 12.1) Contents of the packages As we have seen, a package is an archive directory 15 that contains everything that is necessary to run the application on each client station, and contains: - resources, that is to say all the static multimedia resources that will be used at the application level (images, sounds, texts, videos, etc.) 20 - one or more behavior files in script language, for example made on the basis of a language interpreted as LUA (see www Ia orq). 12.2) API Application Programming Interfaces Application programming interfaces (APIs for Application Programming Interfaces) are provided by the platform; for example, the following APIs can be provided, which can be called by the scripting language: resource creation: this API loads a resource from the package in memory and returns an identifier ID of the resource to the script; - creation of global (synchronized) or local (non-synchronized) objects; these objects are created either in the shared graphical environment or virtual world (global objects), or in the interface specific to a user (local objects), - creation of properties associated with the objects: these properties are either system properties, by example related to the display (assignment to an object of a resource ID), or properties specific to the application; - locking / unlocking an object: this API allows you to take or release control on a global object; if the station controls a global object, it can then modify its properties; - manipulation of object properties (read or write): if an object is locked by a client machine, the script can then write and modify these properties and the system will synchronize these changes on the other computers; - recovery of the states of the entries: it is a group of functions allowing to recover the entries of the user under two big groups: * the position of the virtual hand by interpretation of the position of the mouse, the fingers of the user on a touchpad, or other X / Y input device, - text input on a physical or virtual keyboard, depending on the type of client device. 12.3) Programming behaviors The behavior programming functions must be present in each script and they are automatically called by the system in the following order: 1) function TInitLocal (): this function is called by the system once on each station client to create the local objects that must be present the respective positions; 2) function TInitOwner (): this function is called only on the station of the creator of a session to create the global objects; 3) TInitStarted () function: This function is called by the system once per station when a client joins an active session; it allows to create the local objects related to the presence of the user (for example his webcam, his virtual hand, etc.), each of these objects being created locally on each respective post. Then during the course of a session, the following functions are called by the system: - function TFrameUpdate (): it is called cyclically by the system, with the following modalities: - before the call, the system retrieves the states of the inputs as well as the modifications of the global objects by the other client stations (modifications which are synchronized by the server via the network); - the function is called so that the script can handle the behaviors according to the inputs and modified global objects; behaviors act either on local objects or on global objects with the locking / unlocking mechanism of these objects; - following this execution of the function, the system proceeds with the synchronization of the modifications on the network, and then with the various renderings on the client station (audio, video, etc. - OnUserChange () function: this function is called every time that a user joins or leaves the current session, or changes its parameters such as the nickname The modified values are delivered by the function itself 12.4) Supplied libraries The platform can also provide a mechanism for script libraries that In particular, they have the following two objectives: - factorization of the code by grouping the behaviors often used; - Simplification of the code by providing libraries of complex codes that achieve basic functionality and directly usable by a developer who wishes to have a rapid development of its application. These libraries are independent of the platform and can therefore be developed by third parties. Of course, the present invention is not limited to the embodiment described above and shown in the figures, but the skilled person will be able to make many variations and modifications.

Claims (10)

REVENDICATIONS1. Computer system, comprising a set of client stations 5 networked to server means, said system being able to execute shared applications on the client computers using objects and resources, characterized in that it comprises: means for synchronizing behaviors able to synchronize, in real time or near real time, the behaviors of objects restored in a given application at the level of the various client stations; means for managing objects capable of organizing the creation, the modification and deletion of objects on the initiative of client computers, and - a common low-level messaging system capable of conveying all the information between the client computers and the server means, relating to the synchronization of the behaviors and to the management of objects. 2. System according to claim 1, wherein the synchronization means are adapted to implement a mechanism for locking / unlocking objects. 3. System according to claim 2, wherein the synchronization means comprise an arbitration mechanism between object locking requests from different client stations. 25 4. The system of claim 3, wherein the arbitration mechanism comprises means for temporally scheduling the requests with respect to a server time scale propagated to the client stations by taking into account the propagation delay of the messages of the system of 30. messaging from server facilities to client computers. 5. System according to one of claims 2 to 4, wherein one of the objects consists of an object manager, and the locking / unlocking mechanism of the objects is able to lock the object manager for the purpose of creating and editing objects. 6. System according to one of claims 1 to 5, wherein the synchronization means are able to convey standard input commands, and there is provided at the client computers means for converting said standard commands into commands adapted to 10 operating systems of the workstations. 7. System according to one of claims 1 to 6, further comprising session management means able to manage the entry of client stations in an application sharing and the output of said client stations of said application share, the information put into play by said session management means being also conveyed by the low level mail server. 8. System according to claims 2 and 7 taken in combination, wherein the entry of a client station into an application share is implemented by transferring the unlocked objects to said client station and then transferring the objects which were locked to said client station after unlocking. 25 9. System according to one of claims 1 to 8, further comprising means for propagating server means to client stations application packets to share, an application package comprising an application description file, one or more files of description of behaviors, preferably in interpreted language, and resource files. 10. System according to one of the preceding claims, further comprising means for sharing applications run locally on a given client station, able to copy a graphical representation of an application executed locally on a client station to other positions clients participating in the sharing, and means for controlling the input commands on said locally executed application to selectively apply input commands generated on said client and input commands generated by other participating client stations sharing and conveyed via said low level messaging system.