消息交互的方法、裝置及系統與流程

2023-05-09 01:44:36 2

本發明涉及網際網路技術領域，尤其涉及一種消息交互的方法、裝置及系統。

背景技術：

隨著網際網路的飛速發展，大量網際網路應用隨之出現，關於網際網路應用的伺服器與客戶端的消息交互，主要有以下兩種模式：一種是客戶端主動向伺服器發起請求，伺服器接收到請求後返迴響應結果。一種是伺服器向客戶端主動推送消息。上述兩種消息交互的方式都存在一定的弊端，對於客戶端主動請求的模式，客戶端無法精準的獲知什麼時段是伺服器的訪問高峰期，因此會經常性的出現伺服器系統宕機或資源浪費的情況；對於伺服器主動推送消息的模式，會出現伺服器響應不及時，以及當客戶端未開機時還容易造成漏更新的客戶端的現象。

技術實現要素：

鑑於上述問題，本發明提供一種消息交互的方法、裝置及系統，用以解決現有的網際網路應用中客戶端與伺服器之間消息交互的方式效率低的問題。

為解決上述技術問題，第一方面，本發明提供了一種消息交互的方法，所述方法包括：

客戶端向伺服器發送請求後，獲取伺服器返回的請求的請求延時值；

根據所述請求延時值設置再次發送請求的延時等待時間；

當到達延時等待時間後，自動向所述伺服器發送請求。

可選的，所述獲取伺服器返回的請求的請求延時值包括：

接收伺服器返回的對應請求的響應包；

解析所述響應包從所述響應包中獲取所述請求延時值。

可選的，所述根據所述請求延時值設置再次發送請求的延時等待時間包括：

在獲取伺服器返回的請求的更新的請求延時值之後，根據所述更新的請求延時值設置再次發送請求的延時等待時間。

可選的，所述客戶端向伺服器發送請求包括：

在客戶端開啟或初始化後，自動向所述伺服器發送請求。

第二方面，本發明還提供了一種消息交互的方法，所述方法包括：

伺服器在接收客戶端發送的請求後，設置所述客戶端下次發送請求的請求延時值；

將請求延時值返回給對應的客戶端，以使客戶端根據所述請求延時值設置再次發送請求的延時等待時間，並在到達延時等待時間後，自動向所述伺服器發送請求。

可選的，將請求延時值返回給對應的客戶端，包括：

將請求延時值添加到對應客戶端的請求的響應包中；

將所述響應包返回給對應的客戶端。

可選的，所述方法進一步包括：

在再次接收到所述客戶端發送的請求後，重新設置請求延時值，得到更新的請求延時值；

將更新的請求延時值返回給對應的客戶端。

可選的，所述設置請求延時值包括：

根據伺服器更新服務數據的時間間隔以及需要請求對應服務數據的客戶端的數量，計算客戶端的請求延時值，以使在所述時間間隔內，對應的客戶端的請求可以均勻散列。

第三方面，本發明提供了一種消息交互的裝置，所述裝置包括：

獲取單元，用於客戶端向伺服器發送請求後，獲取伺服器返回的請求的請求延時值；

設置單元，用於根據所述請求延時值設置再次發送請求的延時等待時間；

發送單元，用於當到達延時等待時間後，自動向所述伺服器發送請求。

可選的，所述獲取單元包括：

接收模塊，用於接收伺服器返回的對應請求的響應包；

解析模塊，用於解析所述響應包從所述響應包中獲取所述請求延時值。

可選的，設置單元用於：

在獲取伺服器返回的請求的更新的請求延時值之後，根據所述更新的請求延時值設置再次發送請求的延時等待時間。

可選的，發送單元還用於：

在客戶端開啟或初始化後，自動向所述伺服器發送請求。

第四方面，本發明還提供了一種消息交互的裝置，所述裝置包括：

設置單元，用於伺服器在接收客戶端發送的請求後，設置所述客戶端下次發送請求的請求延時值；

返回單元，用於將請求延時值返回給對應的客戶端，以使客戶端根據所述請求延時值設置再次發送請求的延時等待時間，並在到達延時等待時間後，自動向所述伺服器發送請求。

可選的，返回單元包括：

添加模塊，用於將請求延時值添加到對應客戶端的請求的響應包中；

