GB2611284A

GB2611284A - Managing Connectivity Between Devices

Info

Publication number: GB2611284A
Application number: GB2112760.0A
Authority: GB
Inventors: Sasin Szymon
Original assignee: Pelion Technology Inc
Current assignee: Pelion Technology Inc
Priority date: 2021-09-08
Filing date: 2021-09-08
Publication date: 2023-04-05
Also published as: GB202112760D0

Abstract

A method 600 of managing connectivity between a client device (10, Figure 2) and a server (20, Figure 2), wherein the server receives a handshake initiation message from the client device 620 specifying a registration at the server 610 and a connection ID for a session with the client device. The server further receives an inquiry from the client device 630 as to the connection status between the client device and the server. The inquiry may be sent in response to the client device not receiving a reply to data, including the connection ID, sent from the client device to the server within a first predetermined period. The inquiry may be a first message of a second handshake (e.g. a ClientHello request) and may comprise the connection ID, and upon receiving the inquiry the server may send a response (e.g. a HelloVerifyRequest message). The method reduces the need for handshakes and may be used for machine to machine (M2M) communications secured using the Datagram Transport Layer Security (DTLS) protocol.

Description

Intellectual Property Office Application No G132112760.0 RTM Date:17 February 2022 The following terms are registered trade marks and should be read as such wherever they occur in this document: WiFi, ZigB ee, Thread, Bluetooth Intellectual Property Office is an operating name of the Patent Office www.gov.uk/ipo Managing Connectivity Between Devices The present techniques relate to methods for managing connectivity between devices, and in particular to a reduced bandwidth communication technique between devices.

Cloud computing services are becoming more common. More and more devices are being connected to the cloud, as there are ever increasing numbers of devices within buildings, vehicles and the outdoor environment, as well as personal devices, which have the processing and communication capabilities to enable them to communicate with other devices (e.g. end-point devices, servers, etc.) within the same network or in a different network to access services as part of the "Internet of Things" (IoT).

For example, devices such as temperature sensors, healthcare monitors and electronic door locks can be connected to the cloud so that they can be accessed and controlled using remote systems.

For example, a door may be remotely unlocked or opened from a remote platform. In another example, a temperature device in the home may gather sensed data and push the sensed data to a remote service (such as an application running in 'the cloud'). The temperature device may then be controlled remotely by the remote service via received command data. In other examples, a factory pollution monitoring sensor may gather information from various chemical sensors and arrange maintenance based on the gathered information; whilst a healthcare provider may use wireless sensors, such as a heart rate monitor to track the health of patients while they are at home. Such devices are used in a range of networks, whereby the data is generally transmitted between devices and/or services using machine-to-machine (M2M) communication techniques.

M2M communication techniques typically need to be secure, for example, because sensitive data may be transmitted between devices to servers, and/or because unsecure communication may enable malicious third parties to gain access to the machines or to the data being transmitted between machines. M2M communications may be secured using cryptographic protocols, such as the Datagram Transport Layer Security (DTLS) protocol, which is designed to prevent eavesdropping, tampering or message/data forgery. The DTLS protocol requires machines that seek to communicate with each other (e.g. end-point devices and servers) to authenticate each other by exchanging and validating digital certificates in a handshake process. However, the handshake process usually requires a large amount of data to be sent between the machines, often several kB per handshake, often on limited or constrained network resources. In scenarios where communication occurs frequently (e.g. every few minutes, every hour, etc.), performing a DTLS handshake process between a server and a device can place strain on the network resources. Further, devices which are remote may have limited power resources, as power may be at a premium or the devices may be battery-based, and therefore be required to save energy wherever possible, and so frequent DTLS handshake operations can place a strain on the device resources. In devices which spend significant time in a sleep mode, such as for remote devices which enter extended sleep periods to increase their battery lifetime, a DTLS handshake may force the device to be awake for longer, forcing the sleeping periods to be longer to compensate.

It would therefore be desirable to provide improved techniques to manage connectivity between devices.

