專利名稱：一種通過dhcp傳送時區(qū)信息的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)通信技術(shù)領(lǐng)域，尤其涉及一種通過DHCP傳送時區(qū)信息的方法。
背景技術(shù)：
DHCP是Dynamic Host Configuration Protocol的縮寫，它提供了一種動態(tài)指定IP地址和配置參數(shù)的機制。
DHCP采用Client/Server模式，由客戶端向服務(wù)器提出配置申請(包括分配的IP地址、子網(wǎng)掩碼、缺省網(wǎng)關(guān)、時間信息等參數(shù))，服務(wù)器根據(jù)策略返回相應(yīng)配置信息，DHCP報文采用UDP進行封裝。
DHCPv4的工作過程如圖1所示1.發(fā)現(xiàn)階段，即DHCP客戶端尋找DHCP服務(wù)器的階段DHCP客戶端以廣播方式(因為DHCP服務(wù)器的IP地址對于DHCP客戶端來說是未知的)發(fā)送DHCPDiscover消息來尋找DHCP服務(wù)器；2.提供階段，即DHCP服務(wù)器提供IP地址的階段。在網(wǎng)絡(luò)中接收到DHCPDiscover消息的DHCP服務(wù)器都會做出響應(yīng)，它從尚未分配的IP地址中選擇一個分配給DHCP客戶端，向DHCP客戶端發(fā)送一個包含分配的IP地址和其他配置參數(shù)的DHCP Offer消息；
3.選擇階段，即DHCP客戶端選擇某個DHCP服務(wù)器提供的IP地址的階段。如果有多個DHCP服務(wù)器向DHCP客戶端發(fā)送DHCP Offer消息，則DHCP客戶端從接收到的DHCP Offer中選擇一個，即選定一個DHCP服務(wù)器。然后DHCP客戶端以廣播方式應(yīng)答一個DHCP Request消息，該消息中包含DHCP客戶端所選定的DHCP服務(wù)器的IP地址和該DHCP服務(wù)器提供的IP地址。之所以要以廣播方式應(yīng)答，是為了通知所有的DHCP服務(wù)器，它將選擇某個DHCP服務(wù)器所提供的IP地址；4.確認階段，即DHCP服務(wù)器確認所提供的IP地址的階段。當(dāng)DHCP服務(wù)器接收到DHCP客戶端的DHCP Request消息后，它便向DHCP客戶端發(fā)送一個包含它所提供的IP地址和其他配置參數(shù)的DHCP Ack消息，告訴DHCP客戶端可以使用它所提供的IP地址。另外，除DHCP客戶端選中的DHCP服務(wù)器外，其他的DHCP服務(wù)器都將回收曾提供的IP地址。
DHCP客戶端可以在DHCP Discover消息或者DHCP Request消息中包含Parameter Request List Option，向DHCP服務(wù)器請求自己感興趣的配置參數(shù)，Parameter Request List Option的格式如下描述CodeLenOption Codes C1、C2......為DHCP客戶端請求的option對應(yīng)的codeDHCP客戶端也可以在DHCP Discover消息或者DHCP Request消息中包含某個的Option，該Option中的值暗示DHCP服務(wù)器它希望獲取的值，DHCP服務(wù)器可以返回DHCP客戶端希望的值，也可以返回其他的值。
DHCPv6的工作過程類似于DHCPv4，但是DHCPv6是采用組播發(fā)送的，而不是廣播發(fā)送。大家用時區(qū)timezone來設(shè)置時區(qū)信息，時區(qū)格式有很多，下面僅給出三種常用的時區(qū)格式(1)POSIX TZ字符串POSIX TZ字符串提供了一種通過字符串表述時區(qū)信息的標(biāo)準，它的格式如下所描述stdoffset[dst[offset][，start[/time]，end[/time]]]例如”EST5EDT4，M4.1.1，M11.1.1”(2)TZ DatabaseTZ Database也叫“Olson Database”，該數(shù)據(jù)庫維護了全球的時區(qū)數(shù)據(jù)。這個數(shù)據(jù)庫是定時更新的。如果想從該數(shù)據(jù)庫中獲取時區(qū)信息，需要給出索引，即時區(qū)的名字，然后根據(jù)該索引從數(shù)據(jù)庫中查找。
例如“Europe/Zurich”(3)Microsoft時區(qū)Microsoft時區(qū)中包括了類似于POSIX TZ字符串的信息，但是一串可顯示的字符串。Microsoft時區(qū)也是一個數(shù)據(jù)庫，需要根據(jù)TZ ID從數(shù)據(jù)庫中查找這個字符串例如<pre listing-type="program-listing">＜時區(qū)ID="13" Name="(GMT-08:00)Pacific Time(US and Canada);Tijuana"Hidden="FALSE"＞ ＜Bias＞480＜/Bias＞＜StandardTime＞ ＜Bias＞0＜/Bias＞ ＜Date＞＜Month＞10＜/Month＞＜Day＞5＜/Day＞＜Hour＞2＜/Hour＞ </pre><pre listing-type="program-listing"> ＜/Date＞＜/StandardTime＞＜DaylightTime＞ ＜Bias＞-60＜/Bias＞ ＜Date＞＜Month＞4＜/Month＞＜Day＞1＜/Day＞＜Hour＞2＜/Hour＞ ＜/Date＞ ＜/DaylightTime＞＜/時區(qū)＞</pre>客戶端可以在啟動的時候，通過DHCP從DHCP服務(wù)器獲取時區(qū)信息。
已有技術(shù)一DHCPv4中提供了一個time offset option(option code＝2)，用于傳送UTC offset，DHCP客戶端根據(jù)該option提供的值，設(shè)定和格林威治時間的偏移時間，單位是秒。但是，因為只傳遞和格林威治時間的偏移時間，所以該option提供的是一個靜態(tài)的數(shù)據(jù)，對于某些應(yīng)用來說，這些信息是不夠的。例如DHCP客戶端無法根據(jù)該數(shù)據(jù)確定自己當(dāng)前所處的時區(qū)；在實行DST的地區(qū)或者國家，DHCP客戶端無法根據(jù)該數(shù)據(jù)卻動自己當(dāng)前是否處于DST，什么時候啟用DST以及什么時候哦退出DST等等。
已有技術(shù)二在DHCP消息中傳送完整的時區(qū)信息。這雖然解決了已有技術(shù)一的缺陷，但是，本方案存在DHCP服務(wù)器返回的時區(qū)信息的格式和DHCP客戶端支持的格式不兼容的問題。如何保證DHCP服務(wù)器返回的時區(qū)信息的格式和DHCP客戶端支持的格式統(tǒng)一，是已有技術(shù)二存在的最大問題；而且，如果DHCP客戶端請求TZDatabase格式或者Microsoft格式的時區(qū)信息時，DHCP服務(wù)器只能返回數(shù)據(jù)庫的索引，DHCP客戶端需要保存和更新時區(qū)數(shù)據(jù)庫，存在因為數(shù)據(jù)庫更新不及時而導(dǎo)致DHCP客戶端獲取的時區(qū)信息不準確的問題。

