(57)【要約】      （修正有）【課題】ライブ配信メッセージ伝送方法及び装置、電子機器、記憶媒体並びにコンピュータプログラムを提供する。【解決手段】方法は、ライブ配信メッセージ伝送方法がクライアントによって実行される時、サーバとの間の持続的接続の状態を定期的に検出するステップと、持続的接続が切断状態にあることが検出されると、サーバとの間の持続的接続を再確立し、サーバから持続的接続の切断期間中の第１タイプのメッセージをプルするステップと、を含む。【効果】ライブ配信際の持続的接続の切断期間中にメッセージを正常に伝送できず、メッセージの欠落または誤った伝送をもたらすという問題を防止することができ、それにより、クライアントがライブ配信ルームのメッセージを正確に取得することができる。【選択図】図１
2022003510.tif 000002
【特許請求の範囲】
【請求項１】
クライアントによって実行され、前記クライアントとサーバとの間に持続的接続が確立されている、ライブ配信メッセージ伝送方法であって、
前記サーバとの間の持続的接続の状態を定期的に検出するステップと、
持続的接続が切断状態にあることが検出されると、前記サーバとの間の持続的接続を再確立し、前記サーバから持続的接続の切断期間中の第１タイプのメッセージをプルするステップと
を含むことを特徴とするライブ配信メッセージ伝送方法。
【請求項２】
前記サーバから持続的接続の切断期間中の第１タイプのメッセージをプルするステップは、
ローカルに表示された第１タイプのメッセージ識別子を取得するステップと、
ローカルに表示された第１タイプのメッセージ識別子に基づいて第１タイプのメッセージプルリクエストを生成するステップと、
前記サーバが持続的接続の切断期間中の第１タイプのメッセージを返送するように、前記サーバに前記第１タイプのメッセージプルリクエストを送信するステップと
を含むことを特徴とする請求項１に記載のライブ配信メッセージ伝送方法。
【請求項３】
前記第１タイプのメッセージ識別子は単調増加することを特徴とする請求項２に記載のライブ配信メッセージ伝送方法。
【請求項４】
前記サーバとの間の持続的接続の状態を定期的に検出するステップは、
前記サーバによって前記持続的接続を介して送信された第２タイプのメッセージを含むハートビート検出リクエストが受信されたか否かを定期的に検出するステップと、
前記ハートビート検出リクエストが受信されなかった場合、状態検出リクエストにより、持続的接続が切断状態にあるか否かを検出するステップと
を含むことを特徴とする請求項１に記載のライブ配信メッセージ伝送方法。
【請求項５】
前記サーバによって前記持続的接続を介して送信された第２タイプのメッセージを含むハートビート検出リクエストが受信されたか否かを定期的に検出するステップの後に、
前記ハートビート検出リクエストが受信された場合、持続的接続が接続状態にあると判定し、受信された第２タイプのメッセージを表示するステップを更に含むことを特徴とする請求項４に記載のライブ配信メッセージ伝送方法。
【請求項６】
前記方法は、
持続的接続を介して前記サーバによって送信された第１タイプのメッセージプロンプト指令を受信するステップと、
前記第１タイプのメッセージプロンプト指令に応答して、前記サーバから第１タイプのメッセージをプルするステップと
を更に含むことを特徴とする請求項１に記載のライブ配信メッセージ伝送方法。
【請求項７】
前記サーバから第１タイプのメッセージをプルした後、
ローカルに表示された第１タイプのメッセージ識別子に基づいて、プルされた第１タイプのメッセージをスクリーニング及び／又はソート処理し、処理結果に基づいてプルされた第１タイプのメッセージを表示するステップを更に含むことを特徴とする請求項１または６に記載のライブ配信メッセージ伝送方法。
【請求項８】
前記第１タイプのメッセージプロンプト指令は、ライブ配信ルームの固定トランザクションに応じて生成され、前記固定トランザクションは、投票、投げ銭及び贈り物の少なくとも１つを含むことを特徴とする請求項６に記載のライブ配信メッセージ伝送方法。
【請求項９】
サーバによって実行され、前記サーバとクライアントとの間に持続的接続が確立されている、ライブ配信メッセージ伝送方法であって、
クライアントの持続的接続の確立リクエストに応答して、前記クライアントとの間の持続的接続を再確立し、前記持続的接続の確立リクエストは、前記サーバとの間の持続的接続が切断状態にあることが前記クライアントによって検出された時に生成される、ステップと、
前記クライアントに持続的接続の切断期間における第１タイプのメッセージを送信するステップと
を含むことを特徴とするライブ配信メッセージ伝送方法。
【請求項１０】
前記クライアントに持続的接続の切断期間中の第１タイプのメッセージを送信するステップは、
表示された第１タイプのメッセージ識別子に基づいてクライアントによって生成された第１タイプのメッセージプルリクエストに応答して、前記クライアントに持続的接続の切断期間中の第１タイプのメッセージを送信するステップを含むことを特徴とする請求項９に記載のライブ配信メッセージ伝送方法。
【請求項１１】
前記第１タイプのメッセージ識別子は単調増加することを特徴とする請求項１０に記載のライブ配信メッセージ伝送方法。
【請求項１２】
持続的接続を介して、クライアントに第２タイプのメッセージを含むハートビート検出リクエストを定期的に送信して、クライアントが前記ハートビート検出リクエストを受信しなかった場合、状態検出リクエストを介して、持続的接続が切断状態にあるか否かを検出するステップを更に含むことを特徴とする請求項９に記載のライブ配信メッセージ伝送方法。
【請求項１３】
持続的接続を介して、クライアントに第１タイプのメッセージプロンプト指令を送信して、クライアントが前記第１タイプのメッセージプロンプト指令に応答して、前記サーバから第１タイプのメッセージをプルするステップを更に含むことを特徴とする請求項９に記載のライブ配信メッセージ伝送方法。
【請求項１４】
前記第１タイプのメッセージプロンプト指令は、ライブ配信ルームでの固定トランザクションに応じて生成され、前記固定トランザクションは、投票、投げ銭及び贈り物の少なくとも１つを含むことを特徴とする請求項１３に記載のライブ配信メッセージ伝送方法。
【請求項１５】
クライアントの所属する電子機器に配置され、前記クライアントとサーバとの間に持続的接続が確立されている、ライブ配信メッセージ伝送装置であって、
前記サーバとの間の持続的接続の状態を定期的に検出するための検出モジュールと、
持続的接続が切断状態にあることが検出されると、前記サーバとの間の持続的接続を再確立し、前記サーバから持続的接続の切断期間中の第１タイプのメッセージをプルするための持続的接続確立モジュールと
を含むことを特徴とするライブ配信メッセージ伝送装置。
【請求項１６】
サーバの所属する電子機器に配置され、前記サーバとクライアントとの間に持続的接続が確立されている、ライブ配信メッセージ伝送装置であって、
クライアントの持続的接続の確立リクエストに応答して、前記クライアントとの間の持続的接続を再確立するためのリクエスト応答モジュールであって、前記持続的接続の確立リクエストは、前記サーバとの間の持続的接続が切断状態にあることが前記クライアントによって検出された時に生成されるリクエスト応答モジュールと、
前記クライアントに持続的接続の切断期間中の第１タイプのメッセージを送信するためのメッセージ送信モジュールと
を含むことを特徴とするライブ配信メッセージ伝送装置。
【請求項１７】
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサと通信可能に接続されるメモリとを含み、
前記メモリには、前記少なくとも１つのプロセッサによって実行可能な指令が格納されており、前記指令は前記少なくとも１つのプロセッサによって実行されると、前記少なくとも１つのプロセッサに請求項１〜８のいずれかに記載のクライアントによって実行される方法、又は請求項９〜１４のいずれかに記載のサーバによって実行される方法を実現することを特徴とするライブ配信メッセージ伝送のための電子機器。
【請求項１８】
コンピュータ指令が格納される非一時的なコンピュータ可読記憶媒体であって、
前記コンピュータ指令は、請求項１〜８のいずれかに記載のクライアントによって実行される方法、又は請求項９〜１４のいずれかに記載のサーバによって実行される方法を前記コンピュータに実行させるためのものであることを特徴とする非一時的なコンピュータ可読記憶媒体。
【請求項１９】
プロセッサにより実行されると、請求項１〜８のいずれかに記載のクライアントによって実行される方法、又は請求項９〜１４のいずれかに記載のサーバによって実行される方法を実現する、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願の実施例は、インターネット技術分野に関し、特にメッセージ伝送技術に関する。具体的には、本出願の実施例は、ライブ配信メッセージ伝送方法及び装置、電子機器、記憶媒体並びにコンピュータプログラムを提供する。
【背景技術】
【０００２】
ライブ配信は、その場で、イベントの発生、進行のプロセスに同期して、情報を作成および配布し、且つ双方向通信過程を有する情報ネットワーク配布方式である。その形態は、ライブ配信ブロードキャスト、スタジオインタビュースタイルのライブ配信、テキストと画像のライブ配信、ビデオとオーディオのライブ配信、またはＴＶ（サードパーティ）によってソースが提供されるライブ配信に分けることができ、大量に格納されてクエリに便利である機能を持っている。
【０００３】
クライアントのライブ配信シーンにおいて、ライブ配信ルームでのデータ配信は、持続的接続のメッセージプッシュに強く依存している。これらのメッセージには、ライブ配信ルームのオンラインユーザ数の更新、通常の弾幕メッセージ、ネットアイドルへの贈り物、投げ銭などのメッセージ、質問回答ライブ配信際の質問の配信およびライブ配信ルームのクローズ、全員発言禁止、ライブストリームの切り替えなどの制御コマンドが含まれる。ライブ配信ルーム内のメッセージがクライアントに届かない場合、またはクライアントに届いたメッセージが誤った場合は、ライブ配信製品のユーザ体験に大きく影響を及ぼすことがある。
【発明の概要】
【０００４】
本出願の実施例はライブ配信メッセージ伝送方法及び装置、電子機器、記憶媒体並びにコンピュータプログラムを提供する。
【０００５】
第１の態様では、本出願の実施例はライブ配信メッセージ伝送方法を提供する。当該ライブ配信メッセージ伝送方法は、クライアントによって実行され、前記クライアントとサーバとの間に持続的接続が確立されており、
前記サーバとの間の持続的接続の状態を定期的に検出するステップと、
持続的接続が切断状態にあることが検出されると、前記サーバとの間の持続的接続を再確立し、前記サーバから持続的接続の切断期間中の第１タイプのメッセージをプルするステップとを含む。
【０００６】
第２の態様では、本出願の実施例はライブ配信メッセージ伝送方法を更に提供する。当該ライブ配信メッセージ伝送方法は、サーバによって実行され、前記サーバとクライアントとの間に持続的接続が確立されており、
クライアントの持続的接続の確立リクエストに応答して、前記クライアントとの間の持続的接続を再確立し、前記持続的接続の確立リクエストは、前記サーバとの間の持続的接続が切断状態にあることを前記クライアントが検出した時に生成されるステップと、
前記クライアントに持続的接続の切断期間中の第１タイプのメッセージを送信するステップとを含む。
【０００７】
第３の態様では、本出願の実施例は、ライブ配信メッセージ伝送装置を更に提供する。当該ライブ配信メッセージ伝送装置は、クライアントの所属する電子機器に配置され、前記クライアントとサーバとの間に持続的接続が確立されており、
前記サーバとの間の持続的接続の状態を定期的に検出するための検出モジュールと、
持続的接続が切断状態にあることが検出されると、前記サーバとの間の持続的接続を再確立し、前記サーバから持続的接続の切断期間中の第１タイプのメッセージをプルするための持続的接続確立モジュールとを含む。
【０００８】
第４の態様では、本出願の実施例はライブ配信メッセージ伝送装置を更に提供する。当該ライブ配信メッセージ伝送装置は、サーバの所属する電子機器に配置され、前記サーバとクライアントとの間に持続的接続が確立されており、
クライアントの持続的接続の確立リクエストに応答して、前記クライアントとの間の持続的接続を再確立するためのリクエスト応答モジュールであって、前記持続的接続の確立リクエストは、前記サーバとの間の持続的接続が切断状態にあることを前記クライアントが検出した時に生成されるリクエスト応答モジュールと、
前記クライアントに持続的接続の切断期間中の第１タイプのメッセージを送信するためのメッセージ送信モジュールとを含む。
【０００９】
第５の態様では、本出願の実施例は、ライブ配信メッセージ伝送用の電子機器を更に提供する。当該ライブ配信メッセージ伝送用の電子機器は、少なくとも１つのプロセッサと、前記少なくとも１つのプロセッサと通信可能に接続されるメモリとを含み、前記メモリには、前記少なくとも１つのプロセッサによって実行可能な指令が格納されており、前記指令は前記少なくとも１つのプロセッサによって実行されると、前記少なくとも１つのプロセッサに本出願の実施例のいずれかに記載のクライアントによって実行される方法、又は本出願の実施例のいずれかに記載のサーバによって実行される方法を実行させる。
【００１０】
第６の態様では、本出願の実施例は、コンピュータ指令が格納される非一時的なコンピュータ可読記憶媒体であって、前記コンピュータ指令は、本出願の実施例のいずれかに記載の、クライアントによって実行される方法、又は本出願の実施例のいずれかに記載の、サーバによって実行される方法を前記コンピュータに実行させる非一時的なコンピュータ可読記憶媒体を提供する。
【００１１】
第７の態様では、本出願の実施例は、コンピュータプログラムであって、前記コンピュータプログラムがプロセッサにより実行されると、本出願の実施例のいずれかに記載のクライアントによって実行される方法、又は本出願の実施例のいずれかに記載のサーバによって実行される方法を実現する、コンピュータプログラムを提供する。
【００１２】
本出願の実施例の技術的解決手段によれば、クライアントがサーバとの間の持続的接続の状態を定期的に検出し、持続的接続が切断状態にあることが検出されると、サーバとの間の持続的接続を再確立し、且つサーバから持続的接続の切断期間中の第１タイプのメッセージをプルすることにより、ライブ配信際の持続的接続の切断期間中にメッセージを正常に伝送できず、メッセージの欠落または不正確な伝送をもたらすという問題を防止することができ、それによって、クライアントがライブ配信期間のメッセージを正確に取得することができる。
【００１３】
この部分に記載された内容は、本出願の実施例のキーまたは重要な特徴を特定することを意図するものではなく、本出願の範囲を限定することを意図するものでもないことを理解される。本出願の他の特徴は、以下の明細書によって理解しやすくなる。
【図面の簡単な説明】
【００１４】
図面は、本解決手段をよりよく理解するために使用されており、本出願を制限するものではない。
【図１】本出願の実施例に係るクライアントによって実行されるライブ配信メッセージ伝送方法のフローチャートである。
【図２】本出願の実施例に係る第１タイプのメッセージを取得するための模式図である。
【図３】本出願の実施例に係る他の、クライアントによって実行されるライブ配信メッセージ伝送方法のフローチャートである。
【図４】本出願の実施例に係る第２タイプのメッセージをプッシュするための模式図である。
【図５】本出願の実施例に係る持続的接続の検出・再確立及びメッセージプルの模式図である。
【図６】本出願の実施例に係るさらなる他の、クライアントによって実行されるライブ配信メッセージ伝送方法のフローチャートである。
【図７】本出願の実施例に係るサーバによって実行されるライブ配信メッセージ伝送方法のフローチャートである。
【図８】本出願の実施例に係るクライアントの所属する電子機器に配置されたライブ配信メッセージ伝送装置の構造模式図である。
【図９】本出願の実施例に係るサーバの所属する電子機器に配置されたライブ配信メッセージ伝送装置の構造模式図である。
【図１０】本出願の実施例のライブ配信メッセージ伝送方法を実現するための電子機器のブロック図である。
【発明を実施するための形態】
【００１５】
以下は、図面を参照しながら、理解を容易にするための本出願の実施例の様々な詳細を含めて本出願の例示的な実施例を説明し、これらは、単なる例示的なものと見なされるべきである。従って、当業者は、本出願の範囲および精神から逸脱することなく、本明細書に記載の実施例に対して様々な変更および修正を行うことができることを理解すべきである。同様に、明確さと簡潔さのために、よく知られている機能と構造の説明は、以下の説明では省略されている。
【００１６】
図１は、本出願の実施例に係るクライアントによって実行されるライブ配信メッセージ伝送方法のフローチャートである。本実施例は、ライブ配信期間にメッセージを伝送する状況に適することができる。典型的に、本実施例は、ライブ配信期間にクライアントが持続的接続の状態を定期的に検出し、持続的接続の切断を検出した時に、サーバからメッセージをタイムリーにプルする場合に適用することができる。図１に示すように、本出願の実施例に係るクライアントによって実行されるライブ配信メッセージ伝送方法では、前記クライアントとサーバとの間に持続的接続が確立されており、前記方法は、Ｓ１１０〜Ｓ１２０を含む。
【００１７】
Ｓ１１０、前記サーバとの間の持続的接続の状態を定期的に検出する。
【００１８】
ここで、持続的接続とは、１つの接続に複数のデータパケットを連続して送信でき、接続の維持期間に、データパケットが送信されない場合、双方がリンク検出パケットを送信する必要がある通信接続モードである。持続的接続チャネルは、通常、クライアントがＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ、伝送制御プロトコル）又はＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ、ユーザデータグラムプロトコル）を介してサーバとの間に確立したものである。サーバは、プッシュモードを使用して、クライアントにメッセージをプッシュする。持続的接続の通信モードは、サービスアクセスが簡単で、メッセージが拡張可能であり、ライブ配信ルーム内でのメッセージの並行性が高いシーンに対応できるため、ライブ配信シーンに適用できる。
【００１９】
ライブ配信ルームでの持続的接続自体は、モバイルネットワークの影響を大きく受けるため、長期的な安定性を維持することは困難である。ライブ配信過程中に持続的接続が切断されると、ライブ配信ルームから配信されるメッセージの正確な配達に深刻な影響を及ぼす。従って、本出願の実施例では、クライアントがサーバとの間の持続的接続の状態を定期的に検出するため、持続的接続が切断されたことをタイムリーに知ることができ、それによって、持続的接続の長期的な切断によるライブ配信効果への影響を防止できる。本出願の実施例では、クライアントがサーバとの間の持続的接続の状態を定期的に検出し、サーバによる定期的な検出の必要がないので、サーバへのストレスを効果的に低減し、ライブ配信の効果を改善することができる。
【００２０】
Ｓ１２０、持続的接続が切断状態にあることが検出されると、前記サーバとの間の持続的接続を再確立し、前記サーバから持続的接続の切断期間中の第１タイプのメッセージをプルする。
【００２１】
ここで、第１タイプのメッセージは、ライブ配信ルームに到達する必要のあるメッセージであってもよく、例えば贈り物、投げ銭、質問回答ライブ配信における質問の配信、ライブ配信ルームのクローズ、ライブストリームの切り替え等のメッセージである。上記到達する必要のあるメッセージが正確に到着できないと、支払い結果、決済結果、質問回答コンテスト結果又はライブ配信ルームの状態等の重要なデータに影響を及ぼすことがある。上記到達する必要のあるメッセージは第１タイプのメッセージとされる。それに対応して、到達する必要のあるメッセージを除くライブ配信ルームでのほかのメッセージは通常メッセージであってもよく、例えばライブ配信の弾幕、到着メッセージ、ライブ配信ルーム内の人数の更新などの他のメッセージである。上記通常メッセージは、ライブ配信進行及びイベント結果にほとんど影響を与えない。上記通常メッセージは第２タイプのメッセージとされる。
【００２２】
例示的には、持続的接続の長期間にわたる切断によってライブ配信期間のメッセージをタイムリー且つ正確にクライアントに配信できないことを回避するために、クライアントは、持続的接続が切断状態にあることを検出したとき、ライブ配信期間のメッセージのタイムリーで正確な配信を確保するように、サーバとの間の持続的接続を再確立する。持続的接続の切断期間にも、ライブ配信ルームではメッセージがサーバを介して配信される可能性があるため、メッセージの欠落を回避するために、サーバから持続的接続の切断期間中の第１タイプのメッセージをプルする必要がある。クライアントは、メッセージの完全性を維持するように、サーバから持続的接続の切断期間中の第２タイプのメッセージをプルすることもできる。クライアントは、持続的接続チャネルを介して第１タイプのメッセージ及び／又は第２タイプのメッセージをプルしてもよく、ショート接続チャネルを介して第１タイプのメッセージ及び／又は第２タイプのメッセージをプルしてもよく、ここで限定をしない。
【００２３】
本出願の実施例では、前記方法は、持続的接続を介して前記サーバから送信された第１タイプのメッセージプロンプト指令を受信するステップと、前記第１タイプのメッセージプロンプト指令に応答して、前記サーバから第１タイプのメッセージをプルするステップとを更に含む。前記第１タイプのメッセージプロンプト指令は、ライブ配信ルームでの固定トランザクションに応答して生成され、前記固定トランザクションは、投票、投げ銭及び贈り物の少なくとも１つを含む。
【００２４】
具体的には、図２に示すように、ライブ配信ルームでは、投票、投げ銭の配信又は贈り物の贈与等の固定イベントが開始されると、サーバは、固定イベントに応答し、第１タイプのメッセージプロンプト指令を生成して、第１タイプのメッセージがあることをクライアントにタイムリーに通知する。サーバは、クライアントにライブ配信ルームから配信される第１タイプのメッセージを送信して、クライアントが第１タイプのメッセージを受信して表示できるようにしてもよく、先にクライアントに第１タイプのメッセージを直接送信する代わりに、クライアントに第１タイプのメッセージプロンプト指令を送信して、クライアントが第１タイプのメッセージプロンプト指令に応答してサーバから第１タイプのメッセージをプルできるようにしてもよい。サーバがクライアントに第１タイプのメッセージを直接送信する技術的解決手段と比較して、サーバがクライアントに第１タイプのメッセージプロンプト指令を送信することは、サーバからクライアントにプッシュされるデータの量を効果的に減らし、サーバのストレスを軽減することができ、且つ伝送されるデータの量が減るため、クライアントが第１タイプのメッセージプロンプト指令を素早く受信でき、メッセージがクライアントに到達するまでの時間を短縮することができる。
【００２５】
本出願の実施例では、前記サーバから第１タイプのメッセージをプルするステップの後、前記方法は、ローカルに表示された第１タイプのメッセージ識別子に基づいて、プルされた第１タイプのメッセージをスクリーニング及び／又はソート処理し、処理結果に基づいてプルされた第１タイプのメッセージを表示するステップを更に含む。
【００２６】
例示的には、クライアントがサーバからプルした第１タイプのメッセージ中には、クライアントによってローカルに表示されている第１タイプのメッセージがいくつある場合があり、表示された第１タイプのメッセージが繰り返し表示されないようにするために、第１タイプのメッセージを整然と表示させるように、重複排除処理を実行する。ローカルに表示された第１タイプのメッセージ識別子に基づいて、プルされた第１タイプのメッセージをスクリーニング及び／又はソート処理し、且つ処理結果に基づいて、その後に表示する第１タイプのメッセージを確定することができる。例えば、第１タイプのメッセージ識別子を単調増加させる。表示された第１タイプのメッセージ識別子は１、２、３、４であり、クライアントがサーバからプルした第１タイプのメッセージ識別子が３である第１タイプのメッセージを表示せず、クライアントがサーバからプルした第１タイプのメッセージ識別子が５である第１タイプのメッセージを表示する。クライアントは、ローカルに表示された第１タイプのメッセージを永続的に記憶してもよい。ローカルに表示された第１タイプのメッセージの数が統計して取得され、表示された第１タイプのメッセージの数が２０であり、クライアントがサーバからプルした第１タイプのメッセージ識別子が１９であると、当該第１タイプのメッセージを表示しない。クライアントがサーバからプルした第１タイプのメッセージ識別子が２１であると、当該第１タイプのメッセージを表示する。上記の技術的解決手段により、第１タイプのメッセージの欠落を回避することができ、第１タイプのメッセージを繰り返し表示して、ライブ配信効果及びイベント処理結果に影響を及ぼすことを回避することができる。あるいは、クライアントがサーバからプルした第１タイプのメッセージの第１タイプのメッセージ識別子をソートすることで、第１タイプのメッセージの整然とした表示を実現してもよい。
【００２７】
本出願の実施例の上記技術的解決手段によれば、クライアントがサーバとの間の持続的接続の状態を定期的に検出し、持続的接続が切断状態にあることが検出されると、サーバとの間の持続的接続を再確立し、且つサーバから持続的接続の切断期間中の第１タイプのメッセージをプルすることにより、ライブ配信際の持続的接続の切断期間中にメッセージを正常に伝送できなく、メッセージの欠落または誤った伝送をもたらすという問題を回避することができ、それにより、クライアントがライブ配信期間のメッセージを正しく取得することができる。
【００２８】
図３は、本出願の実施例に係る他のクライアントによって実行されるライブ配信メッセージ伝送方法のフローチャートである。この実施例に記載されていない詳細については、上記の実施例を参照できる。図３を参照し、本実施例に係る他のクライアントによって実行されるライブ配信メッセージ伝送方法は、Ｓ２１０〜Ｓ２４０を含んでもよい。
【００２９】
Ｓ２１０、前記サーバによって前記持続的接続を介して送信された、第２タイプのメッセージを含むハートビート検出リクエストが受信されたか否かを定期的に検出する。受信されなかった場合は、Ｓ２２０〜Ｓ２３０を実行し、受信された場合は、Ｓ２４０を実行する。
【００３０】
具体的には、第２タイプのメッセージに関する説明は、上記実施例を参照されたい。ライブ配信期間の持続的接続の状態を検出するために、一般的な技術的解決手段は、サーバが持続的接続の状態を定期的に検出することであるが、この技術的解決手段によれば、サーバのストレスが増え、サーバがライブ配信期間の他のタスクを処理できなくなり、ライブ配信の進行プロセスに影響を与える可能性がある。従って、本出願の実施例では、図４に示すように、サーバからクライアントに定期的に配信される第２タイプのメッセージは、ダウンリンクハートビート検出リクエストとして使用され、周期が２ｓであってもよく、特に限定されない。サーバによって持続的接続を介して送信された、第２タイプのメッセージを含むハートビート検出リクエストが受信されると、Ｓ２４０を実行する。サーバによって持続的接続を介して送信された、第２タイプのメッセージを含むハートビート検出リクエストが受信されていないと、Ｓ２２０〜Ｓ２３０を実行する。サーバから定期的に配信される第２タイプのメッセージをダウンリンクハートビート検出リクエストとすることにより、サーバはライブ配信ルームから配信される第２タイプのメッセージを正常に送信するだけでよく、持続的接続の状態を検出するための追加の検出リクエストを定期的に送信する必要がない。それにより、サーバのストレスを効果的に軽減し、ライブ配信期間のイベントに対するサーバの正常処理を確保し、正常なライブ配信プロセスを維持することができる。上記技術的解決手段は、サーバのソースを節約でき、例えば、５００万人が同時にオンラインでライブ視聴できるようにサポートする場合、上記技術的解決手段を採用すると、約６２台のサーバが必要であり、他のライブ配信の技術的解決手段を採用すると、約２５０台のサーバが必要である。
【００３１】
本出願の実施例は、サーバはライブ配信ルームから配信されるメッセージを第１タイプのメッセージ及び第２タイプのメッセージに分け、クライアントはサーバから持続的接続を介して送信されたメッセージを受信し、サーバから持続的接続を介して送信された第１タイプのメッセージを受信した場合、第１タイプのメッセージに対する処理操作を実行し、例えばサーバから第１タイプのメッセージをプルし、スクリーニング及び／又はソート処理し、処理結果に基づいてプルされた第１タイプのメッセージを表示する等を実行してもよい。サーバから持続的接続を介して送信された、第２タイプのメッセージを含むハートビート検出リクエストが受信された場合、Ｓ２４０を実行し、サーバから持続的接続を介して送信された、第２タイプのメッセージを含むハートビート検出リクエストが受信されていない場合、Ｓ２２０〜Ｓ２３０を実行する。
【００３２】
Ｓ２２０：状態検出リクエストにより持続的接続が切断状態にあるか否かを検出する。
【００３３】
クライアントがサーバから持続的接続を介して送信された第２タイプのメッセージを含むハートビート検出リクエストを受信できない場合、持続的接続の切断により、第２タイプのメッセージを含むハートビート検出リクエストがクライアントまでに伝送できないためであり得る。従って、持続的接続が切断されているか否かを更に確認するために、クライアントは、サーバに状態検出リクエストを送信することにより、持続的接続が切断されているか否かを検出する。例示的には、クライアントは、サーバに状態検出リクエストを送信した後、サーバから返された応答メッセージを受信した場合、持続的接続が切断されていないことを示す。クライアントは、サーバに状態検出リクエストを送信した後、サーバから返された応答メッセージを受信していない場合は、持続的接続が切断状態にあることを示す。クライアントは持続的接続が切断状態にあるか否かを検出することにより、持続的接続が切断された時にタイムリーに知ることができる。それによって、持続的接続の切断が判定された時、タイムリーに持続的接続を再確立し、ライブ配信の正常な進行を確保することができる。
【００３４】
Ｓ２３０、持続的接続が切断状態にあることが検出されると、前記サーバとの間の持続的接続を再確立し、前記サーバから持続的接続の切断期間中の第１タイプのメッセージをプルする。
【００３５】
Ｓ２４０、持続的接続が接続状態にあることを確定し、受信した第２タイプのメッセージを表示する。
【００３６】
具体的には、クライアントは、サーバから持続的接続を介して送信された、第２タイプのメッセージを含むハートビート検出リクエストを受信した場合、この時、持続的接続が接続状態にあり、メッセージの伝送を実現できる。クライアントは、受信した第２タイプのメッセージをローカルに表示して、第２タイプのメッセージの正常な表示を実現する。
【００３７】
本出願の実施例では、図５に示すように、当該メッセージが第２タイプのメッセージである場合、タイマーをリセットして、サーバから定期的に送信された第２タイプのメッセージを引き続き受信する。タイマーが切れたとき、サーバから送信された第２タイプのメッセージを受信していなかった場合、持続的接続の切断により、第２タイプのメッセージがクライアントに成功に伝送できなかったためである可能性がある。従って、Ｓ２２０を再度実行し、状態検出リクエストにより持続的接続が切断状態にあるか否かを検出する。
【００３８】
本出願の実施例の上記技術的解決手段によれば、前記サーバから前記持続的接続を介して送信された、第２タイプのメッセージを含むハートビート検出リクエストが受信されたか否かを確定することにより、受信されていない場合、状態検出リクエストにより持続的接続が切断状態にあるか否かを検出することにより、クライアントは、持続的接続が切断された時にタイムリーに知ることができる。それによって、持続的接続の切断が確定された時、タイムリーに持続的接続を再確立し、ライブ配信の正常な進行を確保することができる。また、サーバから定期的に配信された第２タイプのメッセージをダウンリンクハートビート検出リクエストとすることにより、サーバはライブ配信ルームから配信される第２タイプのメッセージを正常に配信するだけでよく、持続的接続の状態を検出するために追加の検出リクエストを定期的に送信する必要がない。それによって、サーバへのストレスを効果的に軽減し、ライブ配信期間のイベントに対するサーバの正常処理を確保し、正常なライブ配信プロセスを維持することができる。
【００３９】
図６は、本出願の実施例に係るさらなる他の、クライアントによって実行されるライブ配信メッセージ伝送方法のフローチャートである。この実施例に記載されていない詳細については、上記の実施例を参照できる。図６を参照し、本実施例に係る他の、クライアントによって実行されるライブ配信メッセージ伝送方法は、Ｓ３１０〜Ｓ３５０を含んでもよい。
【００４０】
Ｓ３１０、前記サーバとの間の持続的接続の状態を定期的に検出する。
【００４１】
Ｓ３２０、持続的接続が切断状態にあることが検出されると、前記サーバとの間の持続的接続を再確立する。
【００４２】
Ｓ３３０、ローカルに表示された第１タイプのメッセージ識別子を取得する。
【００４３】
ここで、第１タイプのメッセージ識別子は単調増加する。例示的には、１番目の第１タイプのメッセージの第１タイプのメッセージ識別子は１であってもよく、２番目の第１タイプのメッセージの第１タイプのメッセージ識別子は２であってもよく、このように類推できる。ここで、第１タイプのメッセージ識別子の具体的な形式は、特に限定されておらず、０１、０２、０３…であってもよい。クライアントによってローカルに表示された第１タイプのメッセージを再度表示する必要がないため、第１タイプのメッセージの繰り返し表示を防止するために、クライアントはローカルに表示された第１タイプのメッセージ識別子を取得して、サーバから表示された第１タイプのメッセージをプルしない。
【００４４】
Ｓ３４０、ローカルに表示された第１タイプのメッセージ識別子に基づいて第１タイプのメッセージプルリクエストを生成する。
【００４５】
Ｓ３５０、前記サーバが持続的接続の切断期間中の第１タイプのメッセージを返すように、前記サーバに前記第１タイプのメッセージプルリクエストを送信する。
【００４６】
例示的には、クライアントは、ローカルに表示されたすべての第１タイプのメッセージ識別子に基づいて第１タイプのメッセージプルリクエストを生成し、サーバに送信することができる。サーバは、ライブ配信ルームから配信された第１タイプのメッセージ識別子と、クライアントから送信された、ローカルに表示されたすべての第１タイプのメッセージ識別子とを比較し、比較の結果のうち、一致しない第１タイプのメッセージ識別子に対応する第１タイプのメッセージは、クライアントによって表示されていない第１タイプのメッセージであり、サーバは、当該第１タイプのメッセージをクライアントに返す。例えば、クライアントによってローカルに表示されたすべての第１タイプのメッセージ識別子は１、２、３、４であり、サーバにおいてライブ配信ルームから配信された第１タイプのメッセージ識別子は１、２、３、４、５であり、ここで、第１タイプのメッセージ識別子５はクライアントによってローカルに表示されたいずれの第１タイプのメッセージ識別子と一致しなく、サーバは、第１タイプのメッセージ識別子５に対応する第１タイプのメッセージをクライアントに返す。
【００４７】
本出願の実施例では、クライアントは、ローカルに表示された第１タイプのメッセージ識別子のうちの、最も大きい第１タイプのメッセージ識別子に基づいて第１タイプのメッセージプルリクエストを生成し、サーバに送信し、サーバにおいてライブ配信ルームから配信された第１タイプのメッセージ識別子が最も大きい第１タイプのメッセージ識別子より大きい場合、当該第１タイプのメッセージ識別子に対応する第１タイプのメッセージを、クライアントによって表示されていない第１タイプのメッセージとして確定し、サーバは、当該第１タイプのメッセージをクライアントに返すようにしてもよい。例えば、クライアントによってローカルに表示されたすべての第１タイプのメッセージ識別子は１、２、３、４であり、ここで、第１タイプのメッセージ識別子の最大値は４であり、サーバにおいてライブ配信ルームから配信された第１タイプのメッセージ識別子は１、２、３、４、５であり、第１タイプのメッセージ識別子５が第１タイプのメッセージ識別子の最大値４より大きく、サーバは第１タイプのメッセージ識別子５に対応する第１タイプのメッセージをクライアントに返す。
【００４８】
本出願の実施例では、クライアントは、ローカルに表示された第１タイプのメッセージ識別子に基づいて、ローカルに表示された第１タイプのメッセージの数を統計し、表示された第１タイプのメッセージの数に基づいて第１タイプのメッセージプルリクエストを生成し、サーバに送信し、サーバはライブ配信ルームから配信された第１タイプのメッセージ識別子と表示された第１タイプのメッセージの数とを比較し、第１タイプのメッセージ識別子に対応する第１タイプのメッセージの数が表示された第１タイプのメッセージの数より大きい場合、当該第１タイプのメッセージ識別子に対応する第１タイプのメッセージを、クライアントによって表示されていない第１タイプのメッセージとして確定し、サーバは、当該第１タイプのメッセージをクライアントに返すようにしてもよい。例えば、クライアントによってローカルに表示されたすべての第１タイプのメッセージ識別子は１、２、３、４であるため、クライアントによってローカルに表示されたすべての第１タイプのメッセージの数は４であり、サーバにおいてライブ配信ルームから配信された第１タイプのメッセージ識別子は１、２、３、４、５であり、サーバの第１タイプのメッセージ識別子５に対応する第１タイプのメッセージの数５は、クライアントによってローカルに表示されたすべての第１タイプのメッセージの数４より大きく、サーバは、第１タイプのメッセージ識別子５に対応する第１タイプのメッセージをクライアントに返す。
【００４９】
本出願の実施例では、タイマーの時間に基づいて、サーバからプルする必要がある第１タイプのメッセージを確定してもよい。例えば、クライアントは、タイマー期間内にライブ配信ルームから配信された第１タイプのメッセージを返すようにサーバに要求するか、またはタイマーがリセットされた時から現在の時刻までの期間内にライブ配信ルームから配信された第１タイプのメッセージを返すようにサーバに要求する。
【００５０】
本出願の実施例では、前記サーバが持続的接続の切断期間中の第１タイプのメッセージを返すように、前記サーバに前記第１タイプのメッセージプルリクエストを送信するステップの後、前記方法は、ローカルに表示された第１タイプのメッセージ識別子に基づいて、プルされた第１タイプのメッセージをスクリーニング及び／又はソート処理し、処理結果に基づいてプルされた第１タイプのメッセージを表示するステップを更に含む。それによって、第１タイプのメッセージが重複排除（ｄｅｄｕｐｌｉｃａｔｉｏｎ）後に表示され、同一の第１タイプのメッセージを繰り返し表示してユーザ体験に影響を与えることを回避することができ、且つソート処理により、第１タイプのメッセージを順次再生することが実現され、ユーザ体験を向上させることができる。
【００５１】
本出願の実施例に係る上記技術的解決手段によれば、前記サーバが持続的接続の切断期間中の第１タイプのメッセージを返すように、前記サーバに前記第１タイプのメッセージプルリクエストを送信することにより、持続的接続の切断期間中にライブ配信ルームから配信された第１タイプのメッセージを正確に取得することができ、第１タイプのメッセージの欠落を回避することができる。ローカルに表示された第１タイプのメッセージ識別子を取得し、ローカルに表示された第１タイプのメッセージ識別子に基づいて第１タイプのメッセージプルリクエストを生成することにより、第１タイプのメッセージを選択的にプルすることが実現され、クライアントによってローカルに同一の第１タイプのメッセージを繰り返し表示することを回避し、ライブ配信のユーザ体験を向上させることができる。
【００５２】
図７は、本出願の実施例に係るサーバによって実行されるライブ配信メッセージ伝送方法のフローチャートである。本実施例は、ライブ配信期間にメッセージを伝送する場合に適することができる。特に、本実施例は、ライブ配信期間にクライアントが持続的接続の状態を定期的に検出し、持続的接続の切断を検出した時にタイムリーにサーバからメッセージをプルする場合に適することができる。この実施例に記載されていない詳細については、上記の実施例を参照できる。図７を参照し、本出願の実施例に係るサーバによって実行されるライブ配信メッセージ伝送方法では、前記サーバとクライアントとの間に持続的接続が確立されており、前記方法はＳ４１０〜Ｓ４２０を含んでもよい。
【００５３】
Ｓ４１０：クライアントの持続的接続の確立リクエストに応答して、前記クライアントとの間の持続的接続を再確立するステップであって、前記持続的接続の確立リクエストは、前記クライアントが前記サーバとの間の持続的接続が切断状態にあることを検出した時に生成される。
【００５４】
ここで、持続的接続とは、１つの接続上で複数のデータパケットを連続して送信でき、接続の維持期間に、データパケットが送信されない場合、双方がリンク検出パケットを送信する必要がある通信接続モードである。持続的接続チャネルは、通常、クライアントがＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ、伝送制御プロトコル）又はＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ、ユーザデータグラムプロトコル）を介してサーバとの間に確立したものである。サーバは、プッシュモードを使用して、クライアントにメッセージをプッシュする。持続的接続の通信モードは、サービスアクセスが簡単で、メッセージが拡張可能で、ライブ配信ルーム内でのメッセージの同時実行性が高いシーンに対応できるため、ライブ配信シーンに適用できる。
【００５５】
ライブ配信ルームでの持続的接続自体は、モバイルネットワークから大きな影響を受けるため、長期的な安定性を維持することは困難である。ライブ配信過程中に持続的接続が切断されると、ライブ配信ルームから配信されるメッセージの確実な配達に深刻な影響を及ぼす。従って、本出願の実施例では、クライアントがサーバとの間の持続的接続の状態を定期的に検出するため、持続的接続が切断されたときにタイムリーに知ることができ、それによって、持続的接続の長期的な切断によるライブ配信効果への影響を防止する。本出願の実施例では、クライアントがサーバとの間の持続的接続の状態を定期的に検出し、サーバによる定期的な検出を必要としないので、サーバへのストレスを効果的に低減し、ライブ配信の効果を改善することができる。
【００５６】
持続的接続の長期的な切断によってライブ配信期間的メッセージをタイムリー且つ正確にクライアントに配信できないことを回避するために、クライアントは、持続的接続が切断状態にあることを検出したとき、ライブ配信期間のメッセージのタイムリーで正確な配信を確保するように、サーバとの間の持続的接続を再確立する。サーバは、クライアントの持続的接続の確立リクエストに応答して、前記クライアントとの間の持続的接続を再確立する。
【００５７】
Ｓ４２０：前記クライアントに持続的接続の切断期間中の第１タイプのメッセージを送信する。
【００５８】
ここで、第１タイプのメッセージは、ライブ配信ルームでの到達する必要のあるメッセージであってもよく、例えば贈り物、投げ銭、質問回答ライブ配信における質問の配信、ライブ配信ルームのクローズ、ライブストリームの切り替え等のメッセージである。上記の到達する必要のあるメッセージが正確に配達できないと、支払い結果、決済結果、質問回答コンテスト結果又はライブ配信ルームの状態等の重要なデータに影響を与えることがある。上記の到達する必要のあるメッセージは、第１タイプのメッセージとされる。それに対応して、例えばライブ配信の弾幕、到着メッセージ、ライブ配信ルーム内の人数の更新などのライブ配信ルームの通常メッセージは、ライブ配信プロセス及びイベントの結果にほとんど影響を与えない。上記の通常メッセージは第２タイプのメッセージとされる。
【００５９】
持続的接続の切断期間にも、ライブ配信ルームではメッセージがサーバを介して配信される可能性があるため、メッセージの欠落を回避するために、サーバは、クライアントに持続的接続の切断期間中の第１タイプのメッセージを送信する。メッセージの完全性を保持するように、同様にクライアントに第２タイプのメッセージを送信してもよい。
【００６０】
本出願の実施例では、前記クライアントに持続的接続の切断期間中の第１タイプのメッセージを送信するステップは、表示された第１タイプのメッセージ識別子に基づいてクライアントによって生成された第１タイプのメッセージプルリクエストに応答して、前記クライアントに持続的接続の切断期間中の第１タイプのメッセージを送信するステップを含む。前記第１タイプのメッセージ識別子は単調増加する。
【００６１】
例示的には、クライアントが持続的接続の切断状態を検出したとき、ローカルに表示された第１タイプのメッセージ識別子を取得し、ローカルに表示された第１タイプのメッセージ識別子に基づいて第１タイプのメッセージプルリクエストを生成し、前記サーバに前記第１タイプのメッセージプルリクエストを送信し、サーバはクライアントから送信された第１タイプのメッセージプルリクエストに応答して、クライアントに第１タイプのメッセージを返す。詳細については、上記実施例におけるＳ３３０〜Ｓ３５０を参照されたい。
【００６２】
本出願の実施例では、前記方法は、持続的接続を介して、クライアントに第２タイプのメッセージを含むハートビート検出リクエストを定期的に送信して、クライアントが前記ハートビート検出リクエストを受信していない時、状態検出リクエストによって持続的接続が切断状態にあるか否かを検出するステップを更に含む。
【００６３】
具体的には、第２タイプのメッセージに関する説明は、上記実施例に示されている。ライブ配信期間の持続的接続の状態を検出するために、一般的な技術的解決手段は、サーバが持続的接続の状態を定期的に検出することであるが、この技術的解決手段は、サーバへのストレスを増加することがあるため、サーバがライブ配信期間の他のタスクを正常に処理できなくなり、ライブ配信プロセスに影響を与える可能性がある。従って、本出願の実施例では、サーバからクライアントに定期的に配信される第２タイプのメッセージがダウンリンクハートビート検出リクエストとされ、クライアントは、サーバから持続的接続を介して送信されたメッセージを受信する。サーバから持続的接続を介して送信された第２タイプのメッセージを含むハートビート検出リクエストが受信された場合、持続的接続が接続状態にあると判定し、受信した第２タイプのメッセージを表示する。サーバから持続的接続を介して送信された第２タイプのメッセージを含むハートビート検出リクエストが受信されなかった場合、状態検出リクエストにより持続的接続が切断状態にあるか否かを検出する。サーバから定期的に配信される第２タイプのメッセージをダウンリンクハートビート検出リクエストとすることにより、サーバは、ライブ配信ルームから配信された第２タイプのメッセージを正常に送信するだけでよく、持続的接続の状態を検出するための追加の検出リクエストを定期的に送信する必要がない。それによって、サーバへのストレスを効果的に軽減し、ライブ配信期間のイベントに対するサーバの正常処理を確保し、正常なライブ配信プロセスを維持することができる。
【００６４】
本出願の実施例は、サーバがライブ配信ルームから配信されたメッセージを第１タイプのメッセージ及び第２タイプのメッセージに分け、クライアントはサーバから持続的接続を介して送信されたメッセージを受信し、サーバから持続的接続を介して送信された第１タイプのメッセージを受信した場合、第１タイプのメッセージに対する処理操作を実行し、例えばサーバから第１タイプのメッセージをプルし、スクリーニング及び／又はソート処理し、処理結果に基づいてプルされた第１タイプのメッセージを表示する等を実行することであってもよい。サーバから持続的接続を介して送信された第２タイプのメッセージを含むハートビート検出リクエストが受信された場合、持続的接続が接続状態にあると判定し、受信した第２タイプのメッセージを表示する。サーバから持続的接続を介して送信された第２タイプのメッセージを含むハートビート検出リクエストが受信されなかった場合、状態検出リクエストにより持続的接続が切断状態にあるか否かを検出する。
【００６５】
本出願の実施例では、前記方法は、持続的接続を介して、クライアントに第１タイプのメッセージプロンプト指令を送信して、クライアントが前記第１タイプのメッセージプロンプト指令に応答して、前記サーバから第１タイプのメッセージをプルするステップを含む。前記第１タイプのメッセージプロンプト指令は、ライブ配信ルームでの固定トランザクションに応答して生成され、前記固定トランザクションは、投票、投げ銭及び贈り物の少なくとも１つを含む。
【００６６】
具体的には、ライブ配信ルームでは、投票、投げ銭の配信又は贈り物の贈与等の固定イベントが開始されると、サーバは、固定イベントに応答し、第１タイプのメッセージプロンプト指令を生成して、第１タイプのメッセージがあることをクライアントにタイムリーに通知する。サーバは、クライアントにライブ配信ルームから配信された第１タイプのメッセージを送信して、クライアントが第１タイプのメッセージを受信して表示できるようにしてもよく、クライアントに第１タイプのメッセージを直接送信せず、クライアントに第１タイプのメッセージプロンプト指令を送信して、クライアントが第１タイプのメッセージプロンプト指令に応答してサーバから第１タイプのメッセージをプルできるようにしてもよい。サーバがクライアントに第１タイプのメッセージを直接送信する技術的解決手段と比較して、サーバがクライアントに第１タイプのメッセージプロンプト指令を送信することは、サーバからクライアントにプッシュされるデータの量を効果的に減らし、サーバへのストレスを軽減することができ、且つ伝送されるデータの量が減るため、クライアントが第１タイプのメッセージプロンプト指令を素早く受信でき、メッセージのクライアントに到達するまでの時間を短縮することができる。
【００６７】
本出願の実施例に係る上記技術的解決手段によれば、クライアントの持続的接続の確立リクエストに応答して、前記クライアントとの間の持続的接続を再確立し、且つ前記クライアントに持続的接続の切断期間中の第１タイプのメッセージを送信することにより、ライブ配信際の持続的接続の切断期間中にメッセージを正常に伝送できず、メッセージの欠落または不正確な伝送をもたらすという問題を回避することができ、それによって、クライアントがライブ配信期間のメッセージを正確に取得することができる。
【００６８】
図８は、本出願の実施例に係るクライアントの所属する電子機器に配置されたライブ配信メッセージ伝送装置の構造模式図である。図８を参照し、本出願の実施例に係るクライアントの所属する電子機器に配置されるライブ配信メッセージ伝送装置５００において、前記クライアントとサーバとの間に持続的接続が確立されており、前記装置は、検出モジュール５０１と持続的接続確立モジュール５０２とを含む。
【００６９】
検出モジュール５０１は、前記サーバとの間の持続的接続の状態を定期的に検出するように構成される。
【００７０】
持続的接続確立モジュール５０２は、持続的接続が切断状態にあることが検出されると、前記サーバとの間の持続的接続を再確立し、前記サーバから持続的接続の切断期間中の第１タイプのメッセージをプルするように構成される。
【００７１】
本出願の実施例では、前記持続的接続確立モジュール５０２は、
ローカルに表示された第１タイプのメッセージ識別子を取得するための識別子取得ユニットと、
ローカルに表示された第１タイプのメッセージ識別子に基づいて第１タイプのメッセージプルリクエストを生成するためのリクエスト生成ユニットと、
前記サーバが持続的接続の切断期間中の第１タイプのメッセージを返すように、前記サーバに前記第１タイプのメッセージプルリクエストを送信するためのリクエスト送信ユニットとを含む。
【００７２】
本出願の実施例では、前記第１タイプのメッセージ識別子は単調増加する。
【００７３】
本出願の実施例では、前記検出モジュール５０１は、
前記サーバから前記持続的接続を介して送信された第２タイプのメッセージを含むハートビート検出リクエストが受信されたか否かを定期的に検出するためのリクエスト検出ユニットと、
ハートビート検出リクエストが受信されなかった場合、状態検出リクエストを介して、持続的接続が切断状態にあるか否かを検出するための状態検出ユニットとを含む。
【００７４】
本出願の実施例では、前記装置は、
前記サーバから前記持続的接続を介して送信された第２タイプのメッセージを含むハートビート検出リクエストが受信されたか否かを定期的に検出した後、ハートビート検出リクエストが受信された場合、持続的接続が接続状態にあると判定し、受信された第２タイプのメッセージを表示するためのメッセージ表示モジュールを更に含む。
【００７５】
本出願の実施例では、前記装置は、
持続的接続を介して前記サーバから送信された第１タイプのメッセージプロンプト指令を受信するためのプロンプト指令受信モジュールと、
前記第１タイプのメッセージプロンプト指令に応答して、前記サーバから第１タイプのメッセージをプルするためのプロンプト指令応答モジュールとを更に含む。
【００７６】
本出願の実施例では、前記装置は、
ローカルに表示された第１タイプのメッセージ識別子に基づいて、プルされた第１タイプのメッセージをスクリーニング及び／又はソート処理し、処理結果に基づいてプルされた第１タイプのメッセージを表示するための処理モジュールを更に含む。
【００７７】
本出願の実施例では、前記第１タイプのメッセージプロンプト指令は、ライブ配信ルームでの固定トランザクションに応答して生成され、前記固定トランザクションは、投票、投げ銭及び贈り物の少なくとも１つを含む。
【００７８】
本出願の実施例に係るクライアントの所属する電子機器に配置されるライブ配信メッセージ伝送装置は、本出願のいずれかの実施例に係るクライアントによって実行されるライブ配信メッセージ伝送方法を実行可能であり、方法を実行するための対応する機能モジュール及び有益効果を有する。
【００７９】
図９は、本出願の実施例に係るサーバの所属する電子機器に配置されたライブ配信メッセージ伝送装置の構造模式図である。図９を参照し、本出願の実施例に係るサーバが所属する電子機器に配置されるライブ配信メッセージ伝送装置６００において、前記サーバとクライアントとの間に持続的接続が確立されており、前記装置は、リクエスト応答モジュール６０１とメッセージ送信モジュール６０２とを含む。
【００８０】
ここで、リクエスト応答モジュール６０１は、クライアントの持続的接続の確立リクエストに応答して、前記クライアントとの間の持続的接続を再確立するように構成され、前記持続的接続の確立リクエストは、前記クライアントが前記サーバとの間の持続的接続の切断状態を検出した時に生成される。
【００８１】
メッセージ送信モジュール６０２は、前記クライアントに持続的接続の切断期間中の第１タイプのメッセージを送信するように構成される。
【００８２】
本出願の実施例では、前記メッセージ送信モジュール６０２は、具体的には、
表示された第１タイプのメッセージ識別子に基づいてクライアントによって生成された第１タイプのメッセージプルリクエストに応答して、前記クライアントに持続的接続の切断期間中の第１タイプのメッセージを送信するように構成される。
【００８３】
本出願の実施例では、前記第１タイプのメッセージ識別子は単調増加する。
【００８４】
本出願の実施例では、前記装置は、
持続的接続を介して、クライアントに第２タイプのメッセージを含むハートビート検出リクエストを定期的に送信して、クライアントが前記ハートビート検出リクエストを受信しなかった場合、状態検出リクエストを介して、持続的接続が切断状態にあるか否かを検出するように構成されるハートビート検出リクエスト送信モジュールを更に含む。
【００８５】
本出願の実施例では、前記装置は、
クライアントが第１タイプのメッセージプロンプト指令に応答して、前記サーバから第１タイプのメッセージをプルするために、持続的接続を介して、クライアントに第１タイプのメッセージプロンプト指令を送信するように構成されるプロンプト指令送信モジュールを更に含む。
【００８６】
本出願の実施例では、前記第１タイプのメッセージプロンプト指令は、ライブ配信ルームの固定トランザクションに応答して生成され、前記固定トランザクションは、投票、投げ銭及び贈り物の少なくとも１つを含む。
【００８７】
本出願の実施例に係るサーバの所属する電子機器に配置されるライブ配信メッセージ伝送装置は、本出願のいずれかの実施例に係るサーバによって実行されるライブ配信メッセージ伝送方法を実行可能であり、方法を実行するための対応する機能モジュール及び有益効果を有する。
【００８８】
本出願の実施例によれば、本出願は、電子機器及び可読記憶媒体を提供する。
【００８９】
図１０に示すように、本出願の実施例に係るライブ配信メッセージ伝送方法を実行する電子機器のブロック図である。前記電子機器がクライアントによって実行されるライブ配信メッセージ伝送方法を実現する場合、前記電子機器は、例えば携帯電話、タブレット、ウェアラブル装置等の端末装置であってもよい。前記電子機器がサーバによって実行されるライブ配信メッセージ伝送方法を実現する場合、前記電子機器は、サーバ等であってもよい。電子機器は、例えば、ラップトップコンピュータ、デスクトップコンピュータ、ワークステーション、パーソナルデジタルアシスタント、サーバ、ブレードサーバ、メインフレーム、及びその他の適切なコンピュータなどの、様々な形式のデジタルコンピュータを表すことを目的としている。電子機器は、例えばパーソナルデジタル処理、携帯電話、スマートフォン、ウェアラブル装置およびその他の同様のコンピューティングデバイス等の、様々な形式のモバイルデバイスを表すこともできる。明細書に示されているコンポーネント、それらの接続関係、およびそれらの機能は単なる例示であり、ここで説明および／または要求した本出願の実現を限定することを意図したものではない。
【００９０】
図１０に示すように、当該電子機器は、１つ又は複数のプロセッサ７０１、メモリ７０２、及び各コンポーネントを接続するためのインターフェースを含む。インターフェースは高速インターフェース及び低速インターフェースを含む。各コンポーネントは、異なるバスを介して互いに接続されており、共通のマザーボード上に実装されていてもよいし、必要に応じて他の方式で実装されていてもよい。プロセッサは、電子機器内で実行する指令を処理することができ、その指令には、インタフェースに結合される表示装置などの外部入出力装置上にＧＵＩ（ＧＵＩ，Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）のグラフィック情報を表示するための、メモリ内又はメモリ上に格納された指令が含まれる。他の実施形態では、必要がある場合、複数のプロセッサ及び／又は複数のバスを複数のメモリとともに使用することができる。同様に、複数の電子機器が接続されてもよく、各電子機器は一部の必要な動作（例えば、サーバアレイ、一組のブレードサーバ、又はマルチプロセッサシステムとして）を提供する。図１０では１つのプロセッサ７０１を例とする。
【００９１】
メモリ７０２は、本出願に係る非一時的なコンピュータ可読記憶媒体である。ここで、前記メモリには、少なくとも１つのプロセッサによって実行可能な指令が記憶されており、このように、前記少なくとも１つのプロセッサは、本出願に係るクライアントによって実行されるライブ配信メッセージ伝送方法、又は本出願に係るサーバによって実行されるライブ配信メッセージ伝送方法を実行する。本出願の非一時的なコンピュータ可読記憶媒体は、コンピュータに本出願に係るクライアントによって実行されるライブ配信メッセージ伝送方法、又は本出願に係るサーバによって実行されるライブ配信メッセージ伝送方法を実行させるためのコンピュータ指令を記憶する。
【００９２】
メモリ７０２は、非一時的なコンピュータ可読記憶媒体として、非一時的なソフトウェアプログラム、非一時的なコンピュータ実行可能プログラム及びモジュールを記憶することに用いることができ、例えば、本出願の実施例におけるライブ配信メッセージ伝送方法に対応するプログラム指令／モジュール（例えば、図８に示す検出モジュール５０１及び持続的接続確立モジュール５０２、又は図９に示すリクエスト応答モジュール６０１及びメッセージ送信モジュール６０２）を記憶することに用いることができる。プロセッサ７０１は、メモリ７０２に記憶されている非一時的なソフトウェアプログラム、指令及びモジュールを実行することにより、サーバの様々な機能アプリケーション及びデータ処理を実行し、すなわち、上記方法実施例におけるクライアントによって実行されるライブ配信メッセージ伝送方法、又はサーバによって実行されるライブ配信メッセージ伝送方法を実現する。
【００９３】
メモリ７０２は、プログラム記憶領域及びデータ記憶領域を含んでもよい。プログラム記憶領域は、オペレーティングシステム、少なくとも１つの機能に必要なアプリケーションプログラムを記憶することができる。データ記憶領域は、ライブ配信メッセージ伝送のための電子機器の使用により作成されたデータ等を記憶することができる。なお、メモリ７０２は、高速ランダムアクセスメモリを含んでもよく、更に、例えば少なくとも１つの磁気ディスク記憶装置、フラッシュ記憶装置、又は他の非一時的ソリッドステート記憶装置などの非一時的なメモリを含んでもよい。いくつかの実施例では、メモリ７０２は、プロセッサ７０１に対して遠隔的に設置されたリモートメモリを含んでもよく、これらのリモートメモリは、ネットワークを介してライブ配信メッセージ伝送のための電子機器に接続されることができる。上記ネットワークの例には、インターネット、企業イントラネット、ローカルエリアネットワーク、移動体通信網およびそれらの組み合わせが含まれるが、これらに限定されない。
【００９４】
ライブ配信メッセージ伝送方法の電子機器は、入力デバイス７０３及び出力デバイス７０４を更に含んでもよい。プロセッサ７０１、メモリ７０２、入力デバイス７０３及び出力デバイス７０４は、バスまたは他の方法で接続することができる。図１０では、バスによる接続を例とする。
【００９５】
入力デバイス７０３は、入力された数字又は文字情報を受信し、ライブ配信メッセージ伝送のための電子機器のユーザ設定及び機能制御に関連するキー信号入力を生成することができる。例えばタッチパネル、キーパッド、マウス、トラックパッド、タッチパッド、ポインティングスティック、１つまたは複数のマウスボタン、トラックボール、ジョイスティックなどの入力デバイスが挙げられる。出力デバイス７０４は、表示装置、補助照明装置（例えば、ＬＥＤ）及び触覚フィードバック装置（例えば、振動モータ）などを含んでもよい。当該表示装置は、液晶ディスプレイ（ＬＣＤ）、発光ダイオード（ＬＥＤ）ディスプレイ及びプラズマディスプレイを含んでもよいが、これらに限定されない。いくつかの実施形態では、表示装置はタッチパネルであってもよい。
【００９６】
本明細書に記載のシステム及び技術の様々な実施形態は、デジタル電子回路システム、集積回路システム、専用ＡＳＩＣ（特定用途向け集積回路）、コンピュータハードウェア、ファームウェア、ソフトウェア、及び／又はそれらの組み合わせで実現することができる。これらの様々な実施形態は１つ又は複数のコンピュータプログラムにおける実装形態を含むことができ、当該１つ又は複数のコンピュータプログラムは、少なくとも１つのプログラマブルプロセッサを含むプログラマブルシステム上で実行可能及び／又は解釈可能であり、当該プログラマブルプロセッサは、専用又は汎用のプログラマブルプロセッサであってもよく、ストレージシステム、少なくとも１つの入力デバイス、及び少なくとも１つの出力デバイスからデータ及び指令を受信し、且つデータ及び指令を当該ストレージシステム、当該少なくとも１つの入力デバイス、及び当該少なくとも１つの出力デバイスに伝送することができる。
【００９７】
これらのコンピュータプログラムは、プログラム、ソフトウェア、ソフトウェアアプリケーション又はコードとも呼ばれ、プログラマブルプロセッサの機械命令を含み、且つ高度プロセス及び／又はオブジェクト指向のプログラミング言語、及び／又はアセンブリ言語／機械語を利用して実装することができる。ここで、「機械可読媒体」及び「コンピュータ可読媒体」という用語は、機械命令及び／又はデータをプログラマブルプロセッサに供給するための任意のコンピュータプログラム製品、装置、及び／又はデバイス（たとえば、磁気ディスク、光ディスク、メモリ、プログラマブルロジックデバイス（ＰＬＤ））を意味し、機械可読信号である機械命令を受信する機械可読媒体を含む。「機械可読信号」という用語は、機械命令および／またはデータをプログラマブルプロセッサに供給するための任意の信号を意味する。
【００９８】
ユーザとのインタラクションを提供するために、ここで説明するシステムと技術は、ユーザに情報を表示するための表示装置（例えば、陰極線管（Ｃａｔｈｏｄｅ  Ｒａｙ  Ｔｕｂｅ，ＣＲＴ）またはＬＣＤ（液晶ディスプレイ）モニタ）と、キーボード及びポインティングデバイス（例えば、マウスまたはトラックボール）とを備えるコンピュータ上で実現することができ、ユーザが該キーボード及び該ポインティングデバイスを介してコンピュータに入力を提供できる。他の種類の装置は、さらにユーザとのインタラクションを提供することに用いることができる。例えば、ユーザに提供されるフィードバックは、例えば、視覚フィードバック、聴覚フィードバック、又は触覚フィードバックのような任意の形態のセンシングフィードバックであってもよく、且つ音の入力、音声入力又は、触覚入力を含む任意の形態でユーザからの入力を受信してもよい。
【００９９】
ここで説明されるシステム及び技術は、バックエンドコンポーネントを含むコンピューティングシステム（例えば、データサーバとする）、又はミドルウェアコンポーネントを含むコンピューティングシステム（例えば、アプリケーションデータサーバ）、又はフロントエンドコンポーネントを含むコンピューティングシステム（例えば、グラフィカルユーザインターフェイス又はウェブブラウザを有するユーザコンピュータが挙げられ、ユーザは、当該グラフィカルユーザインターフェイス又は当該ウェブブラウザにより、ここで説明されるシステム及び技術の実施形態と対話することができる）、又はそのようなバックエンド、ミドルウェア、またはフロントエンドコンポーネントの任意の組合せを含むコンピューティングシステムにおいて実施することができる。任意の形式または媒体のデジタルデータ通信（例えば、通信網）によってシステムのコンポーネントを相互接続することができる。通信網の例は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、及びインターネットを含む。
【０１００】
コンピュータシステムは、クライアント及びサーバを含んでもよい。クライアントとサーバは、一般に互いに離れており、通常に通信網を介してインタラクションする。クライアントとサーバとの関係は、互いにクライアント−サーバ関係を有するコンピュータプログラムを対応するコンピュータ上で実行させることによって生じる。
【０１０１】
本出願の実施例の技術的解決手段によれば、ライブ配信際の持続的接続の切断期間中にメッセージを正常に伝送できないことにより、メッセージの欠落または不正確な伝送をもたらすという問題を回避することができ、それによって、ライブ配信期間のメッセージを正確に取得することができる。
【０１０２】
なお、上述した様々な形態のフローを用いて、ステップを並び替え、追加または削除を行うことができることを理解されるべきである。例えば、本出願に記載の各ステップは、本出願に開示された技術的解決手段の所望の結果が達成できる限り、並行して実行されてもよく、順番に実行されてもよく、異なる順序で実行されてもよい。本明細書はここで制限はしない。
【０１０３】
上記具体的な実施形態は、本出願の保護範囲を限定するものではない。当業者であれば、設計要件および他の要因に応じて、様々な修正、組み合わせ、副次的な組み合わせ、および代替を行うことができることは理解される。本出願の精神および原理内で行われたあらゆる補正、均等な置換および改善などは、いずれも本出願の保護範囲内に含まれるべきである。
【図１】
2022003510.tif 000003
【図２】
2022003510.tif 000004
【図３】
2022003510.tif 000005
【図４】
2022003510.tif 000006
【図５】
2022003510.tif 000007
【図６】
2022003510.tif 000008
【図７】
2022003510.tif 000009
【図８】
2022003510.tif 000010
【図９】
2022003510.tif 000011
【図１０】
2022003510.tif 000012
【外国語明細書】
2022003510000001.pdf