FR3006137A1

FR3006137A1 - MECHANISM FOR MANAGING A COMMUNICATION SESSION

Info

Publication number: FR3006137A1
Application number: FR1357580A
Authority: FR
Inventors: Fabrice Baranski; Fabrice Fontaine
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2013-07-31
Filing date: 2013-07-31
Publication date: 2014-11-28

Abstract

L'invention concerne un procédé de gestion d'une session de communication (SS_WS) entre un terminal (1) apte à échanger des messages applicatifs (MSG_WS) avec au moins un serveur (3) via la session de communication (SS_WS). Le procédé est caractérisé en ce qu'il comporte les étapes de : - établissement (E1) de la session de communication (SS_WS) pour échanger des messages applicatifs entre le terminal (1) et le serveur (3) ; - initialisation (E2) d'une période de temps (T) ; - détection (E2) d'un message applicatif (MSG_WS) relatif à la session de communication (SS_WS) ; - fermeture (E3) de la session de communication (SS_WS) à l'issue de cette période de temps (T), si aucun message n'a été détecté.The invention relates to a method for managing a communication session (SS_WS) between a terminal (1) able to exchange application messages (MSG_WS) with at least one server (3) via the communication session (SS_WS). The method is characterized in that it comprises the steps of: - establishing (E1) the communication session (SS_WS) for exchanging application messages between the terminal (1) and the server (3); initialization (E2) of a period of time (T); detection (E2) of an application message (MSG_WS) relating to the communication session (SS_WS); - closing (E3) of the communication session (SS_WS) at the end of this period of time (T), if no message has been detected.

Description