返回模塊，用於將所述響應包返回給對應的客戶端。

可選的，所述設置單元還用於：

在再次接收到所述客戶端發送的請求後，重新設置請求延時值，得到更新的請求延時值；

所述返回單元，還用於將更新的請求延時值返回給對應的客戶端。

可選的，所述設置單元用於：

根據伺服器更新服務數據的時間間隔以及需要請求對應服務數據的客戶端的數量，計算客戶端的請求延時值，以使在所述時間間隔內，對應的客戶端的請求可以均勻散列。

第五方面，本發明提供了一種消息交互的系統，所述系統包括客戶端與伺服器：

所述客戶端，用於向伺服器發送請求後，獲取伺服器返回的請求的請求延時值；根據所述請求延時值設置再次發送請求的延時等待時間；當到達延時等待時間後，自動向所述伺服器發送請求；

所述伺服器，用於在接收客戶端發送的請求後，設置所述客戶端下次發送請求的請求延時值；將請求延時值返回給對應的客戶端。

藉由上述技術方案，本發明提供的消息交互的方法、裝置及系統，在客戶端向伺服器發送請求，在再次向伺服器發送請求時是根據伺服器返回的請求延時值進行的，相當於伺服器統籌安排不同的客戶端發送請求的間隔時間，因此可以降低伺服器峰值負荷，另外，是由客戶端向伺服器主動發送請求，所以在一定程度相比於伺服器主動推送消息的模式提高了伺服器的及時響應性也可以避免漏更新的現象。

上述說明僅是本發明技術方案的概述，為了能夠更清楚了解本發明的技術手段，而可依照說明書的內容予以實施，並且為了讓本發明的上述和其它目的、特徵和優點能夠更明顯易懂，以下特舉本發明的具體實施方式。

附圖說明

通過閱讀下文優選實施方式的詳細描述，各種其他的優點和益處對於本領域普通技術人員將變得清楚明了。附圖僅用於示出優選實施方式的目的，而並不認為是對本發明的限制。而且在整個附圖中，用相同的參考符號表示相同的部件。在附圖中：

圖1示出了本發明實施例提供的一種消息交互的方法的流程圖；

圖2示出了本發明實施例提供的另一種消息交互的方法的流程圖；

圖3示出了本發明實施例提供的又一種消息交互的方法的流程圖；

圖4示出了本發明實施例提供的一種消息交互過程的示意圖；

圖5示出了本發明實施例提供的一種消息交互的裝置的組成框圖；

圖6示出了本發明實施例提供的另一種消息交互的裝置的組成框圖；

圖7示出了本發明實施例提供的又一種消息交互的裝置的組成框圖；

圖8示出了本發明實施例提供的再一種消息交互的裝置的組成框圖。

具體實施方式

下面將參照附圖更詳細地描述本公開的示例性實施例。雖然附圖中顯示了本公開的示例性實施例，然而應當理解，可以以各種形式實現本公開而不應被這裡闡述的實施例所限制。相反，提供這些實施例是為了能夠更透徹地理解本公開，並且能夠將本公開的範圍完整的傳達給本領域的技術人員。

為解決現有的網際網路應用中客戶端與伺服器之間消息交互的方式效率低的問題，本發明實施例提供了一種消息交互的方法，該方法應用於客戶端，如圖1所示，該方法包括：

101、客戶端向伺服器發送請求後，獲取伺服器返回的請求的請求延時值。

首先需要說明的是，本實施例主要適用於移動應用客戶端需要通過獲取伺服器中的更新數據進行更新的情況。為了防止客戶端漏更新的情況，本實施例採用主動發送請求的方式，當客戶端端向伺服器發送請求後，伺服器返回對應的響應結果。但是又為了防止同一時刻大量客戶端同時訪問的負荷達到峰值的情況，由伺服器來統籌所有的客戶端發送請求的時間。具體的是在向客戶端返迴響應結果時，向客戶端返回下次發送請求的請求延時值，合理安排所有客戶端的高效訪問，避免伺服器負荷峰值以及宕機，因此客戶單端每次發送請求後都會獲取到伺服器返回的請求延時值。請求延時值是由伺服器設置的。

102、根據請求延時值設置再次發送請求的延時等待時間。

