CN1805450A - 在域名系统dns机制中实现服务器与客户端数据同步的方法 - Google Patents

Abstract

本发明公开了一种在DNS机制中实现服务器与客户端数据同步的方法，该方法包括：A.服务器判断是否有数据更新，若有数据更新，则服务器向客户端发出数据已更新的通知消息，利用消息中的字段信息标识该消息为通知消息；B.客户端根据接收到的所述数据已更新的通知消息中的字段信息，更新本地缓存区记录。这样，客户端可以根据自身需求，删除缓存区的相应记录，或在需要使用该记录时，重新向服务器请求已更新的记录；本发明还允许客户端根据服务器的通知消息中携带的更新记录，将缓存区的记录直接更新，以便下次使用。本发明方法简单、灵活，很好地保持了服务器与客户端之间的数据同步，保证了客户端的正常工作。

Description

在域名系统DNS机制中实现服务器与客户端数据同步的方法

技术领域

本发明涉及域名系统(DNS)机制维护技术，尤指一种在DNS机制中实现服务器与客户端之间相关联资源数据同步的方法。

背景技术

目前，在DNS机制中，服务器与服务器之间的数据同步是通过协议规定的Notify消息来实现的，比如主服务器上的域文件更新后，主服务器会主动向从服务器发送Notify消息通知从服务器该域文件已被更新过。这样能保持主服务器与从服务器之间的数据同步。

而在服务器与客户端之间没有这样的同步机制来保证服务器与客户端之间的数据一致，这里所说的数据，是指客户端根据服务器与客户端之间协商好的某识别信息，客户端向服务器请求与该识别信息相关联的存储在服务器的数据资源，这种数据也可以称为记录。目前，服务器与客户端之间的数据交互过程是这样的：客户端向服务器发出查询记录请求后，服务器如果查询到客户端记录请求中的记录，则服务器会在向客户端返回的响应消息中写入该记录的生存期(TTL)值，以标识该记录的有效期。而为了提高查询的效率，客户端一般会将查询到的记录存入自身的缓存区，当下次需要用到该记录时，且此时该记录仍然处于有效期内，客户端不必向服务器再次请求，直接使用存储在缓存区且处于有效期内的该记录即可。

但是，如果存储在客户端缓存区的记录还在有效期内，而服务器对应的该记录的内容发生了变化，那么，客户端此时如果使用该记录，无疑会使用无效记录，从而会造成客户端不能正常工作，即会导致业务运行的失败；对于这点，可以通过将TTL值设置得比较短来避免，但无疑又不能保证客户端的查询效率。

比如，电话号码映射(ENUM)就是利用DNS机制来查询命名权威指针记录(NAPTR)的。NAPTR记录中可能包括用户的手机号、用户固定电话号码、用户各种终端信息等。在ENUM的应用中需要在Internet中查询用户的信息，而电信业务中对实时性的要求比较高，缓存就显得尤为必要。这时就有一个矛盾，如果记录中的TTL过小，缓存很快过期，记录会失效，无法减少查询量；如果TTL过大，当服务器中的记录更新后，客户端在记录有效期内会继续使用原有记录，这样会导致业务运行的失败。

从上述来看，服务器与客户端之间的数据不同步已经成为一个问题，影响到了客户端业务的正常运行。

发明内容

有鉴于此，本发明的主要目的在于提供一种DNS机制中实现服务器与客户端数据同步的方法，该方法简单、灵活，能够保持服务器与客户端之间的数据同步，从而保证客户端的正常工作。

为达到上述目的，本发明的技术方案具体是这样实现的：一种在域名系统DNS机制中实现服务器与客户端数据同步的方法，该方法包括：

A.服务器判断是否有数据更新，若有数据更新，则服务器向客户端发出数据已更新的通知消息，利用消息中的字段信息标识该消息为通知消息；

B.客户端根据接收到的所述数据已更新的通知消息中的字段信息，更新本地缓存区记录。

所述数据已更新的通知消息是用于保持服务器之间数据同步的Notify消息；

所述Notify消息至少使用了用于判断该消息是否合法的确认字段和用于判断客户端已存储的记录是否需要更新的识别字段。

步骤B所述客户端接收到所述数据已更新的通知消息和处理本地缓存区记录之间，该方法进一步包括：客户端根据Notify消息中的确认字段判断接收到的通知消息是否合法，

若合法，客户端将所述Notify消息中识别字段的内容转换成客户端对应的识别信息并根据所述识别信息查询客户端缓存区是否存储有对应该识别信息的记录，若有，则处理本地缓存区记录；否则，结束；

若不合法，则结束。

客户端判断所述通知消息不合法和在结束之前，该方法还包括：

丢弃该通知消息；

或在通知消息的确认字段中携带错误码后将该消息返回服务器。