According to a first technique, there is provided a method of managing connectivity between a client device and a server, the method performed by the client device comprising: sending a handshake initiation message to a server, specifying a registration at the server; sharing a connection ID with the server for a session; sending data to the server including the connection ID; and in response to the client device not receiving a reply from the server within a first predetermined period, initiating an inquiry of the server to determine a connection status between the client device and the server.

According to a second technique, there is provided a client device comprising: a processor for: determining a handshake initiation message and a connection ID for communication to a server; and a transceiver for: sending the handshake initiation message to the server, specifying a registration at the server; sharing the connection ID with the server for a session; and sending data to the server including the connection ID; the processor, in response to the client device not receiving a reply from the server within a first predetermined period, initiating, via the transceiver, an inquiry of the server to determine a connection status between the client device and the server.

According to a third technique, there is provided a method of managing connectivity between a client device and a server, the method performed by the server comprising: receiving a handshake initiation message from a client device, specifying a registration at the server; receiving a connection ID from the client device for a session; and receiving an inquiry from the client device to determine a connection status between the client device and the server.

According to a fourth technique, there is provided a server comprising: a transceiver for: receiving a handshake initiation message from a client device, specifying a registration at the server; receiving a connection ID from the client device for a session; and receiving an inquiry from the client device to determine a connection status between the client device and the server.

Embodiments will now be described with reference to the accompanying figures of which: Figure 1 illustrates a schematic diagram of a client device according to various examples; Figure 2 illustrates a schematic diagram of a system according to various examples.

Figure 3 illustrates a flow diagram of blocks of a method at a client device according to various examples; Figure 4 illustrates a flow diagram of blocks of a method at a client device according to various examples; Figure 5 illustrates a flow diagram of blocks of a method at a client device according to various examples; Figure 6 illustrates a flow diagram of blocks of a method at a server according to various examples; Figure 7 illustrates a flow diagram of blocks of a method at a server according to various examples; and Figure 8 illustrates a flow diagram of blocks of a method at a server according to various examples.

Broadly speaking, embodiments of the present technique provide methods, apparatuses and systems for managing connectivity between devices 5 in a manner that reduces the need for DTLS handshakes when a client device is deployed on or connected to a limited or constrained network.

The DTLS protocol may be used to secure communication between a client device and a remote or cloud-based server, for example. In this case, during the handshake process, the client device and server exchange their public key certificates (also known as digital certificates or identity certificates). Digital certificates are electronic documents used to prove the ownership of a public key that is used as part of an asymmetric key algorithm (i.e. which forms part of a public-private key pair). A digital certificate typically comprises information about the public key, information about the identity of its owner (e.g. the client device or server), and the digital signature of an issuing entity that has verified the contents of the certificate (e.g. a trusted third party such as a certificate authority). A digital certificate can be large, particularly if it comprises a certificate chain, or if each certificate is an RSA certificate (i.e. where a public key is based on two large prime numbers). For example, a single RSA-based certificate containing a 2048-bit key may be at least 1024 bytes in size.

Similarly, at least the first time a DTLS handshake is performed between a client device and a server, the client device and server need to decide on which cryptographic algorithm(s) or ciphers or cipher suites they will use to secure communication sessions. For example, the client device may send a list of cipher suites that it supports, potentially in order of preference. The server selects a cipher suite from the list and informs the client device of this selection. The list of cipher suites may be large, which increases the amount of information sent between machines during a DTLS handshake. This means that every time a client device and a server perform a handshake process to begin a secure communication session (i.e. a session during which the client device and server exchange encrypted messages), large amounts of data may need to be exchanged.