客戶端獲設置延時發送機制，具體是根據獲取到的伺服器返回的請求延時值後需要設置再次發送請求的延時等待時間，再次發送請求的延時等待時間是在當前時間的基礎上增加請求延時值得到的。在請求延時等待的時間達到前內，客戶端始終處於等待狀態。

103、當到達延時等待時間後，自動向伺服器發送請求。

客戶端能夠監控當前時間，當到達延時等待時時，會觸發自動向伺服器發送請求。

另外，上述消息交互的方式不僅避免了伺服器的負荷峰值以及宕機，也可以有效的平衡現有中伺服器被請求過程中經常出現的請求峰值時段與空閒時段的極端情況。

本發明實施例提供的消息交互的方法，在客戶端向伺服器發送請求之後，再次向伺服器發送請求時是根據伺服器返回的請求延時值進行的，相當於伺服器統籌安排不同的客戶端發送請求的間隔時間，因此可以降低伺服器峰值負荷，另外，是由客戶端向伺服器主動發送請求，所以在一定程度相比於伺服器主動推送消息的模式提高了伺服器的及時響應性也可以避免漏更新的現象。

本發明實施例還提供了一種消息交互的方法，如圖2所示，該方法應用於伺服器，該方法包括：

201、伺服器在接收客戶端發送的請求後，設置客戶端下次發送請求的請求延時值。

每個伺服器對應大量的客戶端，為了避免大量的客戶端同時請求伺服器使伺服器出現系統宕機等情況，需要合理的安排對客戶端的響應。本實施例中是通過請求延時值來錯開同一時間大量客戶端同時請求伺服器。具體的請求延時值的設置方式為：根據接收請求的不同時間段或請求對應的客戶端的不同類型設置不同的請求延時值，不同的時間段可以自由設定，比如不同時間段可以指一天之中的不同時段，也可以為一個小時中的不同時段，或者一周中的不同天等等。不同類型的客戶端可以為屬於不同優先等級的客戶端或者屬於不同網間協議IP位址的客戶端等。關於根據不同的時間段設置不同的請求延時值的方法，給出具體的示例進行說明：假設不同時間段為一天中的不同時段，若將一天分為8:00-12:00、12:00-22:00以及22:00-8:00三個不同的時段，在設置請求延時值可以將8:00-12:00接收到的請求對應的客戶端的請求延時值設為第一請求延時值，將12:00-22:00接收到的請求對應的客戶端的請求延時值設為第二請求延時值，將22:00-8:00接收到的請求對應的客戶端的請求延時值設為第三請求延時值，其中第一請求延時值、第二請求延時值以及第三請求延時值各不相同。關於不同類型的客戶端設置不同的請求延時值的方法，給出具體的示例進行說明，假設每個客戶端對應一個帳戶，不同的帳戶的優先等級不同，對於優先等級較高的客戶端設置的請求延時值可以相對較小，對於優先等級較高的客戶端設置的請求延時值可以相對較大。另外，需要說明的是，上述兩種根據不同時間段以及根據不同的客戶端類型進行設置請求延時值的方式可以結合使用。比如，在每一個時間段中可以再根據客戶端的類型設置不同的請求延時值。

202、將請求延時值返回給對應的客戶端。

在向客戶端返回對應請求的響應結果的同時也將請求延時值返回給對應的客戶端，以使客戶端根據請求延時值設置再次發送請求的延時等待時間，並在到達延時等待時間後，自動向伺服器再次發送請求。

本發明實施例提供的消息交互的方法，伺服器在接收客戶端發送的請求後，再次接收客戶端的請求的時間是由伺服器設置的請求延時值控制的，相當於伺服器統籌安排不同的客戶端發送請求的間隔時間，因此可以降低伺服器峰值負荷，另外，是由客戶端向伺服器主動發送請求，所以在一定程度相比於伺服器主動推送消息的模式提高了伺服器的及時響應性也可以避免漏更新的現象。

進一步的，對圖1以及圖2所示方法的細化及擴展，本實施例還提供了一種消息交互的方法，如圖3所示：

301、客戶端開啟或初始化後自動向所述伺服器發送請求。

為了防止客戶端在關閉的期間伺服器有數據更新，本實施例設置當客戶端開啟或初始化後自動向伺服器發送請求，這時的請求相當於首次請求，是沒有請求延時值的。