当所述消息中未携带服务器更新记录的信息域时，步骤B所述更新本地缓存区记录的方法包括：

客户端将所述Notify消息中识别字段的内容转换成客户端对应的识别信息并根据所述识别信息删除缓存区对应的记录；

在客户端需要使用所述记录时，根据识别字段向服务器发出查询记录请求来更新该记录。

当所述消息中携带有服务器更新记录的信息域时，步骤B所述更新本地缓存区记录的方法包括：

客户端将所述Notify消息中识别字段的内容转换成客户端对应的识别信息并根据所述识别信息删除缓存区对应的记录，然后将所述信息域的内容存储在的本地。

所述服务器判断是否有数据更新的方法：

服务器根据是否接收到其它服务器下发的记录更新Notify消息来判断是否有数据更新，若收到其它服务器下发的记录更新Notify消息，则判断有数据更新；否则，判断无数据更新；

或服务器自身系统发生更新，若系统发生更新，则判断有数据更新；否则，判断无数据更新。

由上述技术方案可见，本发明在服务器发生数据更新后，服务器主动向客户端发出数据已更新的通知消息，客户端接收服务器发送来的数据已更新的通知消息。这样，客户端可以根据通知消息，按照自身需求，删除缓存区的相应记录，然后在需要使用该记录时，重新向服务器请求已更新的记录；本发明还允许客户端根据服务器下发的数据已更新的通知消息，将缓存区的记录直接更新，以便下次使用。本发明方法简单、灵活，很好地保持了服务器与客户端之间的数据同步，保证了客户端的正常工作。

附图说明

图1是本发明流程图；

图2是本发明在ENUM中应用的流程图。

具体实施方式

本发明的核心思想是：当服务器有数据更新时，服务器会主动向客户端发出数据已更新的通知消息，客户端接收服务器发送来的数据已更新的通知消息，并根据该消息中的字段信息，更新客户端缓存区记录。

为使本发明的目的、技术方案及优点更加清楚明白，以下参照附图并举较佳实施例，对本发明进一步详细说明。

本发明方法步骤如下：

步骤100：服务器判断自身是否有数据更新，若有数据被更新，则进入步骤101；否则，返回步骤100。

本步骤中，服务器可以根据其它服务器是否向该服务器下发记录更新的Notify消息来判断是否有数据更新，若该服务器收到其它服务器下发的记录更新Notify消息后，会触发自身向客户端下发记录已更新的通知消息；也可以是在该服务器中的记录发生改变，比如管理员进行的更新或系统定时进行的更新触发向客户端下发通知消息。

步骤101：服务器向客户端发送数据已更新的通知消息。

本步骤中的通知消息，可以使用DNS机制中服务器之间使用的Notify消息，也可以使用服务器与客户端之间协商好消息格式及消息内容的消息作为通知消息。

通知消息中除了携带消息的性质参数外，如请求后响应、是否是成功查询的消息等外，还应该携带对应服务器已更新记录的域名，或IP地址等。另外，该通知消息中还可以同时携带已更新的记录的内容。

步骤102：客户端根据服务器下发的通知消息中的字段信息处理本地缓存区记录。

这里所说的字段信息至少包括用于判断该通知消息是否合法的确认字段和用于判断客户端已存储的记录是否需要更新的识别字段，还可以包括用于存储服务器已更新数据的信息域。

在客户端根据确认字段判断该通知消息合法之后，客户端可以采用以下两种方法对缓存区记录进行处理：一种处理是，在通知消息中未携带已更新的记录的内容时，客户端删除该条记录后，在需要使用该记录时进一步向服务器请求新的记录；另一种处理是，在通知消息中携带了已更新的记录的内容时，客户端删除该条记录后将通知消息中携带的已更新的记录的内容存储到客户端即可使用。

下面以ENUM在DNS机制中应用为例，对本发明方法进行进一步描述：

在进行描述之前，先对实施例中使用到的现有Notify消息进行简单介绍：

Notify消息的格式如表1所示：

名称	含义
		Header	Notify消息头域部分
Question	Notify消息问题域部分
		Answe	Notify消息答案域部分
Authority	Notify消息权威域部分
		Additional	Notify消息附加域部分

                     表1

其中Header域部分的定义如表2所示：

字段名称	含义及要求
		ID	消息的标识，在一般的消息中是由客户端创建的。
QR	消息类型，表示该消息是请求时，QR＝0；表示该消息是响应时，QR＝1。
		Opcode	查询类型。例如是标准查询还是反向查询。服务器之间的Notify消息规定该值为4。
AA	在响应中，值为1表示该服务器是授权的名字服务器。在服务器之间的Notify消息中该字段要求置为1，表示对该查询是权威服务器答复的。本发明中建议当不强求值为1。
		TC	消息超长时，该位置1。