The exchange of certificates in a handshake process may be problematic in an environment in which client devices or end-user devices tend to be low-power, low-memory, and/or low-processing power devices. Client devices (also considered as end-user devices) may have intermittent, limited, or otherwise constrained connectivity with a network in which they are operational, or with an external network, or other devices within a network. For example, client devices may not have good connectivity with the other devices, such as a server, because this may consume resources of the client devices, such as power. Client devices may not have good connectivity with a server because of a limited or constrained network, where such a network may be limited or constrained due to the amount of network traffic. More generally, the exchange of certificates in a DTLS handshake process may be problematic in any scenario in which the client device is a constrained resource device. Accordingly, the techniques described herein may reduce the need for handshakes. The techniques described herein may optimise a DTLS handshake process, such that the handshake process is more efficient and requires less data to be transmitted. This may be useful for constrained resource devices and/or where devices or servers may only be able to transmit/receive a limited amount of data because of a limited or constrained network. The process for reducing handshake requirements is described in more detail below with reference to the figures.

Figure 1 illustrates a schematic diagram of an apparatus 10, where the apparatus 10 may be in the form of a client device 10 which may be remote from a server 20 and connected thereto by or via a network 30.

The client device 10 comprises processing means 12 in the form of a processor 12 or processing circuitry. Processor 12 may control various processing operations performed by client device 10, such as verifying a digital certificate and authenticating a machine which attempts to communicate with client device 10. The processor 12 may comprise processing logic to process data (e.g. data signals and data packets received from other machines within system 100), and generate output data in response to the processing. The processor 12 may comprise one or more of: a microprocessor, a microcontroller, and an integrated circuit.

The client device 10 further comprises communication means 14 in the form of a communication module, communication circuitry, or transmitter and receiver circuitry to enable the client device 10 to communicate with other machines, such as bootstrap server or server 20, or with other client devices.

Typically, the other machines are located remote to the client device 10.

The communication means 14 may be any suitable communication means, comprising any suitable communication circuitry and using any suitable communication protocols, to transmit and receive messages (or data or data packets). The communication means 14 may use any suitable communication protocol to communicate with other machines, such as, but not limited to, wireless communication (e.g. WiFi), short range communication such as radio frequency communication (RFID) or near-field communication (NFC), or by using the communication protocols specified by ZigBee, Thread, Bluetooth, Bluetooth LE, IPv6 over Low Power Wireless Standard (6L0WPAN), or Constrained Application Protocol (CoAP). The communication means 14 may use a wireless mobile (cellular) telecommunication protocol to communicate with remote machines, e.g. 3G, 4G, 5G, etc. The client device 10 may communicate with remote machines using wired communication techniques, such as via metal cables or fibre optic cables. The client device 10 may use more than one communication technique to communicate with remote machines. For example, the communication means 14 may be in the form of a transceiver 14 for receiving messages and/or data from a server 20 and transmitting messages and/or data to a server 20.

Client device 12 may also comprise storage 16. Storage 16 may comprise a volatile memory, such as random access memory (RAM), for use as temporary memory, and/or non-volatile memory such as Flash, read-only memory (ROM), or electrically erasable programmable ROM (EEPROM), for storing data, programs or instructions.

Figure 2 illustrates a schematic diagram of an example system 100 comprising a client device 10, server 20 and network 30. The server 20 is arranged or configured for communication with the client device 10 via a network 30. The server 20 comprises communication means 22 in the form of a communication module, communication circuitry, or transmitter and receiver circuitry to enable the server 20 to communicate with other machines. Typically, the other machines are located remote to the client device 10. The communication means may be any suitable communication means, comprising any suitable communication circuitry and using any suitable communication protocols, to transmit and receive messages (or data or data packets). The communication means may use any suitable communication protocol to communicate with other machines, such as, but not limited to, wireless communication (e.g. WiFi), short range communication such as radio frequency communication (RFID) or near-field communication (NEC), or by using the communication protocols specified by ZigBee, Thread, Bluetooth, Bluetooth LE, IPv6 over Low Power Wireless Standard (6LoWPAN), or Constrained Application Protocol (CoAP). The communication means may use a wireless mobile (cellular) telecommunication protocol to communicate with remote machines, e.g. 3G, 4G, 5G, etc. The server 20 may communicate with remote machines using wired communication techniques, such as via metal cables or fibre optic cables. The server 20 may use more than one communication technique to communicate with remote machines. For example, the communication means 22 may be in the form of a transceiver 22 for receiving messages and/or data from a client device 10 and transmitting messages and/or data to a client device 10.