302、伺服器接收到請求後，根據伺服器更新服務數據的時間間隔以及需要請求對應服務數據的客戶端的數量，計算客戶端的請求延時值。

因為伺服器每次的更新伺服器數據都需要不遺漏的發送給每個對應的客戶端，因此需要以伺服器更新服務數據的時間間隔為基礎，然後根據需求更新伺服器數據的客戶端的數量來將在該時間間隔內，接收到的客戶端的請求是均勻分布的。具體可以通過抽取隨機數的方式實現。給出具體的示例進行說明，假設伺服器更新服務數據的時間段為上午8：00-12:00，需求獲取更新的服務數據的客戶端的數量為5萬個，那麼可以將4個小時的時間間隔平分成50個時間段，然後在為每個客戶端設置下次的請求時間時，隨機中50個時間段中為其選擇某一時間段，這樣可以保證最後5萬個客戶端的請求可以均勻的分布4個小時內，然後根據為客戶端選擇的時間段中的某一具體時間以及上次發送請求的時間的差值計算的得到對應客戶端的請求延時值。假如上述示例的5萬個客戶端中，為其中一個客戶端選擇的時間段為8:00:00-8:04:48，然後從8:00:00-8:04:48時段中選擇8:02為該客戶端下次發送請求的時間，假設伺服器接收到該客戶端請求的當前時間為7:30，那麼該向該客戶端返回的請求延時值為8:02與7:30之間的時間差值，即32分鐘。

303、伺服器將請求延時值添加在對應請求的響應包中返回給客戶端。

在計算得到請求延時值後，將請求延時值添加在請求對應的響應包的包頭或響應包的其他位置返回給客戶端。下面給出一種將請求延時值放在響應包包頭的示例，假設客戶端發送的請求為超文本傳輸協議(HyperText Transfer Protocol，HTTP)請求，則請求延時值添加的位置如下所示，其中TTL為請求延時值：

響應包：HTTP/1.1 200OK

Date:Sat,31Dec 2005 23:59:59GMT

Content-Type:text/html；charset＝ISO-8859-1

TTL:100000

304、客戶端對接收到的響應包進行解析獲取請求延時值。

客戶端在接收到請求對應的響應包後，除了解析得到響應結果之外，還需要對響應包解析獲取其中的請求延時值，具體的可以通過與伺服器約定的請求延時值的標識從響應包中提取。

305、客戶端根據請求延時值設置再次發送請求的延時等待時間。

根據獲取到的伺服器返回的請求延時值後需要設置再次發送請求的延時等待時間，再次發送請求的延時等待時間是在當前時間的基礎上在增加請求延時值得到的。在請求延時等待的時間達到前內，客戶端始終處於等待狀態。

306、當到達延時等待時間後，自動向所述伺服器發送請求。

客戶端在獲取請求延時值後自動監控當前時間，當到達延時等待時間後，會觸發自動向伺服器發送請求。

307、客戶端接收伺服器返回的更新的請求延時值，並根據更新的請求延時值設置再次發送請求的延時等待時間。

客戶端再次發送請求後，會接收到伺服器返回的更新的請求延時值，因為對於伺服器來講，每個時間段的負荷情況是不盡相同的，因此每次計算的客戶端的請求延時值也是不盡相同的。客戶端每次發送請求都會根據最新的請求延時值設置再次發送請求的延時等待時間。

308、當到達延時等待時間後，再次自動向所述伺服器發送請求。

為了更清晰直觀的描述上述圖3所示的消息交互的方法，給出對應的消息交互過程的示意圖，如圖4所示。從圖4中可以看到，在客戶端初始化或開啟時會向伺服器發送請求，之後每次向伺服器發起請求都需要根據伺服器返回的請求延時值等待，這樣可以由伺服器根據自身的負荷情況統籌的安排客戶端發起請求的時間。

進一步的，作為對上述各實施例的實現，本發明實施例的另一實施例還提供了一種消息交互的裝置，所述裝置位於客戶端側，用於實現上述圖1以及圖3中所述的方法。如圖5所示，該裝置包括：獲取單元41、設置單元42以及發送單元43。

獲取單元41，用於客戶端向伺服器發送請求後，獲取伺服器返回的請求的請求延時值；

