FIELD OF THE INVENTION

The present invention generally relates to network technology. More particularly, the invention relates to share information in the network.

BACKGROUND OF THE INVENTION

In a network, there are some variables whose value is shared by multiple devices in the network. This kind of variable is referred to as shared variable because it is shared by these multiple devices in the network. For example, "the online device amount" is a variable indicating how many devices are online in the network. The value of this variable can be used by many devices in the network, in other words, it is a shared variable.

There are generally two methods of storing this kind of shared variable:

(1) The shared variable is stored on a single device. However, when the device on which the shared variable is stored leaves the network, other devices in the network cannot obtain the value anymore. Consequently, this is not a robust method.

(2) The shared variable is stored on multiple devices in the network. This is referred to as the distributed method. Even when some (not all) devices are offline, it is still possible to retrieve the value of the shared variable. Consequently, this distributed method is robust and thus preferred. Such a shared variable which is stored in a distributed way is referred to as distributed variable. The term "distributed variable" is hereinafter understood to mean a variable which is stored in a distributed way (e.g. stored in multiple devices), and the data of the variable are intended to be used by multiple devices (e.g. intended to be shared by multiple devices).

There are potential synchronization problems when using the distributed method. For instance, let it be assumed that a shared variable SV is stored in three devices O-P-Q (e.g. the variable SV is a distributed variable). When the following steps are performed, and if synchronization is not applied properly, there is the risk that ambiguous values are obtained:

(1) All devices O-P-Q are online in the network, and an initial value "M" of SV is stored in all of the three devices;

(2) Later, device O and device Q are offline, and at this time, a step of updating the value of SV is performed, and the new value is set to "N"; therefore, the value of SV stored in device P is updated to "N". However, device O and device Q fail to be updated; their value of SV is still "M".

(3) When device O and device Q are online again, and a device D in the network wants to retrieve the current value of SV and query device O-P-Q, a confusing result "M" and "N" will be obtained; device D has to judge which one is the latest (updated) value.

Synchronization is therefore critical in solving the ambiguity in this distributed method. One synchronization method uses a common timestamp. If the internal clocks of all devices in the network are synchronized when a new value is set to the distributed variable, a timestamp is also marked; therefore, when ambiguity occurs, it is easy to judge, on the basis of the associated timestamp, which one is the latest.

Another synchronization method uses a time counter. Every distributed variable has a separate counter associated with the value of the distributed variable. Whenever the distributed variable is updated, the counter value is also updated. The counter associated with a value can be used to identify the time of setting the value. The following common steps of this synchronization method are then performed: (1) For each distributed variable stored in multiple devices, a counter is initialized (for example: initial value is zero); therefore, a pair <value, counter> is stored as the data of the distributed variable in every related device;

(2) Every time the distributed variable is to be updated, a query of all devices in the network will be performed; and from obtained <value, counter> pairs, the pair corresponding to the biggest counter value is treated as the latest update; the biggest counter is increased, and the new pair <new value, biggest_counter+l> is used to update all related devices in the network;

(3) Every time the value of the distributed variable is to be retrieved, a query of all devices in the network will also be performed; and from obtained <value, counter> pairs, the pair corresponding to the biggest counter value is treated as the latest update, and the corresponding value will be returned as the retrieval result.

All devices in the network need to be queried, not only for an update but also for a retrieval of a distributed variable which is stored in multiple devices in a network. This process requires much resource and is time-consuming, resulting in network congestion.

OBJECTAND SUMMARY OF THE INVENTION

It is an object of the invention to provide an improved method of exchanging data in a network including a sending device. To this end, a distributed variable is stored in a sending device, said distributed variable having a value and being associated with a time identifier indicating the time of setting said value, while the method according to the present invention comprises a step of attaching the value and the associated time identifier of said distributed variable to a broadcast/multicast message to be sent from said sending device.

A sending device comprising a unit for performing the above-mentioned attaching step is also provided. The unit for performing attaching step can be implemented for example by a microprocessor and a memory stored with an instruction code.

It is also an object of the invention to provide an improved method of exchanging data by a receiving device in a network including said receiving device and multiple sending devices.

To this end, a distributed variable is stored in each of said multiple sending devices, said distributed variable having a value and being associated with a time identifier indicating the time of setting said value, the corresponding distributed variable being attached, for each sending device, to a broadcast/multicast message to be sent by each sending device, said method comprising a step of receiving the broadcast/multicast messages so as to retrieve the values and the associated time identifiers of the distributed variable.

A receiving device comprising a unit for performing the above-mentioned receiving step so as to retrieve the values and the associated time identifiers of said distributed variable is also provided. The unit for performing receiving step and identifying step can also be implemented for example by a microprocessor and a memory stored with instruction codes.