Client device 10 may communicate with server 20 using appropriate communication standards/protocols. It will be understood that intermediary devices (such as a gateway) may be located between client device 10 and sever 20, to facilitate communication between the machines.

Client device 10 may, in embodiments, be an Internet of Things (IoT) device or a constrained resource device. Server 20 may be a lightweight machine-to-machine server (LWM2M server), such that the server 20 and client device 10 communicate using the Open Mobile Alliance (OMA) LWM2M protocol, or other LWM2M protocol. Server 20 may be an OMA Device Management (DM) server, such that the server 20 and client device 10 communicate using the OMA DM communication protocol. Server 20 may be a TR-069 server (which is a bidirectional SOAP/HTTP-based protocol), such that server 20 and client device communicate using the CPE WAN Management protocol (CWMP) published by the Broadband Forum. Server 20 may be a server which follows a standard/protocol set by the Open Connectivity Foundation or Open Interconnect Consortium.

Server 20 may communicate with services which may, for example, be part of a private cloud or public cloud environment on the internet, or which may be hosted on server 20. The services may provide different types of services such as data storage, data analytics, data management, application services, etc. It will be understood these listed services are merely examples and are non-limiting.

A method of managing connectivity between a client device 10 and a server 20 will now be described in relation to figures 3 to 8.

Figure 3 illustrates a method 300 of managing connectivity between a client device 10 and a server 20 carried out at the client device 10. The method comprises an initial handshake and subsequent communication between the client device 10 and the server 20 using DTLS. In an initial block 310 of the method 300, a DTLS handshake operation is initiated by the client device 10 by sending a handshake initiation message to a server 20, specifying a registration at the server 20, with the aim of making a connection with the server 20. It will be clear to one of ordinary skill in the art that there may in fact be multiple flows back and forth between the client device 10 and the server 20 during the handshake procedure, but these flows have been omitted for conciseness and ease of explanation. The handshake is an initial negotiation between the client device 10 and the server 20 that establishes the parameters of their transactions.

At block 320, a connection ID is shared with the server 20. The connection ID is a construct for the DTLS protocol which is added to the DTLS record layer. The connection ID is set at the beginning of a DTLS session, and can be used in subsequent ClientHello and ServerHello messages during that session. The connection ID therefore identifies a session, the session being an association between the client device 10 and the server 20 resulting from the handshake. The connection ID removes the need to engage in a new handshake each time the client device 10 and server 20 are connected. When a full handshake negotiation has been completed between the client device 10 and the server 20, the client device 10 and the server 20 will share a unique connection ID. This connection ID may be a random identifier. The connection ID allows reuse of the existing session as long as the server 20 recognises the connection ID within a timeout period of that session.

Thus, the client device 10 can enter a sleep mode, thereby saving power, and subsequently wake up and continue to use the existing session without a new handshake being required, again saving considerable power. By using a connection ID, the number of handshake operations can be significantly reduced and the client device 10 can go to sleep more often since a handshake is not required on wake up, thereby saving power each time the client device 10 wakes up for example to update a data resource value. Further, when using the same connection ID session, a different Internet Protocol (IP) address can be used by the client device 10. This may be particularly useful if the client device IP address changes, such as in the case of Network Address Translation in IPv4 networks, which can cause a change in the IP address.

At block 330, data, for example in the form of, or including, encrypted packets, is sent to the server 20, from the client device 10. The data sent to the server 20 also includes the connection ID.

Each session has a time limit, and this time limit may not be the same between different sessions, as it may vary dependent on the amount of network traffic. Therefore, it is not possible to accurately predict when the session will expire at the server 20, and so the client device 10 does not know when the session at the server 20 will no longer be available. The client device 10 may receive no reply from the server 20 after it has sent data to the server 20, but the client device 10 will not know whether this is due to a network issue or if the server 20 no longer maintains this session. The server 20 is not allowed to send any communication to the client device 10 in response to the receipt of data if the session is no longer available. The client device 10 may repeat the sending of the data one or more further times should no response from the server 20 be received. Alternatively, the data may only be sent once. However, at some later time after the sending of the data, the process will timeout and the connection between the client device 10 and the server 20 will have to be restarted with a new handshake procedure.