發(fā)明內(nèi)容
本發(fā)明解決的技術(shù)問題是提供一種通過DHCP傳送時區(qū)信息的方法，保證了DHCP服務(wù)器返回的時區(qū)信息和DHCP客戶端支持的時區(qū)信息相互統(tǒng)一。
本發(fā)明的目的是通過以下技術(shù)方案實現(xiàn)的一種通過DHCP傳送時區(qū)信息的方法，包括步驟A.動態(tài)主機配置協(xié)議DHCP客戶端向DHCP服務(wù)器發(fā)送請求消息，所述請求消息承載DHCP客戶端期望得到的時區(qū)信息；B.所述DHCP服務(wù)器收到所述消息，根據(jù)所述DHCP客戶端的期望返回時區(qū)信息。
其中，步驟A所述時區(qū)信息包括時區(qū)格式，時間信息元素或者其組合。
其中，所述時區(qū)格式包括POSIX TZ時區(qū)格式，TZ Database時區(qū)格式，Microsoft時區(qū)格式，以及其他的時區(qū)格式。
其中，所述時間信息元素包括標(biāo)準時區(qū)，夏令時區(qū)，與協(xié)調(diào)世界時UTC的偏移量，夏令時的開始時間和結(jié)束時間。
其中，步驟A所述DHCP客戶端期望獲取多個時區(qū)信息時，按照優(yōu)先順序逐一列出。
其中，步驟B中所述DHCP服務(wù)器根據(jù)DHCP客戶端的期望，返回時區(qū)信息給DHCP客戶端包括所述DHCP服務(wù)器只返回時間信息元素給DHCP客戶端；或者，所述DHCP服務(wù)器按照所述DHCP客戶端期望的時區(qū)格式返回時區(qū)信息；或者，所述DHCP服務(wù)器返回時間信息元素與時區(qū)格式的結(jié)合給DHCP客戶端。
其中，步驟B還包括
如果DHCP服務(wù)器不支持DHCP客戶端期望的時區(qū)信息，DHCP服務(wù)器根據(jù)配置或者返回缺省的時區(qū)信息，或者不返回時區(qū)信息。
其中，步驟B所述DHCP服務(wù)器返回的時區(qū)信息承載在所述DHCP服務(wù)器發(fā)送的應(yīng)答消息中。
其中，步驟B之后，DHCP客戶端收到所述來自DHCP服務(wù)器的時區(qū)信息，如果收到的是所述DHCP客戶端期望的時區(qū)信息，則DHCP客戶端直接使用，否則，DHCP客戶端轉(zhuǎn)換所述時區(qū)信息。
進而，本發(fā)明中DHCP服務(wù)器只發(fā)送時間信息元素給DHCP客戶端，而不是數(shù)據(jù)庫的索引，避免了因為DHCP客戶端保存和更新時區(qū)數(shù)據(jù)庫而引起的數(shù)據(jù)不同步的問題。
本發(fā)明通過采取協(xié)商機制，DHCP服務(wù)器返回時區(qū)信息之前，接收來自DHCP客戶端的時區(qū)信息請求，根據(jù)DHCP客戶端的期望，返回時區(qū)信息給DHCP客戶端，有效保證了DHCP服務(wù)器返回的信息和DHCP客戶端支持的信息相互統(tǒng)一。進而，本發(fā)明DHCP服務(wù)器發(fā)送時間信息元素給DHCP客戶端時，避免了因為DHCP客戶端保存和更新時區(qū)數(shù)據(jù)庫而引起的數(shù)據(jù)不同步的問題。