RD	值为1表示请求服务器完成递归查询。
		RA	当服务器完成了递归查询时，在响应中将该位置1。
Z	未使用。
		RCODE	表示查询结果。值为0表示查询成功，否则为对应的错误码。
QDCOUNT	Question域部分的条目个数。
		ANCOUNT	Answer域部分的条目个数。
NSCOUNT	Authority域部分的条目个数。
		ARCOUNT	Additional域部分的条目个数。

                            表2

其中，Question、Answer、Authority、Additional域至少包括NAME、TYPE和CLASS三个字段。比如，Question域包括QNAME、QTYPE、QCLASS三个字段，其中：QNAME为查询的域名；QTYPE为查询该域名中的类型，例如在服务器之间的Notify消息中，该值为6，表示为授权开始记录(SOA)；QCLASS为查询的网络类别，一般用于Internet，值为1。

图2是本发明在ENUM中应用的流程图，本发明ENUM在DNS机制中应用的步骤如下：

步骤200：服务器判断自身是否有数据更新，若有数据被更新，则进入步骤201；否则，返回步骤200。

步骤201：服务器向客户端发送数据已更新的通知消息。

本步骤中，假设服务器向客户端发送Notify消息通知客户端。消息内容如表3所示：

字段名称	含义及要求
		ID	本发明中Notify消息是由服务器发给客户端，所以在本发明中ID由服务器创建。
QR	QR＝0。
		Opcode	本发明中该值可为4；当然定义为其它值也可以，但应该是客户端与服务器之间的协商值。
AA	假设本实施例中该服务器是授权的名字服务器，AA＝1。
		TC	假设消息未超长，所以TC＝0。
RD	RD＝1。
		RA	当服务器完成了递归查询时，在响应中将该位置1。
Z	未使用。
		RCODE	假设该值为0。
QDCOUNT	该值为1。
		ANCOUNT	该值为0。
NSCOUNT	该值为0。
		ARCOUNT	该值为0。

                            表3

表3中QDCOUNT字段的值为1，说明Question域部分的条目个数为1，即该Question域有查询的域名QNAME；查询该域名中的类型QTYPE，本实施例是查询NAPTR记录，QTYPE对应的值为35。查询的网络类别QCLASS，本实施例是用于Internet，所以值为1。

步骤202：客户端接收到服务器发送的数据已更新的通知消息后，判断该通知消息是否合法，若合法，则进入步骤204；否则，进入步骤203。

本步骤中，通过对Notify消息中的确认字段进行检查来判断该通知消息是否合法。比如，QR字段，Opcode字段，RCODE字段，QTYPE字段。

其中，对QR字段的检查，若QR＝0，则表明是服务器向客户端发出的请求消息，是合法的，符合该通知消息的性质，即是服务器主动向客户端发出的请求消息；若QR＝1，则判断该通知消息不合法；

对Opcode字段的检查，若Opcode＝4，则判断该通知消息合法；否则，判断不合法。这里需要说明，Opcode的值可以是本实施例规定的值：4，也可以是服务器与客户端之间的协商值，该值只要满足不与现用的定义值冲突即可；

对RCODE字段的检查，若RCODE＝0，则表明服务器查询结果正确，也即判断该通知消息合法；若RCODE＝错误码，则判断该通知消息不合法；

对QTYPE字段的检查，判断QTYPE是否等于35，若等于，则判断该通知消息合法；否则，则判断该通知消息不合法。

步骤203：客户端在该通知消息的RCODE字段中携带错误码后，将该通知消息返回服务器。

本步骤中，客户端在判断服务器下发的通知消息不合法之后，返回一携带错误码的响应消息给服务器。

步骤204～步骤205：客户端将通知消息中识别字段的内容，如域名转换成客户端对应的识别信息，如E.164号码或号段，并根据E.164号码或号段判断查询客户端缓存区是否已存储了对应的记录，若有对应的记录，则将该记录删除；否则，进入步骤206。

本实施例中，Notify消息中的识别字段是QNAME字段，该字段中是以域名表示的E.164号码，通过QNAME字段中的域名，客户端查询缓存区是否已存储了该域名对应的记录。

假设服务器向客户端下发的Notify消息中，QNAME字段中的域名为1.2.3.4.5.6.7.8.9.6.8.e164.arpa.，则，该域名转换后对应的识别信息是E.164号码，为86987654321，客户端在本地查询与该号码对应的缓存区记录，若存在该记录，则将其删除。

QNAME字段中的内容也可以是一个号段，例如6.7.8.9.6.8.e164.arpa.，那么号码为869876xxxxx的缓存记录都将被删除。具体使用哪种方式，要依据该应用业务的需求而定。

另外QNAME字段中的内容还可以是IP地址、域名等。

