[發明專利]一種即時通信的方法、系統及服務器

有效

• 申請號: 201210062366.2
• 申請日: 2012-03-09
• 公開（公告）號: CN103312586B
• 公開（公告）日: 2017-06-27
• 發明（設計）人: 楊春龍;趙一方;張躍華
• 申請（專利權）人: 聯想（北京）有限公司
• 主分類號: H04L12/58
• 分類號: H04L12/58
• 代理公司: 北京同達信恒知識產權代理有限公司11291
• 代理人: 黃志華

技術領域

本發明涉及即時通信技術，更具體地說，涉及一種即時通信的方法、系統及服務器。

背景技術

隨著信息技術的迅猛的發展，SNS(Social Networking Service，社會化網絡服務)產品大為流行，聊天交友類系統則是此類產品中不可或缺的基本功能組件。鑒于現有的SNS產品多是基于瀏覽器的，因此，需要與之配合的基于瀏覽器的即時通信產品。然而，當前絕大多數即時通信產品(如QQ、MSN等)卻都是基于桌面的。鑒于HTTP協議自身的局限性，如非連接和無狀態特性等等，基于瀏覽器的即時通信產品的狀態管理比較困難。

傳統網頁即時通信系統信息交互模式，現有技術中一般都采用C/S(client/server，客戶端/服務器)架構形式，其中即時通信客戶端軟件安裝于用戶終端上，用于提供數據存儲、消息轉發、狀態保存等功能，而設置于網絡側的服務器用于提供輸入輸出、信息顯示、界面操作等功能。通過客戶端發出請求、服務器端響應的方式工作，這種方式并不能滿足很多現實應用的需求。即時通信系統需要服務器能實時地將更新的信息傳送到客戶端，而無需客戶端發出請求。

現有技術中，當前網頁即時通信系統的信息獲取有以下兩種模式：

第一、瀏覽器每隔一定時間請求服務器來獲取最新消息，這種模式稱之為輪詢；

第二、服務器維持與瀏覽器長時間的連接來傳遞數據，長連接的技術稱之為Comet連接。

在上述第一種模式中，客戶端以用戶可定義的時間間隔去檢查服務器上的最新數據，如此很容易就能發現輪詢方式的主要缺點是產生了大量的傳輸浪費。因為可能大部分向服務器的請求是無效的，也就是說，客戶端等待發生的事件沒有發生，如果有大量的客戶端的話，這種網絡傳輸的浪費是非常嚴重的。特別是對于服務器端很久才更新的應用程序來講，比如郵件程序，這種浪費就更是巨大了。并且，對服務器端處理請求的能力也相應提高了要求。如果很長時間才向服務器端發送一次請求的話，客戶端就不能的得到及時的響應。因此，這種方式要么導致較高的網絡流量(檢查頻率過高)，要么導致錯過更新的數據(檢查頻率過低)。

另一方面，如果使用Comet技術的話，雖然不存在輪詢模式的問題，但是，要求客戶端和服務器端必須保持一個長連接，一般情況下，服務器端每一個接口都會獨占一個線程，這樣就會使得服務器端有很多線程同時存在，在客戶端非常多的情況下，也會對服務器端的處理能力帶來很大的挑戰。

發明內容

本發明實施例提供一種即時通信的方法、系統及服務器，解決了在長連接模式中，對于客戶端非常多的情況下，服務器端有大量線程同時存在時影響服務器端處理能力的問題。

本發明實施例一方面提供一種即時通信的方法，包括以下步驟：

根據接收到的客戶端發送的建立長連接請求，建立與當前客戶端的長連接，并分配給所述當前客戶端對應的線程；

所述服務器端判斷是否存在所述當前客戶端的即時信息；

所述服務器端判斷是否存在所述當前客戶端的即時信息，如果不存在，則將當前客戶端建立的長連接掛起，并將發送建立長連接請求的下一客戶端作為當前客戶端；如果存在，則發送即時信息給對應客戶端；

其中，所述當前客戶端和所述下一客戶端使用同一線程。

優選的，所述將當前客戶端建立的長連接掛起，并將發送建立長連接請求的下一客戶端作為當前客戶端之后，該方法還包括：

當檢測到包含有掛起的客戶端的即時消息時，喚醒對應客戶端的長連接；

將檢測到的即時消息發送給對應的所述喚醒長連接的客戶端。

優選的，所述將檢測到的即時消息發送給對應的所述喚醒長連接的客戶端之后，該方法還包括：再掛起對應客戶端的長連接。

優選的，當檢測到包含有掛起的客戶端的即時消息時，喚醒對應客戶端的長連接之前，該方法還包括：

獲取即時消息，所述即時消息中攜帶有客戶端信息以及對應的當前位置對應的IP地址；

將獲取的即時消息保存到緩存中，并按照接收客戶端發送的建立長連接請求的先后順序，依次喚醒對應客戶端的長連接。

優選的，所述當檢測到包含有掛起的客戶端的即時消息時，喚醒對應客戶端的長連接，具體為：

解析獲取的即時消息中包含的所述客戶端當前位置對應的IP地址；

根據解析的IP地址，喚醒對應客戶端的長連接。

優選的，采用輪詢的模式獲取即時信息。

本發明實施例另一方面還提供一種即時通信系統，包括：客戶端與服務器端；