圖1為已有技術(shù)中DHCP工作過程示意圖；圖2為本發(fā)明實施例一中步驟1示意圖；圖3為本發(fā)明實施例一中步驟2示意圖；圖4為本發(fā)明實施例一中步驟2處理流程圖；圖5為本發(fā)明實施例一中步驟3示意圖；圖6為本發(fā)明實施例一中步驟4示意圖。
具體實施例方式
貫穿說明書，示出的該優(yōu)選實施例和示例應(yīng)被看作本發(fā)明的范例而不受限制。
DHCP客戶端向DHCP服務(wù)器發(fā)送的消息統(tǒng)稱為請求消息，DHCP服務(wù)器向DHCP客戶端發(fā)送的消息統(tǒng)稱為應(yīng)答消息。
DHCP客戶端對時區(qū)信息的請求，承載在向DHCP服務(wù)器發(fā)送的請求消息。DHCP服務(wù)器收到請求后，把DHCP客戶端期望的時區(qū)信息元素承載在應(yīng)答消息中Offer消息Ack消息。DHCP服務(wù)器無法滿足DHCP客戶端對時區(qū)信息的需求時，DHCP服務(wù)器或者根據(jù)配置選擇，或者返回缺省的時區(qū)信息，或者不返回時區(qū)信息。為了便于理解，我們?nèi)匀灰訢HCP的工作流程為主線闡述本發(fā)明的具體內(nèi)容。
實施例一步驟1發(fā)現(xiàn)階段如圖2所示，DHCP客戶端廣播發(fā)送DHCP Discover消息，同時DHCP客戶端可以請求獲取時區(qū)信息。
DHCP客戶端可以在DHCP Discover消息中包含parameter Request Listoption，在該option的code列表中可以包含時區(qū)option code，表明需要獲取時區(qū)信息，包括時區(qū)格式，時間信息元素或者其組合。其中時間信息元素包括標(biāo)準時區(qū)，夏令時區(qū)，與協(xié)調(diào)世界時UTC的偏移量，夏令時的開始時間和結(jié)束時間等。
DHCP客戶端期望獲取的時區(qū)信息有多個時，按照優(yōu)先順序在列表中逐一列出。
本步驟中DHCP客戶端請求獲取時區(qū)信息是可選的，也可以在步驟3中發(fā)送。
步驟2提供階段如圖3所示，DHCP服務(wù)器處理DHCP Discover消息，應(yīng)答DHCP Offer，返回時區(qū)信息。
步驟100如圖4所示，其中判斷DHCP Discover消息中是否承載了時區(qū)信息請求，如果沒有承載，跳轉(zhuǎn)到步驟400；步驟200判斷請求中是否有DHCP服務(wù)器支持的，如果沒有，跳轉(zhuǎn)到步驟400
步驟300如果有支持的話，DHCP服務(wù)器返回支持的時區(qū)信息；步驟400DHCP服務(wù)器根據(jù)配置返回缺省的時區(qū)信息，或者不返回時區(qū)信息。
步驟3選擇階段如圖5所示，DHCP客戶端處理DHCP Offer消息后，廣播發(fā)送DHCP Request，同時可以請求獲取時區(qū)信息。
在處理DHCP Offer時如果在DHCP Offer中返回了時區(qū)信息，則做如下處理如果返回的是自己期望的時區(qū)信息，則DHCP客戶端直接使用，否則，DHCP客戶端將DHCP Offer中提供的時區(qū)信息轉(zhuǎn)化成自己支持的DHCPv4協(xié)議規(guī)定了，如果在發(fā)現(xiàn)階段發(fā)送了Parameter Request ListOption，在選擇階段也必須發(fā)送Parameter Request List Option，當(dāng)然，如果在發(fā)現(xiàn)階段未發(fā)送Parameter Request List Option，在選擇階段是否發(fā)送Parameter Request List Option是可選的。所以，在發(fā)送DHCP選擇的時候，因為不發(fā)送時區(qū)請求的情況比較簡單，不再累述。發(fā)送時區(qū)請求的情況下，處理方法同步驟1。
步驟4確認階段如圖6所示，DHCP服務(wù)器處理DHCP Request消息，發(fā)送DHCP Ack消息，如果步驟3有時區(qū)信息請求，則返回時區(qū)的信息。
DHCP服務(wù)器在處理DHCP Request時，如果Request消息中承載了時區(qū)信息請求，其處理同步驟2，否則，按照DHCP的正常流程處理。
步驟5DHCP客戶端在處理DHCP Ack時，如果在DHCP Ack消息中返回了時區(qū)信息，則做如下處理如果返回的是自己期望的時區(qū)信息，則DHCP客戶端直接使用，否則，DHCP客戶端將DHCP響應(yīng)中提供的時區(qū)信息轉(zhuǎn)化成自己支持的。
如果DHCP客戶端沒有能力或者不愿意保存和更新數(shù)據(jù)庫，那么，它可以在請求的時候，給出期望獲取的時間信息元素，DHCP服務(wù)器可以根據(jù)DHCP客戶端的期望，返回具體的時間信息元素，而不是數(shù)據(jù)庫的索引。進而，避免了因為DHCP客戶端保存和更新時區(qū)數(shù)據(jù)庫而引起的數(shù)據(jù)不同步的問題。
本實施例中僅以DHCPv4為例，通過DHCPv6協(xié)議傳送時區(qū)信息也同理。
權(quán)利要求
1.一種通過DHCP傳送時區(qū)信息的方法，其特征在于，包括步驟A.動態(tài)主機配置協(xié)議DHCP客戶端向DHCP服務(wù)器發(fā)送請求消息，所述請求消息承載DHCP客戶端期望得到的時區(qū)信息；B.所述DHCP服務(wù)器收到所述消息，根據(jù)所述DHCP客戶端的期望返回時區(qū)信息。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟A所述時區(qū)信息包括時區(qū)格式、時間信息元素或者其組合。
3.根據(jù)權(quán)利要求2所述的方法，其特征在于，所述時區(qū)格式包括POSIXTZ時區(qū)格式、TZ Database時區(qū)格式和Microsoft時區(qū)格式。
4.根據(jù)權(quán)利要求2所述的方法，其特征在于，所述時間信息元素包括標(biāo)準時區(qū)、夏令時區(qū)、與協(xié)調(diào)世界時UTC的偏移量、夏令時的開始時間和夏令時的結(jié)束時間。
5.根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟A所述DHCP客戶端期望獲取多個時區(qū)信息時，按照優(yōu)先順序逐一列出。
6.根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟B中所述DHCP服務(wù)器根據(jù)DHCP客戶端的期望，返回時區(qū)信息給DHCP客戶端包括所述DHCP服務(wù)器只返回時間信息元素給DHCP客戶端；或者，所述DHCP服務(wù)器按照所述DHCP客戶端期望的時區(qū)格式返回時區(qū)信息；或者，所述DHCP服務(wù)器返回時間信息元素與時區(qū)格式的結(jié)合給DHCP客戶端。
7.根據(jù)權(quán)利要求1至6中任意一項所述的方法，其特征在于，步驟B還包括如果DHCP服務(wù)器不支持DHCP客戶端期望的時區(qū)信息，DHCP服務(wù)器根據(jù)配置或者返回缺省的時區(qū)信息，或者不返回時區(qū)信息。
8.根據(jù)權(quán)利要求6所述的方法，其特征在于，步驟B所述DHCP服務(wù)器返回的時區(qū)信息承載在所述DHCP服務(wù)器發(fā)送的應(yīng)答消息中。
9.根據(jù)權(quán)利要求7所述的方法，其特征在于，步驟B之后，DHCP客戶端收到所述來自DHCP服務(wù)器的時區(qū)信息，如果收到的是所述DHCP客戶端期望的時區(qū)信息，則DHCP客戶端直接使用，否則，DHCP客戶端轉(zhuǎn)換所述時區(qū)信息。
全文摘要
本發(fā)明公開了一種通過DHCP傳送時區(qū)信息的方法。動態(tài)主機配置協(xié)議DHCP客戶端向DHCP服務(wù)器發(fā)送消息，所述消息承載DHCP客戶端期望得到的時區(qū)信息；所述DHCP服務(wù)器收到所述消息，根據(jù)所述DHCP客戶端的期望，返回時區(qū)信息。本發(fā)明有效保證了DHCP服務(wù)器返回的格式和DHCP客戶端支持的格式相互統(tǒng)一。
文檔編號G06F1/14GK101043532SQ200610061238
公開日2007年9月26日 申請日期2006年6月20日 優(yōu)先權(quán)日2006年6月20日
發(fā)明者管紅光 申請人:華為技術(shù)有限公司