In order to avoid a new handshake procedure when the issue may be network related rather than a lost session at the server 20, in response to the client device 10 not receiving a reply from the server 20 within a first predetermined period, an inquiry of the server 20 may be initiated in block 340 to determine a connection status between the client device 10 and the server 20. The first predetermined period may be set during deployment or commissioning of the client device 10.

In a first example method 400, illustrated in figure 4, the inquiry of the server 20 comprises sending a first message of a second handshake from the client device 10 to the server 20. In terms of a DTLS handshake this first message is a ClientHello request. The ClientHello request is not encrypted as there is no critical information held in the ClientHello.

In block 410, If the client device 10 receives a response to the inquiry of the server 20 within a second predetermined period, then a new handshake initiation message is sent from the client device 10 to the server 20, in block 420, specifying a new registration at the server 20 and a new connection ID is shared with the server 20 for a new session. That is, the client device 10 determines that the connection with the server 20 is working, since it has received a response to the inquiry, but it is determined that the DTLS session has been lost, since it received no response, from the server 20, in response to the initial sending of data. When the inquiry of the server 20 comprises a first message of a second handshake in the form of a ClientHello message, the response to the inquiry of the server 20 should be a HelloVerifyRequest message.

In block 430, if the client device 10 does not receive a response to the inquiry of the server 20 within a second predetermined period, then the client device 10 determines that the connection between the client device 10 and the server 20 has been lost. That is, it is determined that there is a network issue, which may be temporary or permanent, rather than a loss of the session at the server 20, and so the old session can be maintained and the client device 10 can try to reconnect to the server 20 at a later time, without removing the current DTLS session. The second predetermined period may be set during deployment or commissioning of the client device 10.

Optionally, in block 440, if the client device 10 does not receive a response to the inquiry of the server 20 within the second predetermined period, then the client device 10 may repeat the inquiry of the server 20 in order to try to determine a connection status between the client device 10 and the server 20. The period between repeat inquiry attempts and the number of repeat inquiry attempts may be set during deployment or commissioning of the client device 10. The period between repeat inquiry attempts and the number of repeat inquiry attempts may be chosen to avoid or minimise network congestion.

Where the client device 10 does not receive a response to the inquiry of the server 20 within the second predetermined period it may repeat the inquiry of the server 20 until either the client device 10 receives a response to the inquiry of the server 20, or a predetermined number of repeat inquiries is reached. Each repeat inquiry may be separated by the second predetermined period, or may be separated by varying time periods. For example, the time period may double on each retransmission of the inquiry until a maximum time period is reached. In this instance it is considered that the DTLS session has not been lost but that there is an ongoing network issue, so the DTLS session can be maintained and the client device 10 can try to reconnect to the server 20 at a later time, without removing or abandoning the current DTLS session.

In a second example method 500, illustrated in figure 5, the inquiry of the server 20 comprises sending the connection ID. The inquiry of the server 20 may comprise sending a first message of a second handshake from the client device 10 to the server 20 which includes the connection ID. In terms of a DTLS handshake this first message is a ClientHello request including the connection ID. In block 510, if the client device 10 receives a response to the inquiry of the server 20 within a second predetermined period, and the response includes the connection ID, the client device 10 determines, in block 520, that the connection between the client device 10 and the server 20 is present and that the server 20 has maintained the session. That is, the connection with the server 20 is working and the DTLS session can be continued or resumed. The client device 10 can then send data, which may be the encrypted packets, to the server 20 including the connection ID to continue operation of the system 100. When the inquiry of the server 20 comprises a first message of a second handshake in the form of a ClientHello message, the response to the inquiry of the server should be a HelloVerifyRequest message.