It is also an object of the invention to provide a signal intended to be sent by a sending device in a network. To this end, a distributed variable is stored in said sending device, said distributed variable having a value and being associated with a time identifier indicating the time of setting said value, said signal comprising a first portion for storing a value and an associated time identifier of said distributed variable, and a second portion for storing a broadcast/multicast message to which said distributed variable is attached.

By attaching the distributed variable to a broadcast/multicast message which has to be sent anyway (because the message is already used for other purposes) by the sending device in the network, the distributed variable can be retrieved by the devices which need the value of this distributed variable. In this way, there is no need to query all the devices when a device applies for obtaining the value of this distributed variable. Since the value of said distributed variable is just attached to a broadcast/multicast message which has to be sent anyway by the multiple devices in the network, it can save some resource (some network bandwidth) as compared to sending a new message. For example, the data of the packet header, the trailer and the padding can be saved. Consequently, this precludes demands for resource and time-consuming aspects of the prior-art method.

A detailed explanation and other aspects of the invention will be given below.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects and features of the present invention will become more apparent from the following detailed description with reference to the accompanying drawings, in which:

FIGl shows an example of a network according to the present invention.

FIG.2 shows an example of a signal sent by a sending device according to the invention. FIG.3 shows an example of the message without attaching the distributed variable.

FIG.4 shows an example of the message with the distributed variable being attached.

FIG.5 shows another example of the message without attaching the distributed variable.

FIG.6 shows another example of the message with the distributed variable being attached.

DESCRIPTION OF EMBODIMENTS

According to one aspect of the present invention, a method of exchanging data in a network is provided. The network includes a sending device. A distributed variable is stored in this sending device. The distributed variable has a value and is associated with a time identifier indicating the time of setting this value.

The method comprises a step of attaching the value and the associated time identifier of the distributed variable to a broadcast/multicast message to be sent from the sending device.

The term "attaching" is herein understood to mean "piggybacking", in other words, the variable is added to an existing broadcast/multicast message carrying some information for other purposes and has to be periodically sent anyway by the device in the network. There is no new broadcast/multicast message created solely for sending the data of the distributed variable mentioned in the present invention.

The term "broadcast/multicast message" is herein understood to mean "broadcast message" or "multicast message". Both terms used in the invention have their common meaning in the field of network technology. "Broadcast message" is herein understood to mean that the message is sent to every device in a network. It is used when a piece of information actually needs communicating to everyone in the network.

"Multicast message" is herein understood to mean that the message is sent to a group of stations that meet a particular set of criteria. These stations are usually related to each other in some way, such as serving a common function, or being set up into a particular multicast group. (Note that one can also consider a broadcast message to be a special multicast case, wherein the group is "everyone".)

The time identifier may be a timestamp; it may also be a time counter. As mentioned in the background paragraph, the associated time identifier is used to indicate the time of setting the value of the distributed variable.

According to the present invention, the term "network" has its general meaning in the field of information technology. A network is a series of points or nodes or devices interconnected by communication paths. Networks can interconnect with other networks and contain sub-networks.

The most common topology of a network includes the bus, star, Token Ring, and mesh topologies. Networks can also be characterized in terms of spatial distance as local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), etc.

A network can also be characterized by the type of data transmission technology in use on it

(for example, a TCP/IP or Systems Network Architecture network); by the fact whether it carries voice, data, or both kinds of signals; by the usual nature of its connections (dial-up or switched, dedicated or non- switched, or virtual connections); and by the types of physical links (for example, optical fiber, coaxial cable, and Unshielded Twisted Pair).

The multiple devices according to the invention may be any devices that are capable of connecting to a network. For example, they may be a computer, a TV, a DVD, an audio system, a refrigerator, an air conditioner, etc.

As shown in FIGl illustrating a network comprising devices A-B-C-D-E, device A and device B are the sending devices which are capable of sending the information to the other devices in the network. First, both device A and device B store a distributed variable SV as the value of M and the counter of 0, expressed by SV (M, 0). In order to inform the value of the distributed variable to the devices in the network, the distributed variable SV (M, 0) is attached to an existing broadcast/multicast message to be sent by device A and device B, and as the message will be sent periodically, the distributed variable SV is thus also sent periodically.

When device A is offline at the time of updating the distributed variable by a device in the network, for example, by device B, only the value stored in device B is updated. Device B stores the updated distributed variable SV as the value of N and the counter of 1, expressed by SV (N, 1).

At a later stage, when device A is online again, the distributed variable SV (N, 1) is attached to the same existing broadcast/multicast message to be sent by device B. As a result, the message having the distributed variable SV (M, 1) and the message having the distributed variable SV (N, 1) is sent by device A and device B separately.