Mécanisme de gestion d'une session de communication Domaine technique L'invention se rapporte au domaine général des réseaux de télécommunication et plus particulièrement aux communications entre un terminal client et un équipement serveur sur un réseau de télécommunications de type Internet. Etat de la technique De façon connue, dans un réseau de type Internet, une communication entre un terminal client et un équipement serveur s'effectue au moyen du protocole HTTP (de l'anglais HyperText Transfer Protoco,), un protocole de communication client-serveur développé en particulier pour le World Wide Web (Web). Les clients HTTP les plus connus sont les navigateurs Web offrant des applications conçues pour être accédées à distance ; le langage HyperText Markup Language, généralement abrégé HTML, est un format de données conçu pour représenter les pages Web de telles applications. Les premières versions du protocole HTML n'autorisaient pas de communication bidirectionnelle entre le client et le serveur. Le client devait se connecter au serveur via un mécanisme de requêtes et réponses, aussi appelé polling, en utilisant le protocole HTTP. Pour assurer des communications bidirectionnelles entre le client et le serveur, le protocole websocket a été introduit plus récemment. Le protocole WebSocket est un standard désignant à la fois un protocole réseau et une interface de programmation qui peut être utilisée par une application sur n'importe quel client et serveur Web. Le protocole a été normalisé par l'organisme IETF (Internet Engineering Task Force) dans sa spécification RFC 6455 (de référence IETF Request for Comments: 6455) et l'interface de programmation correspondante est en cours de normalisation par l'organisme W3C (de référence : The Web Sockets API ; W3C Working Drag. Le protocole Websocket améliore considérablement la communication entre le serveur et le client, mais impose au client de maintenir une session de communication, et donc la liaison internet active, afin de pouvoir communiquer à tout moment avec le serveur. Le maintien de cette liaison peut être inutilement coûteux. En effet, un terminal consomme de l'énergie lorsque sa liaison Internet est activée et que des données sont échangées. Il est possible, sur certains terminaux, notamment des appareils mobiles (par exemple des smartphones, tablettes informatique, etc.), de couper, ou déconnecter la liaison Internet, lorsqu'il n'est pas nécessaire de l'utiliser. La déconnexion de la liaison Internet permet de diminuer la consommation d'énergie du terminal mais interdit toute communication. Pour réduire la consommation d'énergie d'un terminal apte à communiquer via le protocole Websocket, il est également possible d'arrêter seulement les communications websocket, afin de ne plus recevoir ou émettre des données de ce type. Mais le terminal, dans ce cas, perd la session en cours et doit établir une nouvelle session s'il souhaite communiquer avec le serveur par la suite. L'invention offre une solution ne présentant pas les inconvénients de l'état de la technique.BACKGROUND OF THE INVENTION The invention relates to the general field of telecommunication networks and more particularly to communications between a client terminal and a server equipment on an Internet-type telecommunications network. State of the art In a known manner, in an Internet-type network, a communication between a client terminal and a server equipment is performed using the HTTP (HyperText Transfer Protocol), a client-to-client communication protocol. server developed especially for the World Wide Web (Web). The most popular HTTP clients are web browsers with applications designed to be accessed remotely; HyperText Markup Language, usually abbreviated to HTML, is a data format designed to represent the web pages of such applications. Early versions of the HTML protocol did not allow bidirectional communication between the client and the server. The client had to connect to the server via a request and response mechanism, also called polling, using the HTTP protocol. To provide bidirectional communication between the client and the server, the websocket protocol has been introduced more recently. The WebSocket protocol is a standard designating both a network protocol and a programming interface that can be used by an application on any client and web server. The protocol has been standardized by the Internet Engineering Task Force (IETF) in its specification RFC 6455 (reference IETF Request for Comments: 6455) and the corresponding programming interface is in the process of being standardized by the W3C organization (from reference: The Web Sockets API, W3C Working Drag The Websocket protocol greatly improves the communication between the server and the client, but requires the client to maintain a communication session, and therefore the active internet connection, in order to be able to communicate at any time The maintenance of this connection can be unnecessarily expensive because a terminal consumes power when its Internet connection is activated and data is exchanged.It is possible, on some terminals, including mobile devices ( for example smartphones, tablets, etc.), to cut or disconnect the Internet connection, when it is not necessary to use it. Disconnection of the Internet connection makes it possible to reduce the power consumption of the terminal but prohibits any communication. To reduce the power consumption of a terminal capable of communicating via the Websocket protocol, it is also possible to stop only the websocket communications, in order to no longer receive or transmit data of this type. But the terminal, in this case, loses the current session and must establish a new session if it wishes to communicate with the server thereafter. The invention offers a solution that does not have the drawbacks of the state of the art.

L'invention A cet effet, selon un aspect fonctionnel, l'invention a pour objet un procédé de gestion d'une session de communication entre un terminal apte à échanger des messages applicatifs avec au moins un serveur via la session de communication, ledit procédé étant caractérisé en ce qu'il comporte les étapes suivantes : Etablissement de la session de communication pour échanger des messages applicatifs entre le terminal et le serveur ; Initialisation d'une période de temps ; Détection d'un message applicatif relatif à la session de communication ; Fermeture de la session de communication à l'issue de cette période de temps, si aucun message n'a été détecté. Ainsi, l'invention permet une gestion intelligente de la consommation du terminal. Une période d'inactivité trop longue sur la session de communication établie entre le terminal et le serveur se solde par la fermeture de la session par le procédé de l'invention. La session étant refermée, le terminal consomme moins d'énergie, ce qui s'avère particulièrement avantageux dans le cas de terminaux mobiles (de type smartphone, tablette informatique, etc.) pour lesquels la diminution de consommation électrique est importante. Selon un mode de mise en oeuvre particulier, l'invention est en outre caractérisée en ce que l'étape d'établissement de la session de communication comporte une sous-étape de réception d'une indication de la méthode de réveil à utiliser. L'invention permet ainsi d'indiquer une méthode de réveil pour le terminal à l'initialisation de la session, ce qui est particulièrement avantageux si plusieurs méthodes de réveil existent et que l'utilisateur du terminal, ou le terminal lui-même, souhaitent en privilégier une par rapport aux autres. Par réveil, on entend ici une remise en état du terminal de manière à ce qu'il puisse de nouveau communiquer sur une session telle que définie précédemment lorsque la session sera rétablie.The invention For this purpose, according to a functional aspect, the subject of the invention is a method of managing a communication session between a terminal able to exchange application messages with at least one server via the communication session, said method characterized in that it comprises the following steps: Establishing the communication session for exchanging application messages between the terminal and the server; Initialization of a period of time; Detecting an application message relating to the communication session; Closing of the communication session at the end of this period of time, if no message has been detected. Thus, the invention allows intelligent management of the terminal consumption. A period of inactivity too long on the communication session established between the terminal and the server results in the closing of the session by the method of the invention. The session is closed, the terminal consumes less energy, which is particularly advantageous in the case of mobile terminals (smartphone, tablet computer, etc.) for which the reduction in power consumption is important. According to a particular mode of implementation, the invention is further characterized in that the step of establishing the communication session comprises a substep of receiving an indication of the wake up method to be used. The invention thus makes it possible to indicate a wake-up method for the terminal at the initialization of the session, which is particularly advantageous if several wake-up methods exist and the terminal user, or the terminal itself, wishes to favor one over others. By awakening means here a restoration of the terminal so that it can again communicate on a session as defined previously when the session will be re-established.

Selon un autre mode de mise en oeuvre particulier de l'invention, qui pourra être mis en oeuvre alternativement ou cumulativement avec le précédent, le procédé est caractérisé en ce que l'étape de fermeture est suivie : - d'une seconde étape de détection d'au moins un message applicatif relatif à la session de communication ; - d'une étape de demande de rétablissement de la session de communication si un message applicatif est détecté pendant la seconde étape de détection. Ainsi, l'invention permet de rétablir le canal de communication qui a été déconnecté dès qu'un message est reçu pour cette session de communication. Par rétablissement, on entend ici un nouvel établissement d'une nouvelle session entre le même terminal et le même serveur pour échanger le même type de messages (on pourrait aussi parler de reprise de la session). En détectant les messages relatifs à la session de communication entre le terminal et le serveur, le procédé de l'invention agit en quelque sorte comme un proxy, selon la terminologie anglo-saxonne. Le proxy se positionne en espion sur la session et demande son rétablissement entre le terminal et le serveur dès qu'il détecte un message destiné au terminal. Ainsi, les messages peuvent être de nouveau échangés entre le terminal et le serveur, comme si le canal de communication n'avait jamais été déconnecté, ou fermé, etc. Selon une variante de ce mode de réalisation, l'invention comporte en outre une étape de retransmission vers le terminal du message détecté sur la session de communication. Ainsi, l'invention permet de retransmettre un message qui a été préalablement émis vers le terminal alors que la session était refermée, afin qu'il ne soit pas perdu pour le terminal. La communication est donc transparente entre le serveur et le terminal. Notamment, Les applications websocket sont extrêmement consommatrices d'énergie pour un terminal disposant de peu d'autonomie, comme par exemple un smartphone ou une tablette. L'invention permet de le déconnecter dès qu'il n'y a plus d'activité sur le canal qui le relie à l'internet (Zigbee, Wifi, etc.) tout en assurant la reprise de la communication dès qu'elle sera de nouveau souhaitée. Selon une autre variante de ce mode de réalisation, qui pourra être mise en oeuvre alternativement ou cumulativement avec la précédente, l'invention est en outre caractérisée en ce que l'étape de rétablissement de la session de communication est suivie d'une étape de réception d'un message comportant l'indication d'une méthode de réveil à utiliser. L'invention permet ainsi de préciser la méthode de réveil à utiliser pour le terminal en cours de session, ce qui permet, lorsque plusieurs méthodes de réveil sont possibles, de réveiller le terminal avec la méthode de réveil la plus appropriée, en fonction du réseau, environnement, etc., dans lesquels il se trouve. Selon une autre variante de ce mode de réalisation, l'invention est en outre caractérisée en ce que l'étape de rétablissement de la session de communication est suivie : - d'une étape de réception d'une proposition de prise en charge des messages applicatifs par un autre module proxy; - d'une étape d'acceptation de la prise en charge des messages applicatifs. L'invention permet ainsi notamment de gérer la session de communication lorsque le terminal change de réseau, pour passer par exemple d'un réseau local à un réseau mobile et doit subséquemment être pris en charge par un autre module proxy agissant pour le compte d'un autre réseau (par exemple le réseau mobile). Selon un autre aspect fonctionnel, l'invention a pour objet procédé de basculement d'une première session à une seconde session de communication entre un terminal et un serveur, la première session de communication étant établie par le procédé de gestion d'une session de communication décrit ci-dessus, par l'exécution d'un premier module proxy, la seconde session de communication étant à établir par un second module proxy, ledit procédé étant caractérisé en ce qu'il comporte les étapes suivantes : - réception d'une requête pour modifier la première session de communication, ladite requête comportant au moins un identifiant du premier proxy et un identifiant de la première session ; - émission par le second proxy d'un message de proposition de prise en charge de la première session; - attribution d'un numéro de session à la seconde session ; - établissement de la seconde session par le second proxy. Ce procédé de basculement permet de garder les avantages du procédé de gestion d'une session de communication précitée tout en assurant que le terminal, par exemple mobile, peut changer de réseau sans perdre la session de communication, par exemple wensocket, qu'il a établie avec le serveur. Un second module proxy est prévu à cet effet pour prendre le relai du premier, par exemple sur un réseau différent, ou dans des conditions différentes de réveil, consommation, etc., du terminal.According to another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous one, the method is characterized in that the closing step is followed by: a second detection step at least one application message relating to the communication session; a step of requesting a restoration of the communication session if an application message is detected during the second detection step. Thus, the invention makes it possible to restore the communication channel which has been disconnected as soon as a message is received for this communication session. By recovery, we mean here a new establishment of a new session between the same terminal and the same server to exchange the same type of messages (we could also talk about resumption of the session). By detecting the messages relating to the communication session between the terminal and the server, the method of the invention acts in a way as a proxy, according to the English terminology. The proxy positions itself as a spy on the session and requests its recovery between the terminal and the server as soon as it detects a message intended for the terminal. Thus, the messages can be exchanged again between the terminal and the server, as if the communication channel had never been disconnected, or closed, etc. According to a variant of this embodiment, the invention further comprises a step of retransmission to the terminal of the detected message on the communication session. Thus, the invention retransmits a message that was previously sent to the terminal while the session was closed, so that it is not lost to the terminal. The communication is transparent between the server and the terminal. In particular, websocket applications are extremely energy-consuming for a terminal with little autonomy, such as a smartphone or tablet. The invention makes it possible to disconnect it as soon as there is no more activity on the channel that connects it to the Internet (Zigbee, Wifi, etc.) while ensuring the resumption of communication as soon as it is again desired. According to another variant of this embodiment, which may be implemented alternatively or cumulatively with the previous one, the invention is further characterized in that the step of restoring the communication session is followed by a step of receiving a message indicating an alarm method to be used. The invention thus makes it possible to specify the wakeup method to be used for the terminal during the session, which makes it possible, when several waking methods are possible, to wake up the terminal with the most appropriate waking method, depending on the network. , environment, etc., in which it is located. According to another variant of this embodiment, the invention is further characterized in that the step of restoring the communication session is followed by: a step of receiving a message support proposal; applications by another proxy module; a step of accepting the support of the application messages. The invention thus makes it possible, in particular, to manage the communication session when the terminal changes its network, for example to switch from a local area network to a mobile network, and must subsequently be supported by another proxy module acting on behalf of the network. another network (eg the mobile network). According to another functional aspect, the subject of the invention is a method of switching from a first session to a second communication session between a terminal and a server, the first communication session being established by the management method of a session. communication described above, by the execution of a first proxy module, the second communication session to be established by a second proxy module, said method being characterized in that it comprises the following steps: - reception of a a request to modify the first communication session, said request comprising at least one identifier of the first proxy and an identifier of the first session; - issuing by the second proxy a support proposal message for the first session; - assignment of a session number to the second session; - establishment of the second session by the second proxy. This failover method makes it possible to retain the advantages of the management method of a communication session mentioned above while ensuring that the terminal, for example mobile, can change its network without losing the communication session, for example wensocket, which it has established with the server. A second proxy module is provided for this purpose to take the relay of the first, for example on a different network, or in different conditions of awakening, consumption, etc., the terminal.

Selon un mode de mise en oeuvre particulier de l'invention, le procédé de basculement est en outre caractérisé en ce que les messages applicatifs du serveur sont reçus par le premier module proxy et retransmis au second module proxy. Ainsi, lorsque le terminal n'est pas accessible, l'invention permet de retransmettre les messages applicatifs en provenance du serveur depuis le premier module proxy vers un second module proxy apte à communiquer avec le terminal, notamment si celui-ci a changé de réseau et n'est plus accessible depuis le premier module proxy. Selon un autre aspect fonctionnel, l'invention a pour objet un procédé de communication d'un terminal apte à échanger des messages applicatifs avec au moins un serveur via une session de communication, ledit procédé étant caractérisé en ce qu'il comporte les étapes suivantes : - Envoi d'un message d'ouverture de session de communication ; - réception d'un identifiant de session pour la session de communication ; - fermeture de la session ; - réception d'une demande de rétablissement de la session ; - envoi d'un message de rétablissement de la session de communication comportant l'identifiant de la session. L'invention permet ainsi de suspendre une session de communication d'un terminal. Par exemple, les applications websocket sont extrêmement consommatrices d'énergie pour un terminal disposant de peu d'autonomie tels un smartphone ou une tablette. L'invention permet de le déconnecter de la session dès qu'il n'y a plus d'activité sur cette session (Zigbee, Wifi, etc.) tout en assurant la reprise de la communication dès qu'elle sera de nouveau souhaitée. Notamment, un terminal qui souhaite établir une session de communication de type websocket en consommant peu d'énergie peut faire une requête différente de celle d'un terminal qui souhaite l'établissement d'une session « standard ». La précision, lors de la phase de négociation de la demande, du souhait d'une session optimisée, via par exemple un paramètre spécifique, permet la fermeture ultérieure, suivie d'une réouverture, ou rétablissement, de la session websocket, de manière transparente pour le serveur et quasi-transparente pour le terminal puisqu'il lui suffit de rajouter un paramètre à la commande existante de la phase de négociation de websocket, puis de mémoriser le numéro de session qui sera utilisé ultérieurement pour la réouverture. Selon un aspect matériel, l'invention concerne également un dispositif de gestion d'une session de communication entre un terminal apte à échanger des messages applicatifs avec au moins un serveur via la session de communication, ledit dispositif étant caractérisé en ce qu'il comporte : un module d'établissement de la session de communication pour échanger des messages applicatifs entre le terminal et le serveur ; un module d'initialisation d'une période de temps ; un module de détection d'un message applicatif relatif à la session de communication ; un module de fermeture de la session de communication à l'issue de cette période de temps, si aucun message n'a été détecté. Selon un autre aspect matériel, l'invention concerne également un dispositif de basculement d'une première session à une seconde session de communication entre un terminal et un serveur, la première session de communication étant établie par le dispositif de gestion d'une session de communication décrit ci-dessus par un premier dispositif module proxy, la seconde session de communication étant à établir par un second dispositif module proxy, ledit second dispositif étant caractérisé en ce qu'il comporte les modules suivantes : un module de réception d'une requête pour modifier la première session de communication, ladite requête comportant au moins un identifiant du premier module proxy et un identifiant de la première session ; un module d'émission par le second proxy d'un message proposition de prise en charge de la session ; un module d'attribution d'un numéro de session à la seconde session ; un module d'établissement de la seconde session par le second proxy. Selon un autre aspect matériel, l'invention concerne également une passerelle domestique comportant un dispositif de gestion et/ou un dispositif de basculement de session tel que décrits ci-dessus. Selon encore un autre aspect matériel, l'invention concerne également un terminal apte à échanger des messages applicatifs avec au moins un serveur via une session de communication, ledit terminal comportant : - un module apte à émettre un message d'ouverture de session de communication ; - un module de réception d'un identifiant de session pour la session de communication; - un module de fermeture de la session ; - un module de réception d'une demande de rétablissement de la session - un module d'envoi d'un message de rétablissement de la session de communication comportant l'identifiant de la session. Selon un autre aspect matériel, l'invention concerne aussi un système comportant un terminal et une passerelle domestique tels que décrits ci-dessus. Selon un autre aspect matériel, l'invention concerne encore un programme d'ordinateur apte à être mis en oeuvre sur un dispositif tel que décrit ci-dessus, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes du procédé de gestion d'une session de communication défini au-dessus. Selon un autre aspect matériel, l'invention concerne encore un programme d'ordinateur apte à être mis en oeuvre sur un dispositif tel que décrit ci-dessus, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes du procédé de basculement de session définie au-dessus.According to a particular embodiment of the invention, the switching method is further characterized in that the application messages of the server are received by the first proxy module and retransmitted to the second proxy module. Thus, when the terminal is not accessible, the invention retransmits the application messages from the server from the first proxy module to a second proxy module able to communicate with the terminal, especially if the latter has changed network. and is no longer accessible from the first proxy module. According to another functional aspect, the subject of the invention is a method of communicating a terminal capable of exchanging application messages with at least one server via a communication session, said method being characterized in that it comprises the following steps : - Send a communication logon message; receiving a session identifier for the communication session; - closing of the session; - receipt of a request to reinstate the session; - sending a message of recovery of the communication session with the identifier of the session. The invention thus makes it possible to suspend a communication session of a terminal. For example, websocket applications are extremely energy-consuming for a device with little autonomy such as a smartphone or tablet. The invention makes it possible to disconnect it from the session as soon as there is no more activity on this session (Zigbee, Wifi, etc.) while ensuring the resumption of the communication as soon as it is again desired. In particular, a terminal that wishes to establish a websocket type of communication session using little energy can make a different request to that of a terminal that wants the establishment of a "standard" session. The precision, during the negotiation phase of the request, of the desire for an optimized session, via for example a specific parameter, allows the subsequent closing, followed by reopening, or reestablishment, of the websocket session, in a transparent manner for the server and almost transparent for the terminal since it suffices to add a parameter to the existing command of the websocket negotiation phase, then to memorize the session number that will be used later for the reopening. According to a hardware aspect, the invention also relates to a device for managing a communication session between a terminal able to exchange application messages with at least one server via the communication session, said device being characterized in that it comprises a module for establishing the communication session for exchanging application messages between the terminal and the server; an initialization module of a period of time; a module for detecting an application message relating to the communication session; a closing module of the communication session at the end of this period of time, if no message has been detected. According to another hardware aspect, the invention also relates to a device for switching from a first session to a second communication session between a terminal and a server, the first communication session being established by the management device of a session. communication described above by a first proxy module device, the second communication session being established by a second proxy module device, said second device being characterized in that it comprises the following modules: a module for receiving a request for modifying the first communication session, said request comprising at least one identifier of the first proxy module and an identifier of the first session; a transmission module by the second proxy of a message providing support for the session; a module for assigning a session number to the second session; a module for establishing the second session by the second proxy. According to another hardware aspect, the invention also relates to a home gateway comprising a management device and / or a session switching device as described above. According to yet another material aspect, the invention also relates to a terminal capable of exchanging application messages with at least one server via a communication session, said terminal comprising: a module capable of transmitting a communication logon message ; a module for receiving a session identifier for the communication session; - a closing module of the session; a module for receiving a request to restore the session; a module for sending a message for restoring the communication session including the identifier of the session. According to another material aspect, the invention also relates to a system comprising a terminal and a home gateway as described above. According to another material aspect, the invention also relates to a computer program capable of being implemented on a device as described above, the program comprising code instructions which, when the program is executed by a processor, performs the steps of the management method of a communication session defined above. According to another material aspect, the invention also relates to a computer program capable of being implemented on a device as described above, the program comprising code instructions which, when the program is executed by a processor, perform the steps of the session failover method defined above.

Ces programmes peuvent être mis en oeuvre dans le dispositif inséré dans un équipement quelconque du réseau local, en particulier dans la passerelle résidentielle définie ci-dessus. Selon encore un autre aspect matériel, l'invention a trait à un support d'enregistrement lisible par un processeur de données sur lequel est enregistré un programme comprenant des instructions de code de programme pour l'exécution des étapes de l'un quelconque des procédés définis ci-dessus. L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés.These programs can be implemented in the device inserted in any equipment of the local network, in particular in the residential gateway defined above. According to still another material aspect, the invention relates to a recording medium readable by a data processor on which is recorded a program comprising program code instructions for executing the steps of any one of the methods. defined above. The invention will be better understood on reading the description which follows, given by way of example and with reference to the accompanying drawings.

Les figures: La figure 1 représente le contexte général d'une mise en oeuvre de l'invention. La figure 2 représente une architecture d'une passerelle domestique implémentant un mode de réalisation de l'invention.The figures: FIG. 1 represents the general context of an implementation of the invention. FIG. 2 represents an architecture of a home gateway implementing an embodiment of the invention.

La figure 3 représente un chronogramme des échanges entre les différents équipements lors d'une mise en oeuvre de l'invention.FIG. 3 represents a timing diagram of the exchanges between the different pieces of equipment during an implementation of the invention.

La figure 4 représente le contexte général d'une variante de mise en oeuvre de l'invention La figure 5 représente un chronogramme des échanges entre les différents équipements du réseau selon une variante de mise en oeuvre de l'invention.FIG. 4 represents the general context of an implementation variant of the invention. FIG. 5 represents a chronogram of the exchanges between the different network equipments according to an alternative embodiment of the invention.

La figure 6 représente un chronogramme des échanges entre les différents équipements du réseau local selon une autre variante de mise en oeuvre de l'invention. La figure 7 représente un chronogramme des échanges entre les différents équipements du réseau local selon une autre variante de mise en oeuvre de l'invention.FIG. 6 represents a timing diagram of the exchanges between the different pieces of equipment of the local network according to another alternative embodiment of the invention. FIG. 7 represents a timing diagram of the exchanges between the different pieces of equipment of the local network according to another alternative embodiment of the invention.

Description détaillée d'un exemple de réalisation illustrant l'invention La figure 1 représente le contexte général d'une mise en oeuvre de l'invention. Un serveur d'applications (3) est connecté au réseau Internet (5). La communication entre le serveur (3) et un terminal client (1) s'effectue via le réseau Internet au moyen du protocole HTTP. Des pages Web sont par exemple présentées au terminal client au format HTML, format de données conçu pour représenter de telles pages. Le terminal client (1) dispose d'un client Web ; une page applicative est typiquement présentée sur le terminal (1) au moyen d'un navigateur Web. Le serveur (3) offre des applications de type Web nécessitant un transfert de données entre le serveur et un terminal en mode bidirectionnel, par exemple une application de consultation météorologique, ou de messagerie instantanée, dont les pages sont destinées à être présentées sur le terminal au moyen d'un tel navigateur. Le serveur envoie régulièrement des données vers le terminal, par exemple des notifications lors de l'arrivée de nouveaux messages. Le terminal client (1) est dans cet exemple un téléphone mobile auquel sont associées des fonctions informatiques et de navigation Internet, en anglais smartphone, apte à communiquer avec le serveur, mais pourrait être également un ordinateur portable, une tablette informatique, etc. Dans la suite, on entend par terminal client, ou plus simplement terminal, tout dispositif apte à se connecter à un serveur Web (3) via un canal de communication et à communiquer avec ce serveur en mode duplex, aussi appelé bidirectionnel, c'est-à-dire qui autorise l'échange de messages applicatifs dans les deux sens. Comme introduit préalablement, le protocole websocketdéfinit un mécanisme de communication bidirectionnelle entre un client et un serveur sur le Web. Dans le mode de réalisation choisi, les messages sont de type websocket et sont échangés au cours d'une session de communication websocket, plus simplement appelée session websocketet abrégée en SS_WS sur la figure 1 et la figure 3.DETAILED DESCRIPTION OF AN EMBODIMENT EXCHANGING THE INVENTION FIG. 1 represents the general context of an implementation of the invention. An application server (3) is connected to the Internet (5). Communication between the server (3) and a client terminal (1) is via the Internet using the HTTP protocol. For example, web pages are presented to the client terminal in HTML format, a data format designed to represent such pages. The client terminal (1) has a web client; an application page is typically presented on the terminal (1) by means of a web browser. The server (3) offers Web-type applications requiring a data transfer between the server and a terminal in bidirectional mode, for example a weather consultation application, or instant messaging, whose pages are intended to be presented on the terminal by means of such a browser. The server regularly sends data to the terminal, for example notifications when new messages arrive. The client terminal (1) is in this example a mobile phone with associated computer functions and Internet browsing, in English smartphone, able to communicate with the server, but could also be a laptop, a computer tablet, etc. In the following, the term client terminal, or more simply terminal, any device able to connect to a Web server (3) via a communication channel and to communicate with this server in duplex mode, also called bidirectional is that allows the exchange of application messages in both directions. As previously introduced, the websocket protocol defines a bidirectional communication mechanism between a client and a server on the Web. In the embodiment chosen, the messages are of the websocket type and are exchanged during a websocket communication session, more simply called a websocketet session abbreviated as SS_WS in FIG. 1 and FIG.

Le terminal client (1) se trouve dans un réseau (6), par exemple un réseau mobile. Plus largement, le réseau (6) pourrait être de n'importe quel type (cellulaire, GSM - Global System for Mobile Communications, UMTS - Universal Mobile Telecommunications System, Wifi - Wireless, etc) sans sortir du cadre de l'invention, du moment que le terminal (1) est apte à communiquer avec le serveur (3) via un protocole bidirectionnel, notamment websocket. Selon un autre exemple de réalisation, le terminal (1) pourrait également être connecté directement au réseau Internet (5) en mode filaire. Un serveur (4) est également connecté à l'Internet. Ce serveur émet des données vers les terminaux (1) du réseau mobile (6) ; ce serveur, parfois appelé serveur de notifications, est par exemple un serveur de notifications de messages de type Zigbee, ou encore de type SMSC (sigle pour Short Message Service Center), c'est-à-dire qu'il permet dans ce dernier cas de gérer le transfert de messages SMS (en mode texte ou binaire) vers les téléphones mobiles, via un lien (9) établi entre le serveur et le réseau mobile. Ce serveur stocke le message puis le transmet au destinataire lorsque celui-ci est présent sur le réseau (mobile allumé). Dans cet exemple de réalisation, c'est notamment le serveur (4) qui est capable de mettre le terminal (1) en veille afin de désactiver certaines de ses fonctions pour consommer moins d'énergie. L'invention permet une gestion économique de la session websocket établie entre le client et le serveur par l'introduction d'un équipement, ou module (2), que l'on appelle « Proxy Web » (en abrégé, PW) et qui va pouvoir se substituer au terminal (1) lorsque la session websocket est désactivée et que le terminal devient de ce fait incapable de répondre aux messages websocket en provenance du serveur (3). Le module Proxy propose en quelque sorte un canal de communication alternatif (représenté en pointillés sur la figure) à même d'intercepter les messages de la session websocket SS_WS et donc, dans ce contexte, de se substituer au terminal.The client terminal (1) is in a network (6), for example a mobile network. More broadly, the network (6) could be of any type (cellular, GSM - Global System for Mobile Communications, UMTS - Universal Mobile Telecommunications System, Wifi - Wireless, etc.) without departing from the scope of the invention, the as the terminal (1) is able to communicate with the server (3) via a bidirectional protocol, including websocket. According to another embodiment, the terminal (1) could also be directly connected to the Internet network (5) in wired mode. A server (4) is also connected to the Internet. This server transmits data to the terminals (1) of the mobile network (6); this server, sometimes called a notification server, is for example a message notification server of Zigbee type, or SMSC type (acronym for Short Message Service Center), that is to say that it allows in the latter case of managing the transfer of SMS messages (in text or binary mode) to the mobile phones via a link (9) established between the server and the mobile network. This server stores the message and then transmits it to the recipient when the latter is present on the network (mobile on). In this embodiment, it is in particular the server (4) which is able to put the terminal (1) in standby to disable some of its functions to consume less energy. The invention allows an economic management of the websocket session established between the client and the server by the introduction of a device, or module (2), which is called "Proxy Web" (abbreviated PW) and which will be able to replace the terminal (1) when the websocket session is disabled and the terminal thus becomes unable to respond to websocket messages from the server (3). The Proxy module offers somehow an alternative communication channel (shown in dashed lines in the figure) capable of intercepting the messages of the websocket session SS_WS and therefore, in this context, to replace the terminal.

On va maintenant décrire l'invention plus en détails à l'appui des figures 2 et 3. La figure 2 représente l'architecture d'un équipement qui implémente un mode de réalisation de l'invention. Le module proxy (2) peut être situé sur n'importe quel équipement connecté à l'Internet, par exemple selon ce mode de réalisation dans une passerelle domestique (10), un équipement qui permet d'assurer la redirection, ou routage, des paquets de données entre les différents terminaux et réseaux qui lui sont connectés. La passerelle (10) comprend, classiquement, des mémoires (M) associées à un processeur (CPU). Les mémoires peuvent être de type ROM (de l'anglais Read Only Memory) ou RAM (de l'anglais Random Access Memory) ou encore Flash. Une partie de la mémoire M contient notamment, selon l'invention, la partie logicielle du dispositif de l'invention qui est mise en oeuvre au moyens de modules logiciels et/ou matériels. Le terme module utilisé dans la présente description peut donc correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous- programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en oeuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.). La passerelle 10 comporte encore un certain nombre de modules qui lui permettent de communiquer avec l'extérieur via différents protocoles sur différents liens physiques ; sur la figure 2, on a ainsi schématisé un module Ethernet permettant des communications filaires avec le réseau internet, un module Wifi et un module Zigbee pour les communications sans fils.The invention will now be described in more detail with reference to FIGS. 2 and 3. FIG. 2 shows the architecture of a device that implements an embodiment of the invention. The proxy module (2) can be located on any equipment connected to the Internet, for example according to this embodiment in a home gateway (10), a device that makes it possible to ensure the redirection, or routing, of data packets between the different terminals and networks connected to it. The gateway (10) conventionally comprises memories (M) associated with a processor (CPU). The memories can be type ROM (English Read Only Memory) or RAM (English Random Access Memory) or Flash. Part of the memory M contains in particular, according to the invention, the software part of the device of the invention which is implemented by means of software and / or hardware modules. The term module used in the present description can therefore correspond to a software component as well as a hardware component or a set of hardware and software components, a software component corresponding to one or more programs or subprograms of computer or more generally to any element of a program capable of implementing a function or a set of functions as described for the modules concerned. In the same way, a hardware component corresponds to any element of a hardware set (or hardware) able to implement a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc. .). The gateway 10 also includes a number of modules that allow it to communicate with the outside via different protocols on different physical links; in Figure 2, there is thus schematized an Ethernet module for wired communications with the Internet, a WiFi module and a Zigbee module for wireless communications.