首先需要說明的是，本實施例主要適用於移動應用客戶端需要通過獲取伺服器中的更新數據進行更新的情況。為了防止客戶端漏更新的情況，本實施例採用主動發送請求的方式，當客戶端端向伺服器發送請求後，伺服器返回對應的響應結果。但是又為了防止同一時刻大量客戶端同時訪問的負荷達到峰值的情況，由伺服器來統籌所有的客戶端發送請求的時間。具體的是在向客戶端返迴響應結果時，向客戶端返回下次發送請求的請求延時值，合理安排所有客戶端的高效訪問，避免伺服器負荷峰值以及宕機，因此客戶單端每次發送請求後都會獲取到伺服器返回的請求延時值。請求延時值是由伺服器設置的。

設置單元42，用於根據請求延時值設置再次發送請求的延時等待時間；

客戶端獲設置延時發送機制，具體是根據獲取到的伺服器返回的請求延時值後需要設置再次發送請求的延時等待時間，再次發送請求的延時等待時間是在當前時間的基礎上增加請求延時值得到的。在請求延時等待的時間達到前內，客戶端始終處於等待狀態。

發送單元43，用於當到達延時等待時間後，自動向伺服器發送請求。

客戶端能夠監控當前時間，當到達延時等待時時，會觸發自動向伺服器發送請求。

另外，上述消息交互的方式不僅避免了伺服器的負荷峰值以及宕機，也可以有效的平衡現有中伺服器被請求過程中經常出現的請求峰值時段與空閒時段的極端情況。

如圖6所示，獲取單元41包括：

接收模塊411，用於接收伺服器返回的對應請求的響應包；

解析模塊412，用於解析響應包從響應包中獲取請求延時值。

客戶端在接收到請求對應的響應包後，除了解析得到響應結果之外，還需要對響應包解析獲取其中的請求延時值，具體的可以通過與伺服器約定的請求延時值的標識從響應包中提取。

設置單元42用於：

在獲取伺服器返回的請求的更新的請求延時值之後，根據更新的請求延時值設置再次發送請求的延時等待時間。

發送單元43還用於：

在客戶端開啟或初始化後，自動向伺服器發送請求。

為了防止客戶端在關閉的期間伺服器有數據更新，本實施例設置當客戶端開啟或初始化後自動向伺服器發送請求，這時的請求相當於首次請求，是沒有請求延時值的。

本發明實施例提供的消息交互的裝置，在客戶端向伺服器發送請求，在再次向伺服器發送請求時是根據伺服器返回的請求延時值進行的，相當於伺服器統籌安排不同的客戶端發送請求的間隔時間，因此可以降低伺服器峰值負荷，另外，是由客戶端向伺服器主動發送請求，所以在一定程度相比於伺服器主動推送消息的模式提高了伺服器的及時響應性也可以避免漏更新的現象。

本發明實施例的另一實施例還提供了一種消息交互的裝置，所述裝置位於伺服器側，用於實現上述圖2以及圖3中所述的方法。如圖7所示，該裝置包括：設置單元51以及返回單元52。

設置單元51，用於伺服器在接收客戶端發送的請求後，設置客戶端下次發送請求的請求延時值；

每個伺服器對應大量的客戶端，為了避免伺服器大量的客戶端同時請求伺服器使伺服器出現系統宕機等情況，需要合理的安排對客戶端的響應。本實施例中是通過請求延時值來錯開同一時間大量客戶端同時請求伺服器。具體的請求延時值的設置方式為：根據接收請求的不同時間段或請求對應的客戶端的不同類型設置不同的請求延時值，不同的時間段可以自由設定，比如不同時間段可以指一天之中的不同時段，也可以為一個小時中的不同時段，或者一周中的不同天等等。不同類型的客戶端可以為屬於不同優先等級的客戶端或者屬於不同網間協議IP位址的客戶端等。

另外，需要說明的是，上述兩種根據不同時間段以及根據不同的客戶端類型進行設置請求延時值的方式可以結合使用。比如，在每一個時間段中可以再根據客戶端的類型設置不同的請求延時值。

返回單元52，用於將請求延時值返回給對應的客戶端，以使客戶端根據請求延時值設置再次發送請求的延時等待時間，並在到達延時等待時間後，自動向伺服器發送請求。