步骤206：客户端丢弃该通知消息，结束此次对Notify消息的处理。

自此，服务器完成了在发生数据更新后，向客户端下发通知消息，客户端根据收到的通知消息，查询并删除相关记录。这样，保证了客户端使用缓存区记录的正确性。当客户端需要使用上述被删除的记录时，只需再次向服务器请求更新过的记录即可，保证了客户端的正常工作，同时也很好地保持了服务器与客户端之间的数据同步。

上述实施例的工作步骤中，客户端对服务器下发的通知消息，客户端只需接收该通知消息，也可达到本发明的目的；而无需进行判断是否合法、对通知消息进行转换处理并判断该通知消息对应的记录是否存储在本地、以及删除对应记录，同样客户端也不必在通知消息中写入错误码后将其返回给服务器，这些处理可以在客户端再次需要使用相关记录时，再根据已存储的通知消息做进一步处理即可。

当然，如果服务器在Notify消息中的信息域，如Answer域，或Authority域，或Additional域中写入了更新后的记录内容，那么，在客户端收到服务器下发的通知消息时，客户端可以将该通知消息存在本地，等到需要使用响应记录时，再根据该通知消息对记录进行更新，也可以在上述步骤204～步骤205中删除记录之后，进入步骤207。

步骤207：将携带在通知消息Answer域中的更新后的记录存储在本地。

本步骤中，更新后的记录可以携带于Answer域，或Authority域，或Additional域中。

本实施例中，假设更新后的记录携带于Answer域中。这样，客户端再次需要使用该条记录时，不需要再向服务器请求，而直接使用即可。无疑，本发明这样的处理，进一步提高了客户端的查询效率。

以上所述仅为本发明的较佳实施例，并非用于限定本发明的保护范围。

Claims (11)

1.一种在域名系统DNS机制中实现服务器与客户端数据同步的方法，其特征在于，该方法包括：

A.服务器判断是否有数据更新，若有数据更新，则服务器向客户端发出数据已更新的通知消息，利用消息中的字段信息标识该消息为通知消息；

B.客户端根据接收到的所述数据已更新的通知消息中的字段信息，更新本地缓存区记录。

2.根据权利要求1所述的方法，其特征在于，所述数据已更新的通知消息是用于保持服务器之间数据同步的Notify消息；

所述Notify消息至少使用了用于判断该消息是否合法的确认字段和用于判断客户端已存储的记录是否需要更新的识别字段。

3.根据权利要求2所述的方法，其特征在于，步骤B所述客户端接收到所述数据已更新的通知消息和更新本地缓存区记录之间，该方法进一步包括：客户端根据Notify消息中的确认字段判断接收到的通知消息是否合法，

若合法，客户端将所述Notify消息中识别字段的内容转换成客户端对应的识别信息并根据所述识别信息查询客户端缓存区是否存储有对应该识别信息的记录，若有，则处理本地缓存区记录；否则，结束；

若不合法，则结束。

4.根据权利要求3所述的方法，其特征在于，客户端判断所述通知消息不合法和在结束之前，该方法还包括：

丢弃该通知消息；

或在通知消息的确认字段中携带错误码后将该消息返回服务器。

5.根据权利要求3所述的方法，其特征在于，所述识别信息为号码或号段或域名。

6.根据权利要求3所述的方法，其特征在于，所述确认字段为Opcode字段和RCODE字段。

7.根据权利要求2所述的方法，其特征在于，所述识别字段为Question域的QNAME字段；所述识别字段的内容为：域名，或IP地址。

8.根据权利要求2所述的方法，其特征在于，当所述消息中未携带服务器更新记录的信息域时，步骤B所述更新本地缓存区记录的方法包括：

客户端将所述Notify消息中识别字段的内容转换成客户端对应的识别信息并根据所述识别信息删除缓存区对应的记录；

在客户端需要使用所述记录时，根据识别字段向服务器发出查询记录请求来更新该记录。

9.根据权利要求2所述的方法，其特征在于，当所述消息中携带有服务器更新记录的信息域时，步骤B所述更新本地缓存区记录的方法包括：

客户端将所述Notify消息中识别字段的内容转换成客户端对应的识别信息并根据所述识别信息删除缓存区对应的记录，然后将所述信息域的内容存储在的本地。

10.根据权利要求8或9所述的方法，其特征在于，所述信息域为Answer域，或Authority域，或Additional域。

11.根据权利要求1所述的方法，其特征在于，所述服务器判断是否有数据更新的方法：

服务器根据是否接收到其它服务器下发的记录更新Notify消息来判断是否有数据更新，若收到其它服务器下发的记录更新Notify消息，则判断有数据更新；否则，判断无数据更新；

或服务器自身系统发生更新，若系统发生更新，则判断有数据更新；否则，判断无数据更新。

Images