La figure 3 représente les échanges entre le terminal client (1), le module proxy (2) selon l'invention, qui peut se trouver ou non sur la passerelle domestique, le serveur (3) et le serveur mobile (4). Les étapes El à E6 décrites ci-dessous s'exécutent dans cet exemple sur le module proxy (2).FIG. 3 represents the exchanges between the client terminal (1), the proxy module (2) according to the invention, which may or may not be on the home gateway, the server (3) and the mobile server (4). The steps E1 to E6 described below run in this example on the proxy module (2).

L'invention peut s'appliquer à tout type de réseau terminal et aussi tout type de liaison entre le terminal et le réseau Internet : le lien physique (C1) entre le terminal 3 et le réseau Internet peut être de type filaire (Ethernet) ou sans fils (Wifi, 3G, 4G, Zigbee). Le réseau hébergeant le terminal peut être un réseau local ou un réseau mobile, ou encore un support radio pour une communication selon le protocole Zigbee (une technologie sans fils radio de basse puissance qui permet d'échanger sur un canal radio des messages conformes au protocole ZigBee basé sur la norme IEEE 802.15.4). Dans le contexte de ce mode de réalisation, il est supposé que le protocole applicatif utilisé pour la communication entre le serveur et le terminal est de type websocket. Néanmoins, l'invention n'est pas restreinte aux websocket et pourrait s'appliquer au contexte de toute autre session de communication bidirectionnelle entre un serveur et un client. Pour établir une session, ou connexion, websocket, une négociation préalable par échange de messages HTTP est classiquement réalisée entre le client (1) et le serveur (3). Cette négociation, aussi appelée HandShake selon la terminologie anglo-saxonne, (HS en abrégé), permet l'établissement d'une session de communication (SS_WS) pour l'échange de messages applicatifs conformément au protocole websocket, entre un client et un serveur du réseau. Les données peuvent subséquemment être envoyées et reçues par les deux points de terminaison que sont dans cet exemple de réalisation le smartphone (1) et le serveur (3) à l'aide du protocole websocket jusqu'à ce que la connexion, ou session, websocket soit fermée. L'invention permet d'établir une telle session de manière optimisée, c'est-à-dire en permettant au terminal mobile d'être déconnecté de la session établie tout en ayant la possibilité de la retrouver plus tard. Dans ce mode de réalisation de l'invention, comme représenté à la figure 3, le module proxy (2) reçoit les messages de cette phase initiale. Notamment, lors d'une étape E10, le terminal mobile (1) initie le handshake en ajoutant au message standard défini par la norme un paramètre supplémentaire qui indique au module proxy une demande de session websocket optimisée (WSO pour WebSocket Optimisé). Alternativement, ce paramètre peut prendre la forme d'une commande, requête, etc, selon le mode d'implémentation retenu. Ainsi, seuls les terminaux qui ont besoin de désactiver la session, par exemple dans un but d'économie d'énergie (smartphones, etc.), peuvent demander ce mode optimisé, alors que les autres terminaux (ordinateurs, etc.) établissent une session standard.The invention can be applied to any type of terminal network and also any type of connection between the terminal and the Internet: the physical link (C1) between the terminal 3 and the Internet can be wired (Ethernet) or wireless (Wifi, 3G, 4G, Zigbee). The network hosting the terminal may be a local area network or a mobile network, or a radio bearer for communication according to the Zigbee protocol (a low-power wireless radio technology that makes it possible to exchange protocol-compliant messages over a radio channel. ZigBee based on the IEEE 802.15.4 standard). In the context of this embodiment, it is assumed that the application protocol used for the communication between the server and the terminal is of the websocket type. Nevertheless, the invention is not restricted to websocket and could apply to the context of any other bidirectional communication session between a server and a client. To establish a session, or connection, websocket, a prior negotiation by exchange of HTTP messages is conventionally performed between the client (1) and the server (3). This negotiation, also called HandShake according to the English terminology, (abbreviated HS), allows the establishment of a communication session (SS_WS) for the exchange of application messages in accordance with the websocket protocol, between a client and a server network. The data can subsequently be sent and received by the two endpoints that are in this embodiment smartphone (1) and server (3) using the websocket protocol until the connection, or session, websocket be closed. The invention makes it possible to establish such a session in an optimized manner, that is to say by allowing the mobile terminal to be disconnected from the established session while having the possibility of finding it later. In this embodiment of the invention, as shown in FIG. 3, the proxy module (2) receives the messages of this initial phase. In particular, during a step E10, the mobile terminal (1) initiates the handshake by adding to the standard message defined by the standard an additional parameter that indicates to the proxy module an optimized websocket session request (WSO for Optimized WebSocket). Alternatively, this parameter can take the form of a command, request, etc., depending on the implementation mode selected. Thus, only the terminals that need to disable the session, for example for the purpose of saving energy (smartphones, etc.), can request this optimized mode, while other terminals (computers, etc.) establish a standard session.

Par exemple, le champ Web-Socket-Extensions (conforme à la spécification RFC 6455 précitée) peut être utilisé pour transmettre cette information. Lors d'un échange de handshake, par exemple : 1. le client envoie une trame correspondant au message HS_WS(WSO) ou message HS_WS(WSO, NUM) de la figure 3 : GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ- Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 Puis, selon que le client dispose (HS_WS(WSO)) ou non (HS_WS(WSO, NUM)) du numéro de session reçue au préalable : Sec-WebSocket-Extensions: websocket-lowpower ou Sec-WebSocket-Extensions: websocket-lowpower ; sessionid=NUM On peut également, selon des variantes, ajouter un certain nombre de paramètres, comme par exemple une valeur de compteur de temps, correspondant au temps à respecter avant détection d'inactivité, comme il sera discuté par la suite. 2. Le serveur, quant à lui, signifie son accord au proxy (SS_OK) qui répond au client par le message (correspondant au message SS_OK(NUM) dans la figure 3) : HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+x0o= Sec-WebSocket-Extensions: websocket-lowpower ; sessionid =moor Le module proxy (2) reçoit ce message au cours d'une étape El de gestion de l'établissement de la session de communication. Puis, au cours de cette étape El, le module proxy retransmet le message de Handshake (HS_WS) au serveur Web auquel il était initialement destiné, reçoit la confirmation du serveur (SS_OK) si celui-ci autorise la session, c'est-à-dire si toutes les conditions sont réunies pour qu'il accepte une session websocket avec le terminal (1), et retransmet au terminal (1) l'acquittement de la connexion (SS_OK). Un numéro de session (NUM) est également transmis au terminal (1). Il s'agit d'un identifiant unique géré par le module proxy lui permettant de faire le lien entre terminal et serveur. A cet effet, le module proxy maintient par exemple une table comportant, pour chaque numéro de session, l'adresse du terminal et l'adresse correspondante du serveur. Lors d'une étape E2, le module proxy initialise une période de temps (T), par exemple cinq minutes. Selon une variante évoquée ci-dessus, ce paramètre pourrait être retransmis par Sec-WebSocket-Extensions, permettant au client de spécifier la durée d'attente avant détection d'inactivité. Si, à l'issue de cette période de temps, aucun message n'a été détecté en provenance du serveur sur la session websocket (SS_WS), la session de communication est déclarée inactive et le module proxy transmet, au cours d'une étape E3, une commande de fin de session websocket au terminal (message : END_SS_WS). Ce type de message est normalisé par exemple dans la RFC 6455. A partir de ce moment, la session websocket (SS_WS) est refermée. Le lien physique correspondant (radio, mobile, etc.) peut être ou non déconnecté, pour assurer une consommation énergétique mois élevée du terminal. Cette possibilité est offerte par la fermeture de session selon l'invention, mais reste en dehors de l'invention.For example, the Web-Socket-Extensions field (conforming to the above-mentioned RFC 6455 specification) can be used to transmit this information. During a handshake exchange, for example: 1. The client sends a frame corresponding to the HS_WS message (WSO) or HS_WS message (WSO, NUM) of Figure 3: GET / chat HTTP / 1.1 Host: server.example. com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ- Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 Then, depending on whether the client has (HS_WS ( WSO)) or not (HS_WS (WSO, NUM)) of the session number previously received: Sec-WebSocket-Extensions: websocket-lowpower or Sec-WebSocket-Extensions: websocket-lowpower; sessionid = NUM One can also, according to variants, add a certain number of parameters, such as for example a time counter value, corresponding to the time to be respected before detection of inactivity, as will be discussed later. 2. The server, meanwhile, means its agreement to the proxy (SS_OK) that responds to the client with the message (corresponding to the message SS_OK (NUM) in Figure 3): HTTP / 1.1 101 Switching Protocols Upgrade: Websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK + x0o = Sec-WebSocket-Extensions: websocket-lowpower; sessionid = moor The proxy module (2) receives this message during an El management step of the establishment of the communication session. Then, during this step El, the proxy module retransmits the Handshake message (HS_WS) to the web server for which it was originally intended, receives the server confirmation (SS_OK) if it authorizes the session, that is to say say if all the conditions are met for it to accept a websocket session with the terminal (1), and retransmits to the terminal (1) the acknowledgment of the connection (SS_OK). A session number (NUM) is also transmitted to the terminal (1). It is a unique identifier managed by the proxy module allowing it to link the terminal to the server. For this purpose, the proxy module maintains for example a table comprising, for each session number, the address of the terminal and the corresponding address of the server. During a step E2, the proxy module initializes a period of time (T), for example five minutes. According to a variant mentioned above, this parameter could be retransmitted by Sec-WebSocket-Extensions, allowing the client to specify the waiting time before detection of inactivity. If, at the end of this period of time, no message has been detected from the server on the websocket session (SS_WS), the communication session is declared inactive and the proxy module transmits, during a step E3, an end-of-session command websocket to the terminal (message: END_SS_WS). This type of message is standardized for example in RFC 6455. From this moment, the websocket session (SS_WS) is closed again. The corresponding physical link (radio, mobile, etc.) may or may not be disconnected, to ensure a high monthly energy consumption of the terminal. This possibility is offered by the logoff according to the invention, but remains outside the invention.

Lors d'une étape E4 suivant la fermeture, le module proxy prend en charge la session websocket (SS_WS), notamment par une écoute (LST) des messages applicatifs échangés sur cette session : tant qu'aucun message n'est détecté, le module proxy écoute (LST) et la session reste fermée. Lorsqu'un message d'information websocket (MSG_WS) en provenance du serveur est détecté, le module proxy nvoie vers le serveur mobile (4) un message pour lui demander le réveil de la session (SS_WS) et sort de l'étape E4. Le serveur mobile réveille la session, par exemple en utilisant un message SMS binaire (SMS : WK_UP) lui intimant de réactiver, ou rétablir, la session websocket, avec en paramètre le numéro de la session websocket(NUM) qui a été interrompue préalablement. Le but de cette étape est de transmettre au terminal une information de reconnexion websocket au terminal par un moyen (SMS, Zigbee, etc.) si possible peu consommateur d'énergie, afin de conserver le bénéfice de la période d'inactivité.During a step E4 following the closing, the proxy module supports the websocket session (SS_WS), in particular by listening (LST) the application messages exchanged on this session: as long as no message is detected, the module listening proxy (LST) and the session remains closed. When a websocket information message (MSG_WS) from the server is detected, the proxy module sends a message to the mobile server (4) asking for the session to wake up (SS_WS) and exits step E4. The mobile server wakes up the session, for example by using a binary SMS message (SMS: WK_UP) telling it to reactivate, or reestablish, the websocket session, with the number of the websocket session (NUM) which has been interrupted beforehand. The purpose of this step is to transmit to the terminal websocket reconnection information to the terminal by means (SMS, Zigbee, etc.) if possible low energy consumption, in order to keep the benefit of the period of inactivity.

Le message est reçu par le terminal lors d'une étape E13. Lors d'une étape E14 suivant le réveil de la session, une nouvelle phase de négociation, ou handshake, est initiée par le téléphone mobile. Cette phase est très similaire à celle de l'étape E10 : le terminal mobile (1) initie le handshake websocket en ajoutant au message standard défini par la norme un paramètre supplémentaire pour demander une session websocket Optimisée (WSO) et rappelle de plus, à la différence de l'étape E10, le numéro de session (NUM) dans son message (HS_WS (WSO, NUM)). Le module proxy (2) reçoit ce message au cours d'une étape E5 de gestion du rétablissement, ou établissement ultérieur, de la session de communication et transmet au terminal l'acquittement de la connexion (SS_OK) avec le numéro de session (NUM).The message is received by the terminal during a step E13. During a step E14 following the waking of the session, a new negotiation phase, or handshake, is initiated by the mobile phone. This phase is very similar to that of step E10: the mobile terminal (1) initiates the websocket handshake by adding to the standard message defined by the standard an additional parameter to request an optimized websocket session (WSO) and recalls more, to the difference of step E10, the session number (NUM) in its message (HS_WS (WSO, NUM)). The proxy module (2) receives this message during a recovery management step E5 or subsequent establishment of the communication session and transmits to the terminal the acknowledgment of the connection (SS_OK) with the session number (NUM ).

La session étant rétablie, il reste au module proxy à retransmettre le message websocketreçu préalablement du serveur (MSG_WS) vers le terminal, au cours d'une étape E6. Ainsi, vu du serveur, tout s'est passé comme si la session ne s'était pas interrompue. Il en va de même pour le terminal, à condition de demander le mode de session optimisé offert par l'invention. Pour le terminal, le procédé est particulièrement avantageux puisqu'il permet de fermer la session pendant les périodes d'inactivité, la fermeture de la session pouvant être suivie, selon des modes de mise en oeuvre particuliers, par des fermetures et/ou déconnexions du lien physique qui la porte (par exemple, déconnexion du canal radio ou du lien Ethernet Cl, désactivation des modules Ethernet, Wifi, Zigbee, du terminal, etc).The session being restored, it remains to the proxy module to retransmit the websocket message previously received from the server (MSG_WS) to the terminal, during a step E6. So, from the server, everything happened as if the session had not been interrupted. The same goes for the terminal, provided to request the optimized session mode offered by the invention. For the terminal, the method is particularly advantageous since it makes it possible to close the session during periods of inactivity, the closing of the session being able to be followed, according to particular modes of implementation, by closures and / or disconnections of the terminal. physical link that carries it (for example, disconnection of the radio channel or Ethernet link Cl, disabling Ethernet modules, Wifi, Zigbee, terminal, etc.).

Ce mode de mise en oeuvre ne permet cependant pas de résoudre la perte de connexion lors d'un changement de réseau, par exemple dans un contexte (smartphone) où le terminal (1) de la figure 1 se trouverait amené à communiquer sur deux réseaux distincts, par exemple le réseau local qui a pour passerelle domestique la passerelle (10) et le réseau mobile (6) (selon d'autres exemples, on peut envisager le passage d'un réseau Wifi à un réseau mobile 3G, d'un réseau Wifi local à un réseau Wifi communautaire, etc.) L'invention propose de remédier à ce problème par l'introduction d'un nouveau module proxy Websocket (20), comme représenté sur la figure 4, appelé dans la suite « module Proxy Websocket 2» ou de manière plus concise « second module proxy ». L'introduction de ce second module proxy permet une déconnexion du terminal (1) d'un premier réseau (ici, le réseau local derrière la passerelle domestique) et la reprise de la connexion lorsque nécessaire sur un second réseau, ici le réseau mobile (6). Le second module proxy propose en quelque sorte un second canal de communication alternatif (représenté en pointillés discontinus sur la figure) à même d'intercepter les messages de la session websocket SS_WS et donc, dans ce contexte, de se substituer au terminal en coopération avec le module proxy (2). Les deux modules proxy doivent être capables de dialoguer entre eux. Ainsi, comme il va être détaillé maintenant à l'appui des figures 5 à 7, il devient aisément possible de changer de type de réseau sans perdre la session et tout en limitant l'activité, et donc la consommation, du terminal.This embodiment does not however make it possible to solve the loss of connection during a network change, for example in a context (smartphone) where the terminal (1) of FIG. 1 would have had to communicate on two networks. separate networks, for example the local network which has the gateway (10) and the mobile network (6) as a home gateway (according to other examples, it is possible to envisage the transition from a Wi-Fi network to a 3G mobile network, a local Wifi network to a community Wifi network, etc.) The invention proposes to remedy this problem by introducing a new websocket proxy module (20), as shown in FIG. 4, hereafter called "Proxy module". Websocket 2 "or more concisely" second proxy module ". The introduction of this second proxy module allows a disconnection of the terminal (1) from a first network (here, the local network behind the home gateway) and the resumption of the connection when necessary on a second network, here the mobile network ( 6). The second proxy module proposes a second alternative communication channel (shown in broken dashed lines in the figure) capable of intercepting the messages of the websocket session SS_WS and therefore, in this context, to substitute for the terminal in cooperation with the proxy module (2). Both proxy modules must be able to talk to each other. Thus, as will now be detailed in support of FIGS. 5 to 7, it is easily possible to change the type of network without losing the session and while limiting the activity, and therefore the consumption, of the terminal.