In block 530, if the client device 10 receives a response to the inquiry of 5 the server 20 within a second predetermined period, and the response does not include the connection ID, the client device 10 determines that the server 20 has lost the session. When it is determined that the server 20 has lost the session, the client device may send a new handshake initiation message to the server 20, in block 540, specifying a registration at the server to begin a new session, and 10 may share a new connection ID with the server 20 for the new session. That is, if the session is lost then the client device 10 must continue with a new handshake for a new session with the server 20.

If no response is received from the server 20 to the inquiry of the server 20 then the client device 10 determines that the connection between the client device 10 and the server 20 has been lost. That is, it is determined that there is a network issue, which may be temporary or permanent, rather than a loss of the session at the server 20, and so the old session can be maintained and the client device 10 can try to reconnect to the server 20 at a later time, without removing the current DTLS session. As with the first example method previously described, the inquiry of the server 20 can be repeated, in this case also identifying the connection ID, one or more times, in order to try to determine a connection status between the client device 10 and the server 20.

The client device 10 may carry out the above blocks of the method in order to manage connectivity between the client device 10 and the server 20.

The client device 10 comprises processing means 12, for example in the form of a processor 12, for determining a handshake initiation message and a connection ID for communication to a server 20; and communication means 14, for example in the form of a transceiver 14, for sending the handshake initiation message to the server 20, specifying a registration at the server 20, sharing the connection ID with the server 20 for a session, and sending data to the server including the connection ID. The processing means 12, in response to the client device 10 not receiving a reply from the server 20 within a first predetermined period, initiates, via the communication means 14, an inquiry of the server 20 to determine a connection status between the client device 10 and the server 20.

Figure 6 illustrates a method 600 of managing connectivity between a client device 10 and a server 20, carried out at the server 20. The method comprises, at block 610, receiving a handshake initiation message from a client device 10, specifying a registration at the server 20. Thus, the client device, by initiating the handshake with the server, is requesting a session to be created where the parameters of the transactions between the client device 10 and the server 20 are established. At block 620, a connection ID is received from the client device 10 for a session.

At block 630, an inquiry is received at the server 20, from the client device 10, to determine a connection status between the client device 10 and the server 20, that is, to determine whether there is a network issue, such that a session can be maintained, or whether the server has lost a previous session, such that data, for example in the form of encrypted packets, cannot be transferred from the client device 10 to the server 20 without the need for a new handshake procedure. The server 20 will only receive such an inquiry when the client device 10 has sent data to the server 20 but has not received a response.

The inquiry from the client device 10 comprises receiving, at the server 20, a first message of a second handshake from the client device 10. In terms of a DTLS handshake this first message is a ClientHello request.

Figure 7 illustrates a first example method 700 at the server, for responding to an inquiry from the client device 10. In response to receiving the inquiry from the client device 10, the server 20 sends a response, at block 710, to the inquiry of the server 20 to the client device 10. When the inquiry of the server 20 comprises a first message of a second handshake in the form of a ClientHello message, the response to the inquiry of the server 20 should be a HelloVerifyRequest message. Then, in response to sending the response to the inquiry of the server 20, the server 20 receives, in block 720, a new handshake initiation message from the client device 10 specifying a registration at the server 20 and a new connection ID for a new session. That is, by receiving the inquiry at the server 20, and transmitting the response message from the server to the client device 10, the client device 10 establishes that the connection with the server 10 is working but that the DTLS session has been lost. The client device 10 then proceeds with a new handshake with the server 20 in order to transmit data to the server 20.

Figure 8 illustrates a second example method 800 at the server 20, for responding to an inquiry from the client device 10. In this second example, the inquiry from the client device 10 comprises receiving, at the server 20, the connection ID. In particular, the inquiry from the client device 10 may comprise receiving, at the server 20, a first message of a second handshake from the client device 10 including the connection ID. In terms of a DTLS handshake this first message of the second handshake is a ClientHello request including the connection ID.

Then, at block 810, if the connection ID is recognised by the server 20, a response to the inquiry of the server 20 including the connection ID is sent to the client device 10 at block 820.

At block 810 if the server 20 does not recognise the connection ID, a response to the inquiry of the server 20 is sent, without the connection ID, to the client device 10 at block 830.