A distributed variable will hereinafter be used as an example to illustrate the principle of the invention. For example, there is a distributed variable indicating a preferred policy holder in a Quality of Service system defined in some home network standards, e.g. UPnP, IGRS, etc. This distributed variable is referred to as "PreferredQphld".

There are three services defined in the QoS system in UPnP/IGRS: "QosPolicyHolder service" (QPH for short) to store all policies so as to regulate the traffic streams; "QosManager service" (QM for short) to manage the traffic stream setup in the path from source device to sink device; "QosDevice service" (QD for short) to manage QoS provisions of each QoS-enabled physical device.

There are various QPHs in the IGRS network. These QPHs are provided by different vendors, and there are slight differences of policy inside each QPH. A user is allowed to select a QPH in the network as the preferred QPH, and after this selection, QoS setup and traffic policy will follow the policy defined by the "preferred QPH". In this example, the "preferred QPH" is deemed to be a distributed variable.

The "preferred QPH" is stored in multiple QDs in the network. Each QD stores the "preferred

QPH" via a value pair <PreferredQphId, QphPreferenceCount>, wherein "PreferredQphld" is the Service Identifier (i.e. the value) of "preferred QPH", and "QphPreferenceCount" is the time identifier using the synchronization method as described in the background paragraph. In this embodiment, the pair <PreferredQphId, QphPreferenceCount> is attached to a broadcast/multicast message as the data of the distributed variable "preferred QPH".

According to the invention, the broadcast/multicast message may be any type of message which has to be broadcast or multicast periodically in the network. As an example, the message informing the other devices in the network that the device is online is used to illustrate the principle of the invention. This message is referred to as the "device online advertisement message" or "alive message" and is represented by "ssdp:alive" in the UPnP/IGRS network. The "alive message" is multicast to the network periodically. According to one embodiment of the present invention, the data of the distributed variable "preferred QPH" (i.e. <PreferredQphId, QphPreferenceCount> pair) is attached to the "alive message", and the "preferred QPH" can therefore be broadcast/multicast periodically together with the "alive message".

To attach the related data of "preferred QPH", two fields "PreferredQphld: xxxxxx" and "QphPreferenceCount: xxxxxx" are added to "alive message".

Some examples of how to implement the step of attaching the distributed variable to a broadcast/multicast message are given below. There are various formats of the broadcast/multicast message based on different protocols.

For the message with the format requiring each field to be separated by a common delimiter, the attaching step is simply implemented by appending two extra fields in the tail of original data: one field for the distributed variable value information, the other field for time identifier information.

An example of such a format is a message using HTTP (short for Hyper Text Transfer Protocol) over UDP (short for User Datagram Protocol). Each field of the HTTP protocol (named HTTP header) is separated by CRLF (defined as two ASCII characters "\r\n"). The attaching step according to this embodiment is simply implemented by appending two extra HTTP headers. The "alive message" defined in some network standards is one example based on HTTP over UDP.

FIG.3 shows the format of the original "alive message" without attaching the data of the distributed variable.

FIG.4 shows the format of the "alive message" after attaching the distributed variable. In IGRS QoS, the distributed variable "preferred QPH" is represented by "PreferredQphld" and its related time identifier is represented by "QphPreferenceCount". According to this embodiment, the two fields for "PreferredQphld" and "QphPreferenceCount" are attached in the "alive message" so as to reduce the variable query-response messages.

As shown in FIG.4, "PreferredQphld" is the name of the distributed variable indicating the "preferred QPH", and its value is expressed in the field of the italicized "Service Identifier of Preferred QPH";. "QphPreferenceCount" is the name of the time identifier of the distributed variable "preferred QPH", and its value is expressed in the field of the italicized "QPH preference count value".

For the message with the format requiring each field not to be separated by a common delimiter, each field is controlled by a length field or offset field instead in another embodiment of the invention. The attaching step can be implemented by adding the value and the time identifier of the distributed variable with the related field length defined in the protocol data.

FIG 5 is another message format example. In this example, each field is controlled by a length field. As shown in FIG 5, the start byte is a version field. The next byte indicates how many fields there are in the data. In this example, a total number of n fields is defined.

FIG.6 shows the format after attaching the information of the distributed variable "preferred QPH". There are n+2 fields after attaching: one for the distributed variable "PreferredQphld", the other for its related time identifier "QphPreferenceCount". The next two bytes indicate the name and value of the length of field 1, respectively. The following bytes indicate field l's name and value with the afore-defined length. The left bytes follow the same rule. In this example, the "preferred QPH" and its related time identifier is attached to n+1 and n+2 fields, respectively.