La figure 5 représente un chronogramme des échanges entre les différents équipements du réseau local selon une variante de mise en oeuvre de l'invention. Selon cette variante, l'équipement terminal (1) (sma rtphone par exemple) est susceptible de changer de réseau (passage du réseau local de la passerelle (10) au réseau mobile (6). Dans ce contexte, l'invention propose de changer de module proxy websocket optimisé. Lors d'un premier ensemble d'étapes, noté de manière compacte SS_WS (WSO, N1) en référence à l'établissement d'une session optimisée ayant pour numéro N1 entre le terminal (1) de l'invention et le serveur (3), les étapes de la figure 3 préalablement décrites sont mises en oeuvre. Pour rappel : - le module proxy (2) reçoit les messages de la phase initiale de handshake (HS) grâce à l'ajout dans le message standard défini par la norme d'un paramètre (WSO) qui indique au module proxy une demande de session websocket optimisée, retransmet le message de Handshake (HS_WS) au serveur Web auquel il était initialement destiné, reçoit la confirmation du serveur (SS_OK) si celui-ci autorise la session, et retransmet au terminal (1) l'acquittement de la connexion (SS_OK) avec un numéro de session (N1) ; - le module proxy initialise une période de temps (T), ferme la session websocket (SS_WS), puis prend en charge les messages échangés sur la session websocket (SS_WS) : tant qu'aucun message n'est détecté, le module proxy écoute (LST) et la session reste fermée ; lorsqu'un message d'information websocket (MSG_WS) en provenance du serveur est détecté, le procédé envoie vers le serveur mobile (4) un message pour lui demander le réveil de la session ; - une nouvelle phase de négociation, ou handshake, est initiée par le terminal en rappelant le numéro de session (NUM) dans son message. - La session étant rétablie, il reste au module proxy à retransmettre les messages websocket reçus préalablement du serveur (MSG_WS) vers le terminal (1).FIG. 5 represents a timing diagram of the exchanges between the different pieces of equipment of the local network according to an alternative embodiment of the invention. According to this variant, the terminal equipment (1) (for example smartphone) is capable of changing networks (switching from the local network of the gateway (10) to the mobile network (6) .In this context, the invention proposes to to change optimized websocket proxy module During a first set of steps, compactly noted SS_WS (WSO, N1) with reference to the establishment of an optimized session having N1 number between the terminal (1) of the invention and the server (3), the steps of Figure 3 previously described are implemented.For reminder: - the proxy module (2) receives the messages of the initial phase of handshake (HS) through the addition in the standard message defined by the standard of a parameter (WSO) which indicates to the proxy module an optimized websocket session request, retransmits the message from Handshake (HS_WS) to the web server for which it was originally intended, receives the server confirmation (SS_OK ) if the latter authorizes the session, and nsets the terminal (1) the acknowledgment of the connection (SS_OK) with a session number (N1); - the proxy module initializes a period of time (T), closes the websocket session (SS_WS), then supports the messages exchanged on the websocket session (SS_WS): as long as no message is detected, the proxy module listens (LST) and the session remains closed; when a websocket information message (MSG_WS) from the server is detected, the method sends to the mobile server (4) a message to ask it to wake up the session; - A new negotiation phase, or handshake, is initiated by the terminal by recalling the session number (NUM) in its message. - The session is restored, it remains the proxy module to retransmit the websocket messages received from the server (MSG_WS) to the terminal (1).

On suppose donc ici que ces étapes ont abouti à une session de communication N1 optimisée entre le terminal et le serveur Websocket, symbolisée par la double flèche SS_WS(WSO, N1). Le terminal (1) qui souhaite changer de réseau peut désormais maintenir sa session tout en sollicitant un autre module proxy. Lors d'une étape E20, dans notre exemple, le terminal mobile transmet vers le second module proxy (20) un message de handshake qui comporte, comme précédemment, un paramètre WSO de demande de session optimisée, ansi que le numéro de la session (N1) et un identifiant du premier module proxy (@P1). Ce message (HS WS (WSO, Ni, @PV)est reçu par le second module proxy (P2) lors d'une étape E30. Dans ce contexte, le message de handshake peut par exemple prendre la forme suivante pour transmettre les informations du proxy précédent. Sec-WebSocket-Extensions:websocket-lowpower ; sessionid =mooc; oldproxy=@ip Lors de l'étape E31 qui la suit, selon cet exemple, le second module proxy (20) émet vers le premier (2) une demande de prise en charge (CH(P1, P2, N1)) de la session N1. Dans cet exemple le numéro de session est passé en paramètre de la commande (N1) car il peut y avoir plusieurs sessions websocketactives au même moment. Le premier module proxy (2) répond lors d'un message E40, par un message d'acquittement (ACK) s'il est d'accord. Sinon, à l'issue d'un période de temps donnée (time-out, la session n'est pas acceptée. Puis lors d'une étape E32, le second module proxy (20) retransmet au terminal (1) l'acquittement de la connexion (SS_OK). Un numéro de session (N2) est également transmis au terminal (1). Il s'agit d'un identifiant unique généré par le module proxy lui permettant de faire le lien entre terminal et serveur. On notera que ce numéro peut être identique au précédent (N1) ou différent. A partir de ce moment, la session websocket (SS_WS) est refermée. Lors d'une étape E'4 similaire à l'étape E4 de la figure 3, le module proxy prend en charge la session websocket (SS_WS), notamment par une écoute (LST) des messages applicatifs échangés sur cette session : tant qu'aucun message n'est détecté, le module proxy écoute (LST) et la session reste fermée. Lorsqu'un message d'information websocket (MSG_WS) en provenance du serveur est détecté, le premier module proxy (1) le retransmet vers le second module proxy qui demande le réveil de la session mobile au serveur mobile (4, non représenté), notamment si la méthode de réveil demandée requiert la présence d'un tel serveur mobile, qui procède au réveil du terminal, par exemple en utilisant un message SMS binaire. Le message applicatif (MSG_WS) est reçu par le terminal lors d'une étape E22. Il en ira de même pour les suivants, la session (notée 55 WS(WSO, N2)) étant désormais ouverte.It is therefore assumed here that these steps have resulted in an optimized N1 communication session between the terminal and the Websocket server, symbolized by the double arrow SS_WS (WSO, N1). The terminal (1) wishing to change the network can now maintain its session while requesting another proxy module. During a step E20, in our example, the mobile terminal transmits to the second proxy module (20) a handshake message which comprises, as before, an optimized session request parameter WSO, as well as the number of the session ( N1) and an identifier of the first proxy module (@ P1). This message (HS WS (WSO, Ni, @PV) is received by the second proxy module (P2) during a step E30.In this context, the handshake message may for example take the following form to transmit the information of the previous proxy: Sec-WebSocket-Extensions: websocket-lowpower; sessionid = mooc; oldproxy = @ ip In the following step E31, according to this example, the second proxy module (20) sends to the first (2) a request for support (CH (P1, P2, N1)) of the session N1 In this example the session number is passed as a parameter of the command (N1) because there can be several websocketactive sessions at the same time. the first proxy module (2) responds to an E40 message with an acknowledgment message (ACK) if it agrees, otherwise, at the end of a given time period (time-out, the session is not accepted Then in a step E32, the second proxy module (20) transmits to the terminal (1) the acknowledgment of the connection (SS_OK) A session number (N2) is also transmitted to the terminal (1). It is a unique identifier generated by the proxy module allowing it to link the terminal to the server. Note that this number may be identical to the previous one (N1) or different. From this moment, the websocket session (SS_WS) is closed again. During a step E'4 similar to step E4 of FIG. 3, the proxy module supports the websocket session (SS_WS), in particular by listening (LST) the application messages exchanged on this session: as long as no message is detected, the proxy module listens (LST) and the session remains closed. When a websocket information message (MSG_WS) from the server is detected, the first proxy module (1) retransmits it to the second proxy module that requests the mobile session to wake up from the mobile server (4, not shown), especially if the requested wakeup method requires the presence of such a mobile server, which proceeds to wake up the terminal, for example using a binary SMS message. The application message (MSG_WS) is received by the terminal during a step E22. The same will apply to the following ones, the session (noted 55 WS (WSO, N2)) being henceforth open.

Selon une ou plusieurs variantes, un dispositif quelconque peut être chargé de l'une ou de plusieurs étapes de cette variante de réalisation en lieu et place du module proxy (20): - réception du message de Handshake (E30) - émission vers le proxy (2) de la demande de prise en charge - Retransmission de l'acquittement de session (E32) - réception et retransmission d'un message (E33) La figure 6 illustre la mise en oeuvre d'une seconde variante du mode de réalisation. Dans cette variante, le serveur websocket (3) est capable d'accepter un nouveau type de message pour le changement de client proxy websocket.According to one or more variants, any device can be loaded with one or more steps of this embodiment in place of the proxy module (20): - reception of the message Handshake (E30) - transmission to the proxy (2) of the request for support - retransmission of the session acknowledgment (E32) - reception and retransmission of a message (E33) FIG. 6 illustrates the implementation of a second variant of the embodiment. In this variant, the websocket server (3) is able to accept a new type of message for the change of websocket proxy client.

Ceci permet de libérer complètement le premier module proxy (2). On suppose ici, comme précédemment à l'appui de la figure 5, que les premières étapes ont abouti à une session de communication N1 optimisée entre le terminal et le serveur Websocket, symbolisée par la double flèche SS_WS(WSO, N1). Lors d'une étape E20, identique à celle de la figure 5, le terminal mobile transmet vers 20 le second module proxy P2 un message de handshake(HS WS(WSO, Ni, @P1)), reçu lors d'une étape E30 par le second module proxy (20), par exemple celui du réseau mobile. Lors de l'étape E'31 qui suit, le second module proxy (20) émet vers le serveur (3) une demande de changement de session. Cette demande de changement est symbolisée par le message MV(P1,P2,N1) qui indique une demande de basculement d'un proxy P1 (par exemple le 25 premier module proxy (2)) vers un proxy P2 (par exemple le module proxy (20)) pour la session N1. On notera que ce message est un peu différent de celui de l'étape E31 précédente : il s'agit ici de déplacer la session depuis le premier module proxy vers le second, et non plus seulement de prendre le relai en retransmettant les messages applicatifs. Dans notre exemple, le serveur (3) répond lors d'une étape E50 par un message d'acquittement (ACK). 30 Puis lors d'une étape E32, le module proxy 2 retransmet au terminal (1) l'acquittement de la connexion (SS_OK) avec le numéro de la nouvelle session (N3). Lors d'une nouvelle étape E51, le serveur (3) informe via un nouveau message MV(P1, P2, N1) le premier module proxy que le second module proxy va gérer la prise en compte du changement de client (de P1 vers P2). Ce message, reçu par le premier module proxy lors d'une étape E41, peut être géré par exemple via l'utilisation d'un champ (« opcode ») spécifique d'un message de type websocket laissé libre pour de nouvelles applications. L'homme du métier pourra se référer à la RFC 6455 de l'IETF (« The WebSocket Protocol «, section 5, « data framing ») accessible par exemple à l'adresse http://tools.ietf.ora/html/rfc6455#pacie-27, incorporée par référence. Dans notre exemple, la prise en compte effective du changement se traduit par l'envoi d'un message d'acquittement du premier module proxy (2) vers le serveur d'une part au cours de l'étape E41 et du serveur (3) vers le second module proxy (20) d'autre part (ACK) au cours d'une étape E52. A partir de ce moment, la session websocket (SS_WS) est refermée. Lors d'une étape E"4 similaire à l'étape E4 de la figure 3 et à l'étape E'4 de la figure 5, le second module proxy (20) prend en charge la session websocket (SS_WS), notamment par une écoute (LST) des messages applicatifs échangés sur cette session : tant qu'aucun message n'est détecté, le module proxy écoute (LST) et la session reste fermée. Lorsqu'un message d'information websocket (MSG_WS) en provenance du serveur (3) est détecté, le module proxy 2 le retransmet vers le client puis demande le réveil de la session mobile au serveur mobile (4) non représenté, qui procède au réveil du terminal par exemple en utilisant un message SMS binaire.This completely releases the first proxy module (2). It is assumed here, as previously in support of FIG. 5, that the first steps have resulted in an optimized N1 communication session between the terminal and the Websocket server, symbolized by the double arrow SS_WS (WSO, N1). During a step E20, identical to that of FIG. 5, the mobile terminal transmits to the second proxy module P2 a handshake message (HS WS (WSO, Ni, @ P1)) received during a step E30 by the second proxy module (20), for example that of the mobile network. In the following step E'31, the second proxy module (20) sends a request for a change of session to the server (3). This change request is symbolized by the message MV (P1, P2, N1) which indicates a switch request from a proxy P1 (for example the first proxy module (2)) to a proxy P2 (for example the proxy module (20)) for the session N1. Note that this message is a little different from that of the previous step E31: it is here to move the session from the first proxy module to the second, and not only to take the relay by retransmitting the application messages. In our example, the server (3) responds in a step E50 by an acknowledgment message (ACK). Then in a step E32, the proxy module 2 transmits to the terminal (1) the acknowledgment of the connection (SS_OK) with the number of the new session (N3). During a new step E51, the server (3) informs via a new message MV (P1, P2, N1) the first proxy module that the second proxy module will manage the consideration of the client change (from P1 to P2 ). This message, received by the first proxy module during a step E41, can be managed for example via the use of a specific field ("opcode") of a websocket type message left free for new applications. Those skilled in the art will be able to refer to IETF RFC 6455 ("The WebSocket Protocol", section 5, "data framing") accessible for example at the address http: //tools.ietf.ora/html/ rfc6455 # pacie-27, incorporated by reference. In our example, the effective taking into account of the change results in the sending of an acknowledgment message from the first proxy module (2) to the server on the one hand during step E41 and on the server (3). ) to the second proxy module (20) on the other hand (ACK) during a step E52. From this moment, the websocket session (SS_WS) is closed again. During a step E "4 similar to step E4 of FIG. 3 and step E'4 of FIG. 5, the second proxy module (20) supports the websocket session (SS_WS), in particular by a listening (LST) of the application messages exchanged on this session: as long as no message is detected, the proxy module listens (LST) and the session remains closed, When a websocket information message (MSG_WS) coming from the server (3) is detected, the proxy module 2 retransmits it to the client then requests the awakening of the mobile session to the mobile server (4) not shown, which wakes up the terminal for example using a binary SMS message.

La figure 7 représente un chronogramme des échanges entre les différents équipements du réseau local selon une autre variante de mise en oeuvre de l'invention. Cette variante permet notamment d'initialiser, puis d'indiquer un changement de méthode de notification de réveil pour le terminal (1). On peut en effet envisager plusieurs méthodes de notifications (message SMS, message de la norme « UPnP Low Power », message ZigBee, message Bluetooth 4.0, etc.) pour le réveil d'un même terminal à partir de différents serveurs (serveur SMSC pour un réveil de type SMS, serveur UPnP sur une passerelle domestique, etc.) Dans cette variante, une méthode de réveil souhaitée est précisée en paramètre lors du handshake initial entre le terminal et le module proxy (2) (paramètre METH1 du message 30 HS_WS). Le terminal notifie au module proxy une méthode de réveil spécifique parmi plusieurs possibles. Par exemple, le terminal est une tablette électronique qui ne supporte pas le réveil par SMS.FIG. 7 represents a timing diagram of the exchanges between the different pieces of equipment of the local network according to another alternative embodiment of the invention. This variant makes it possible, in particular, to initialize and then indicate a change of wake-up notification method for the terminal (1). Several notification methods can be envisaged (SMS message, "UPnP Low Power" message, ZigBee message, Bluetooth 4.0 message, etc.) for waking up the same terminal from different servers (SMSC server for example). an alarm clock of the SMS type, UPnP server on a home gateway, etc.) In this variant, a desired wake-up method is specified as a parameter during the initial handshake between the terminal and the proxy module (2) (parameter METH1 of message 30 HS_WS ). The terminal notifies the proxy module of a specific wake-up method among several possible. For example, the terminal is an electronic tablet that does not support SMS wake-up.