If the connection ID is recognised at the server 20, then the current DTLS session can be continued or resumed, the client device 10 can then send data, for example in the form of encrypted packets of data, to the server 20 including the connection ID. However, if the connection ID is not recognised at the server 20, then a new DTLS session needs to be started by the client device 10 by performing a new handshake with the server 20 with a new connection ID, in block 840.

The server 20 may carry out the above blocks of the method in order to manage connectivity between the client device 10 and the server 20. The server 20 comprises communication means 22, for example in the form of a transceiver 22, for receiving a handshake initiation message from a client device 10, the handshake initiation message specifying a registration at the server 20. The communication means 22 receives a connection ID from the client device 10 for a session. At a later time, after the session has been created, the communication means 22 of the server 20 receives an inquiry from the client device 10 to determine a connection status between the client device 10 and the server 20, indicating that the client device 10 has previously sent data to the server 20 but has not received a response from the server 20 as a result.

As will be appreciated by one skilled in the art, the present techniques may be embodied as a system, method or computer program product. Accordingly, the present techniques may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware.

Furthermore, the present techniques may take the form of a computer program product embodied in a computer readable medium having computer readable program code embodied thereon. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable storage medium may be a non-transitory computer readable storage medium encoded with instructions that, when performed by a processing means, cause performance of the method described above. A computer readable medium may be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

Computer program code for carrying out operations of the present techniques may be written in any combination of one or more programming languages, including object oriented programming languages and conventional procedural programming languages.

For example, program code for carrying out operations of the present techniques may comprise source, object or executable code in a conventional programming language (interpreted or compiled) such as C, or assembly code, code for setting up or controlling an ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array), or code for a hardware description language such as VerilogTM or VHDL (Very high speed integrated

circuit Hardware Description Language).

Code components may be embodied as procedures, methods or the like, and may comprise sub-components which may take the form of instructions or sequences of instructions at any of the levels of abstraction, from the direct machine instructions of a native instruction set to high-level compiled or interpreted language constructs.

It will also be clear to one of skill in the art that all or part of a logical method according to the preferred embodiments of the present techniques may suitably be embodied in a logic apparatus comprising logic elements to perform the steps of the method, and that such logic elements may comprise components such as logic gates in, for example a programmable logic array or application-specific integrated circuit. Such a logic arrangement may further be embodied in enabling elements for temporarily or permanently establishing logic structures in such an array or circuit using, for example, a virtual hardware descriptor language, which may be stored and transmitted using fixed or transmittable carrier media.

In one alternative, an embodiment of the present techniques may be realized in the form of a computer implemented method of deploying a service comprising steps of deploying computer program code operable to, when deployed into a computer infrastructure or network and executed thereon, cause said computer system or network to perform all the steps of the method.

In a further alternative, the preferred embodiment of the present techniques may be realized in the form of a data carrier having functional data thereon, said functional data comprising functional computer data structures to, when loaded into a computer system or network and operated upon thereby, enable said computer system to perform all the steps of the method.

It will be clear to one skilled in the art that many improvements and 25 modifications can be made to the foregoing exemplary embodiments without departing from the scope of the present techniques.

Features described in the preceding description may be used in combinations other than the combinations explicitly described.

Although functions have been described with reference to certain features, 30 those functions may be performable by other features whether described or not.

Although features have been described with reference to certain embodiments, those features may also be present in other embodiments whether described or not.

Claims