在向客戶端返回對應請求的響應結果的同時也將請求延時值返回給對應的客戶端，以使客戶端根據請求延時值設置再次發送請求的延時等待時間，並在到達延時等待時間後，自動向伺服器再次發送請求。

如圖8所示，返回單元52包括：

添加模塊521，用於將請求延時值添加到對應客戶端的請求的響應包中；

返回模塊522，用於將響應包返回給對應的客戶端。

將請求延時值添加在請求對應的響應包的包頭或響應包的其他位置返回給客戶端。下面給出一種將請求延時值放在響應包包頭的示例，假設客戶端發送的請求為HTTP請求，則請求延時值添加的位置如下所示，其中TTL為請求延時值：

響應包：HTTP/1.1 200OK

Date:Sat,31Dec 2005 23:59:59GMT

Content-Type:text/html；charset＝ISO-8859-1

TTL:100000

設置單元51還用於：

在再次接收到客戶端發送的請求後，重新設置請求延時值，得到更新的請求延時值；

返回單元52，還用於將更新的請求延時值返回給對應的客戶端。

設置單元51還用於：

根據伺服器更新服務數據的時間間隔以及需要請求對應服務數據的客戶端的數量，計算客戶端的請求延時值，以使在所述時間間隔內，對應的客戶端的請求可以均勻散列。

因為伺服器每次的更新伺服器數據都需要不遺漏的發送給每個對應的客戶端，因此需要以伺服器更新服務數據的時間間隔為基礎，然後根據需求更新伺服器數據的客戶端的數量來將在該時間間隔內，接收到的客戶端的請求是均勻分布的。具體可以通過抽取隨機數的方式實現。給出具體的示例進行說明，假設伺服器更新服務數據的時間段為上午8：00-12:00，需求獲取更新的服務數據的客戶端的數量為5萬個，那麼可以將4個小時的時間間隔平分成50個時間段，然後在為每個客戶端設置下次的請求時間時，隨機中50個時間段中為其選擇某一時間段，這樣可以保證最後5萬個客戶端的請求可以均勻的分布4個小時內，然後根據為客戶端選擇的時間段中的某一具體時間以及上次發送請求的時間的差值計算的得到對應客戶端的請求延時值。

本發明實施例提供的消息交互的裝置，伺服器在接收客戶端發送的請求後，再次接收客戶端的請求的時間是由伺服器設置的請求延時值控制的，相當於伺服器統籌安排不同的客戶端發送請求的間隔時間，因此可以降低伺服器峰值負荷，另外，是由客戶端向伺服器主動發送請求，所以在一定程度相比於伺服器主動推送消息的模式提高了伺服器的及時響應性也可以避免漏更新的現象。

進一步的，本發明的最後一個實施例還提供了一種消息交互的系統，用以實現圖1、圖2以及圖3所示的方法。本系統實施例與前述方法實施例對應，能夠實現前述方法實施例中的全部內容。為便於閱讀，本系統實施例僅對前述方法實施例中的內容進行概要性描述，不對方法實施例中的細節內容進行逐一贅述。該系統包括客戶端以及伺服器，其中，客戶端包括上述圖5或圖6所示的裝置，所述伺服器包括上述圖7或圖8所示的裝置。具體的：

客戶端，用於向伺服器發送請求後，獲取伺服器返回的請求的請求延時值；根據請求延時值設置再次發送請求的延時等待時間；當到達延時等待時間後，自動向伺服器發送請求；

伺服器，用於在接收客戶端發送的請求後，設置客戶端下次發送請求的請求延時值；將請求延時值返回給對應的客戶端。

本發明實施例提供的消息交互的系統，在客戶端向伺服器發送請求，在再次向伺服器發送請求時是根據伺服器返回的請求延時值進行的，相當於伺服器統籌安排不同的客戶端發送請求的間隔時間，因此可以降低伺服器峰值負荷，另外，是由客戶端向伺服器主動發送請求，所以在一定程度相比於伺服器主動推送消息的模式提高了伺服器的及時響應性也可以避免漏更新的現象。

在上述實施例中，對各個實施例的描述都各有側重，某個實施例中沒有詳述的部分，可以參見其他實施例的相關描述。