Dans ce contexte, le message de handshake peut par exemple prendre la forme suivante pour transmettre les informations de réveil, dans cet exemple un mode de réveil à base de SMS : Sec-WebSocket-Extensions:websocket-lowpower ; sessionid =mooc; wakeup=sms://699999999 On suppose alors, comme précédemment à l'appui des figures 3, 5 et 6, que les premières étapes ont abouti à une session de communication N1 optimisée entre le terminal et le serveur Websocket, symbolisée par la double flèche SS_WS(WSO, N1), et que le terminal peut être réveillé par la méthode METH1 (SMS binaire).In this context, the handshake message may for example take the following form to transmit the wake-up information, in this example an SMS-based wake-up mode: Sec-WebSocket-Extensions: websocket-lowpower; sessionid = mooc; wakeup = sms: // 699999999 It is then assumed, as previously in support of Figures 3, 5 and 6, that the first steps have resulted in an optimized communication session N1 between the terminal and the Websocket server, symbolized by the double arrow SS_WS (WSO, N1), and that the terminal can be woken up by method METH1 (binary SMS).

Lors d'une nouvelle étape E23, le terminal mobile transmet vers le module proxy (2) un message de notification d'une nouvelle méthode de réveil (WK_UP (METH)). Ce message est reçu par le module proxy lors d'une étape E60. Ce message peut être géré par exemple via l'utilisation d'un champ (« opcode ») spécifique d'un message websocket laissé libre pour de nouvelles applications, comme proposé auparavant.In a new step E23, the mobile terminal transmits to the proxy module (2) a notification message of a new wake up method (WK_UP (METH)). This message is received by the proxy module during a step E60. This message can be managed for example via the use of a specific field ("opcode") of a websocket message left free for new applications, as previously proposed.