As a further step of the invention, QM can monitor the bandwidth condition of the network if a network throughput monitoring means is provided; when the network flow is little, QM can also query all QD services in the network pro-actively so as to update its computed preferred

QPH. This is known as network congestion aware retrieval.

According to another aspect of the invention, a method of exchanging data in a network is provided. Said network includes a receiving device and multiple sending devices. A distributed variable is stored in each of these sending devices. The variable has a value and is associated with a time identifier indicating the time of setting this value. For each sending device, the corresponding distributed variable is attached to a broadcast/multicast message to be sent by each sending device. This method comprises a step of receiving the broadcast/multicast messages so as to retrieve the values and the associated time identifiers of the distributed variable.

In this way, any receiving device in the network that is interested in this distributed variable can intercept the messages and keep track of the latest value of the distributed variable being attached to the message.

The "preferred QPH" and the "alive message" in the QoS system of IGRS network are used as examples of illustrating the principle of the invention.

As mentioned above, the "preferred QPH" is attached to the "alive message", when an application or device needs to obtain the value of the "preferred QPH", QM receives QD 's

"ssdp:alive" messages, the "PreferredQphld" and "QphPreferenceCount" are collected for each QD; the maximum "QphPreferenceCount" is identified, and the "PreferredQphld" having the maximum "QphPreferenceCount" is deemed to be the updated "preferred QPH" to perform subsequent QoS operations.

A synchronization error occurs if the multiple "PreferredQphld" has a different value with the same maximum "QphPreferenceCount". For example, when the "preferred QPH" is updated and a device P with a "preferred QPH" value having a maximum time identifier is not online, this error happens because only a device Q with a "preferred QPH" value having a maximum- 1 time identifier is found, and this maximum- 1 is then deemed to be the maximum time identifier and is updated to the maximum number with a new value. When both the device P and the device Q are online, there are two different values with the same maximum time identifier.

If a synchronization error occurs, or when the QPH determined by the distributed variable "preferred QPH" in the network is not online, the invention proposes the following steps of selecting a QPH from multiple QPH candidates.

Stepl: Find all QPH candidates alive in the network, and obtain UDN of the physical device in which each QPH candidate is located;

Step 2: Find the minimum value of UDN in the list obtained in step 1;

Step3: Select the QPH service with the minimum UDN to retrieve QoS policy.

After receiving the messages and retrieving the values and the associated time identifiers of the distributed variable, the method further comprises a step of identifying, from the retrieved values, the value being associated with a time identifier indicating the latest time.

According to another aspect of the invention, a sending device for exchanging data in a network is provided. A distributed variable is stored in this sending device; the distributed variable has a value and is associated with a time identifier indicating the time of setting this value; the sending device comprises a unit for performing the above-mentioned attaching step.

According to another aspect of the present invention, a receiving device for exchanging data in a network is also provided. This network includes the receiving device and multiple sending devices. A distributed variable is stored in each of these multiple sending devices, while the distributed variable has a value and is associated with a time identifier indicating the time of setting this value. For each sending device, the corresponding distributed variable is attached to a broadcast/multicast message to be sent by each sending device. The receiving device comprises a unit for performing the above-mentioned receiving step.

Advantageously, the receiving device further comprises a unit for performing the above-mentioned identifying step.

According to another aspect of the invention, a signal intended to be sent by a sending device in a network is provided. A distributed variable is stored in this sending device. The distributed variable has a value and is associated with a time identifier indicating the time of setting this value. The signal comprises a first portion for storing a value and an associated time identifier of the distributed variable, and a second portion for storing a broadcast/multicast message to which this distributed variable is attached.

As shown in FIG.2, for example, the signal Sl, S2, S3..., Sn, is intended to be sent by a device periodically. Along time, all of these signals include two portions. The first portion is a distributed variable, and the second portion is a broadcast/multicast message. These signals may have different content regarding the value and the associated time identifier of the distributed variable because the variable may be updated along time. The data of the distributed variable in the signal is independent of the content of the message. It is to be understood that the description above has been given by way of example only and that it is very illustrative. The example cannot be deemed to be a restriction of the present invention.

There are numerous ways of implementing functions by means of items of hardware or software, or both. In this respect, the drawings are also very illustrative, each representing only one possible embodiment of the invention.

The remarks made hereinbefore demonstrate that the detailed description with reference to the drawings illustrates rather than limits the invention. There are numerous alternatives which fall within the scope of the appended claims. Any reference sign in a claim should not be construed as limiting the claim. Use of the verb "comprise" and its conjugations does not exclude the presence of elements or steps other than those stated in a claim. Use of the indefinite article "a" or "an" preceding an element or step does not exclude the presence of a plurality of such elements or steps.