可以理解的是，上述方法及裝置中的相關特徵可以相互參考。另外，上述實施例中的「第一」、「第二」等是用於區分各實施例，而並不代表各實施例的優劣。

所屬領域的技術人員可以清楚地了解到，為描述的方便和簡潔，上述描述的系統，裝置和單元的具體工作過程，可以參考前述方法實施例中的對應過程，在此不再贅述。

在此提供的算法和顯示不與任何特定計算機、虛擬系統或者其它設備固有相關。各種通用系統也可以與基於在此的示教一起使用。根據上面的描述，構造這類系統所要求的結構是顯而易見的。此外，本發明也不針對任何特定程式語言。應當明白，可以利用各種程式語言實現在此描述的本發明的內容，並且上面對特定語言所做的描述是為了披露本發明的最佳實施方式。

在此處所提供的說明書中，說明了大量具體細節。然而，能夠理解，本發明的實施例可以在沒有這些具體細節的情況下實踐。在一些實例中，並未詳細示出公知的方法、結構和技術，以便不模糊對本說明書的理解。

類似地，應當理解，為了精簡本公開並幫助理解各個發明方面中的一個或多個，在上面對本發明的示例性實施例的描述中，本發明的各個特徵有時被一起分組到單個實施例、圖、或者對其的描述中。然而，並不應將該公開的方法解釋成反映如下意圖：即所要求保護的本發明要求比在每個權利要求中所明確記載的特徵更多的特徵。更確切地說，如下面的權利要求書所反映的那樣，發明方面在於少於前面公開的單個實施例的所有特徵。因此，遵循具體實施方式的權利要求書由此明確地併入該具體實施方式，其中每個權利要求本身都作為本發明的單獨實施例。

本領域那些技術人員可以理解，可以對實施例中的設備中的模塊進行自適應性地改變並且把它們設置在與該實施例不同的一個或多個設備中。可以把實施例中的模塊或單元或組件組合成一個模塊或單元或組件，以及此外可以把它們分成多個子模塊或子單元或子組件。除了這樣的特徵和/或過程或者單元中的至少一些是相互排斥之外，可以採用任何組合對本說明書(包括伴隨的權利要求、摘要和附圖)中公開的所有特徵以及如此公開的任何方法或者設備的所有過程或單元進行組合。除非另外明確陳述，本說明書(包括伴隨的權利要求、摘要和附圖)中公開的每個特徵可以由提供相同、等同或相似目的的替代特徵來代替。

此外，本領域的技術人員能夠理解，儘管在此所述的一些實施例包括其它實施例中所包括的某些特徵而不是其它特徵，但是不同實施例的特徵的組合意味著處於本發明的範圍之內並且形成不同的實施例。例如，在下面的權利要求書中，所要求保護的實施例的任意之一都可以以任意的組合方式來使用。

本發明的各個部件實施例可以以硬體實現，或者以在一個或者多個處理器上運行的軟體模塊實現，或者以它們的組合實現。本領域的技術人員應當理解，可以在實踐中使用微處理器或者數位訊號處理器(DSP)來實現根據本發明實施例的發明名稱(如消息交互的裝置)中的一些或者全部部件的一些或者全部功能。本發明還可以實現為用於執行這裡所描述的方法的一部分或者全部的設備或者裝置程序(例如，電腦程式和電腦程式產品)。這樣的實現本發明的程序可以存儲在計算機可讀介質上，或者可以具有一個或者多個信號的形式。這樣的信號可以從網際網路網站上下載得到，或者在載體信號上提供，或者以任何其他形式提供。

應該注意的是上述實施例對本發明進行說明而不是對本發明進行限制，並且本領域技術人員在不脫離所附權利要求的範圍的情況下可設計出替換實施例。在權利要求中，不應將位於括號之間的任何參考符號構造成對權利要求的限制。單詞「包含」不排除存在未列在權利要求中的元件或步驟。位於元件之前的單詞「一」或「一個」不排除存在多個這樣的元件。本發明可以藉助於包括有若干不同元件的硬體以及藉助於適當編程的計算機來實現。在列舉了若干裝置的單元權利要求中，這些裝置中的若干個可以是通過同一個硬體項來具體體現。單詞第一、第二、以及第三等的使用不表示任何順序。可將這些單詞解釋為名稱。