Ce changement de méthode de réveil est particulièrement intéressant lorsque le terminal change de module proxy et que ce nouveau module proxy ne supporte pas l'ancienne méthode de réveil. Par exemple, la nouvelle méthode de réveil souhaitée peut être conforme à la norme « UPnP Low Power » dans le contexte du basculement du terminal (1) sur un réseau local. Lors des étapes E12 (terminal) et E2, E3, E4 identiques à celles décrites précédemment à l'appui de la figure 3, le module proxy (2) suspend la session websocketà l'issue d'un temps T écoulé sans message sur la session, puis à l'arrivée d'un nouveau message applicatif (MSG_WS) émet vers le serveur UPnP de la passerelle 4bis une demande de réveil conformément à la méthode qui a été choisie (message UPnP). Lors de l'étape E13 qui la suit, le terminal reçoit un message de réveil conforme à la méthode choisie. La session peut être rétablie, comme précédemment. Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l'homme de l'art sans pour autant sortir du cadre de l'invention. Notamment, l'invention peut aussi compléter un dispositif de mise en veille du terminal et permettre un réveil de celui-ci lorsque seulement des informations du serveur lui sont transmises.35This change of wake-up method is particularly interesting when the terminal changes proxy module and this new proxy module does not support the old wake up method. For example, the desired new wake up method may conform to the "UPnP Low Power" standard in the context of the terminal (1) failover over a local area network. During the steps E12 (terminal) and E2, E3, E4 identical to those previously described in support of FIG. 3, the proxy module (2) suspends the websocket session at the end of a time T elapsed without message on the session, then on the arrival of a new application message (MSG_WS) sends to the UPnP server of the gateway 4a a wake up request according to the method that has been chosen (UPnP message). During the following step E13, the terminal receives a wake-up message according to the chosen method. The session can be re-established, as before. It goes without saying that the embodiment which has been described above has been given for purely indicative and not limiting, and that many modifications can be easily made by those skilled in the art without departing from the scope of the invention. In particular, the invention may also complete a device for putting the terminal on standby and allowing it to be woken up when only information from the server is transmitted to it.