CLAIMS1. A method of managing connectivity between a client device and a server, the method performed by the client device comprising: sending a handshake initiation message to a server, specifying a registration at the server; sharing a connection ID with the server for a session; sending data to the server including the connection ID; and in response to the client device not receiving a reply from the server within a first predetermined period, initiating an inquiry of the server to determine a connection status between the client device and the server.
2. A method according to claim 1, wherein the inquiry of the server comprises sending a first message of a second handshake from the client device to the server.
3. A method according to claim 2, wherein the first message of the second handshake is a ClientHello request.
4. A method according to any preceding claim, wherein, if the client device receives a response to the inquiry of the server within a second predetermined period, then a new handshake initiation message is sent from the client device to the server specifying a registration at the server and a new connection ID is shared with the server for a new session.
5. A method according to any of claims 1 to 3, wherein, if the client device does not receive a response to the inquiry of the server within a second predetermined period, then the client device determines that the connection between the client device and the server has been lost.
6. A method according to claim 5, wherein if the client device does not receive a response to the inquiry of the server within the second predetermined period, then the client device repeats the inquiry of the server to determine a connection status between the client device and the server.
7. A method according to claim 6, wherein the client device repeats the inquiry of the server until either the client device receives a response to the inquiry of the server, or a predetermined number of repeat inquiries is reached.
8. A method according to claim 1, wherein the inquiry of the server comprises sending the connection ID.
9. A method according to claim 8, wherein the inquiry of the server comprises sending a first message of a second handshake from the client device to the server including the connection ID.
10. A method according to claim 9, wherein the first message of the second handshake is a ClientHello request including the connection ID.
11. A method according to any of claims 8 to 10, wherein, if the client device receives a response to the inquiry of the server within a second predetermined period, and the response includes the connection ID, the client device determines that the connection between the client device and the server is present and that the server has maintained the session.
12. A method according to any of claims 8 to 10, wherein, if the client device receives a response to the inquiry of the server within a second predetermined period, and the response does not include the connection ID, the client device determines that the server has lost the session.
13. A method according to claim 12, wherein when it is determined that the server has lost the session, the client device sends a new handshake initiation message to the server specifying a registration at the server, and shares a new connection ID with the server for a new session.
14. A method according to any of claims 4 to 7 or any of claims 11 to 13, wherein the response to the inquiry of the server is a HelloVerifyRequest message.
15. A client device comprising: a processor for: determining a handshake initiation message and a connection ID for communication to a server; and a transceiver for: sending the handshake initiation message to the server, specifying a registration at the server; sharing the connection ID with the server for a session; and sending data to the server including the connection ID; the processor, in response to the client device not receiving a reply 10 from the server within a first predetermined period, initiating, via the transceiver, an inquiry of the server to determine a connection status between the client device and the server.
16. A method of managing connectivity between a client device and a server, the method performed by the server comprising: receiving a handshake initiation message from a client device, specifying a registration at the server; receiving a connection ID from the client device for a session; and receiving an inquiry from the client device to determine a connection status between the client device and the server.
17. A method according to claim 16, wherein the inquiry from the client device comprises receiving, at the server, a first message of a second handshake from the client device.
18. A method according to claim 17, wherein the first message of the second handshake is a ClientHello request.
19. A method according to any of claims 16 to 18, comprising, in response to receiving the inquiry from the client device, sending a response to the inquiry of the server.
20. A method according to claim 19, comprising, in response to sending the response to the inquiry of the server, receiving a new handshake initiation message from the client device specifying a registration at the server and a new connection ID for a new session.
21. A method according to claim 16, wherein the inquiry from the client device comprises receiving, at the server, the connection ID.
22. A method according to claim 21, wherein the inquiry from the client device comprises receiving, at the server, a first message of a second handshake from the client device including the connection ID.
23. A method according to claim 22, wherein the first message of the second handshake is a ClientHello request including the connection ID.
24. A method according to claim 22 or claim 23, comprising: if the server recognises the connection ID, sending a response to the inquiry of the server including the connection ID to the client device, and if the server does not recognise the connection ID, sending a response to the inquiry of the server without the connection ID to the client device.
25. A method according to claim 19, claim 20 or claim 24, wherein the response to the inquiry of the server is a HelloVerifyRequest message.
26. A server comprising: a transceiver for: receiving a handshake initiation message from a client device, specifying a registration at the server; receiving a connection ID from the client device for a session; and receiving an inquiry from the client device to determine a connection status between the client device and the server.
27. A non-transitory computer readable storage medium encoded with instructions that, when performed by a processing means, cause performance of the method of any one of claims 1 to 14 or claims 16 to 25.