Claims

REVENDICATIONS1. A method of managing a communication session (SS_WS) between a terminal (1) able to exchange application messages (MSG_WS) with at least one server (3) via the communication session (SS_WS), said method being characterized in that it comprises the following steps: establishment (El) of the communication session (SS_WS) for exchanging application messages between the terminal (1) and the server (3); initialization (E2) of a period of time (T); detecting (E2) an application message (MSG_WS) relating to the communication session (SS_WS); closing (E3) of the communication session (SS_WS) at the end of this period of time (T), if no message has been detected.

2. Method according to claim 1, characterized in that the establishment step (El) of the communication session (SS_WS) comprises a substep of receiving an indication of the wake up method (METH1) to use .

3. Method according to claim 1, characterized in that the closing step (E3) is followed by: a second detection step (E4, LST) of at least one application message (MSG_WS) relating to the session of communication; a request for recovery step (E4, REQ_WK-UP) of the communication session (SS_WS) if an application message (MSG_WS) is detected during the second detection step.

4. Method according to claim 3, characterized in that it further comprises a retransmission step (E6) to the terminal (3) of the message (MSG_WS) detected on the communication session (SS_WS).

5. Method according to claim 3, characterized in that the recovery step (E4, REQ_WK-UP) of the communication session (SS_WS) (E3) is followed by a step of receiving (E60) a message (WK_UP (METH2)) indicating an awakening method (METH2) to be used.

6. Method according to claim 3, characterized in that the recovery step (E4) of the communication session is followed by: - a reception step (E40, E41) of a message support proposition applications by another proxy module; an acceptance step (E40, E41) of the support of the application messages.

7. Method of switching from a first session (SS (WSO, N1) to a second session SS (WSO, N2)) of communication between a terminal (1) and a server (3), the first communication session (SS_WS (WSO, N1)) being established according to claim 1 by the execution of a first proxy module, the second communication session (SS_WS (WSO, N2)) to be established by a second proxy module (20), said method characterized in that it comprises the following steps: receiving (E30) a request (HS_WS (WSO, N1, @ P1)) to modify the first communication session (SS_WS (WSO, N1)), said request comprising at least one identifier (@ P1) of the first proxy (2, @ P1) and an identifier of the first session (N1); transmitting (E31, E'31) by the second proxy (20) of a support proposal message (CH (P1, P2, N1), MV (P1, P2, N1)) of the first session; assigning (E32) a session number (N2, N3) to the second session; establishment (E33) of the second session (SS_WS (WSO, N2)) by the second proxy.

8. Failover method according to claim 7, characterized in that the application messages (MSG_WS) of the server are received (E'4) by the first proxy module (2) and retransmitted to the second proxy module (20).

9. A method of communicating a terminal (1) able to exchange application messages with at least one server (3) via a communication session (SS_WS), said method being characterized in that it comprises the following steps: sending a communication logon message (E10 - handshake) - receiving (E11) a session identifier (NUM) for the communication session (SS_WS); - closing (E12) of the session (SS_WS); receiving (E13) a request for restoration (WK_UP (NUM)) of the session; sending a message (E14) for the recovery of the communication session (SS_WS) including the identifier (NUM) of the session.

10. Device for managing (2, PW) a communication session (SS_WS) between a terminal (1) able to exchange application messages (MSG_WS) with at least one server (3) via the communication session (SS_WS) , said device being characterized in that it comprises: an establishment module (El) of the communication session (SS_WS) for exchanging application messages between the terminal (1) and the server (3); an initialization module (E2) of a period of time (T); a detection module (E2) of an application message (MSG_WS) relating to the communication session (SS_WS); a closing module (E3) of the communication session (SS_WS) at the end of this period of time (T), if no message has been detected.

11. Device for switching from a first session (SS (WSO, N1)) to a second session SS (WSO, N2)) of communication between a terminal (1) and a server (3), the first communication session ( SS_WS (WSO, N1)) being established according to claim 10 by a first proxy module device, the second communication session (SS_WS (WSO, N2)) to be established by a second proxy module device (20), said second device being characterized in that it comprises the following modules: a module for receiving a request for modifying the first communication session (SS_WS (WSO, N1)), said request comprising at least one identifier (@ P1) of the first proxy ( 2) and an identifier of the first session (N1); a transmission module (E31, E'31) by the second proxy (20) of a session support proposal message (CH (P1, P2, N1), MV (P1, P2, N1) ); an assignment module (E32) of a session number (N2, N3) at the second session; an establishment module (E33) of the second session (SS_WS (WSO, N2)) by the second proxy.

12. Domestic gateway (1) comprising a management device according to claim 10 and / or a tilting device according to claim 11. 25

Terminal (1) capable of exchanging application messages with at least one server (3) via a communication session (SS_WS), said terminal comprising: a module capable of transmitting a communication opening message (E10 - handshake); A reception module (E11) of a session identifier (NUM) for the communication session (SS_WS); - a closing module (E12) of the session (SS_WS); a reception module (E13) for a request to restore the session; a module for sending a message (E14) for restoring the communication session (SS_WS) including the identifier (NUM) of the session.

14. System comprising a terminal according to claim 13 and a home gateway according to claim 12.

15. Computer program adapted to be implemented on a device as defined in claim 10, the program comprising code instructions which, when the program is executed by a processor, performs the steps of the method defined according to the claim. 1.

16. Computer program adapted to be implemented on a device as defined in claim 11, the program comprising code instructions which, when the program is executed by a processor, performs the steps of the method defined according to the claim 7.