JP6091545B2 - メッセージ・ストリーム・インテグリティ - Google Patents

メッセージ・ストリーム・インテグリティ Download PDF

Info

Publication number
JP6091545B2
JP6091545B2 JP2015104809A JP2015104809A JP6091545B2 JP 6091545 B2 JP6091545 B2 JP 6091545B2 JP 2015104809 A JP2015104809 A JP 2015104809A JP 2015104809 A JP2015104809 A JP 2015104809A JP 6091545 B2 JP6091545 B2 JP 6091545B2
Authority
JP
Japan
Prior art keywords
message
sequence number
data
new
phase number
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2015104809A
Other languages
English (en)
Other versions
JP2015172963A (ja
Inventor
エリカ・ジョアン・グラント・ブラッドニック
レスリー・マイケル・ブロディ
スコット・エフ・シンガー
Original Assignee
トレーディング テクノロジーズ インターナショナル インコーポレイテッド
トレーディング テクノロジーズ インターナショナル インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by トレーディング テクノロジーズ インターナショナル インコーポレイテッド, トレーディング テクノロジーズ インターナショナル インコーポレイテッド filed Critical トレーディング テクノロジーズ インターナショナル インコーポレイテッド
Publication of JP2015172963A publication Critical patent/JP2015172963A/ja
Application granted granted Critical
Publication of JP6091545B2 publication Critical patent/JP6091545B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/06Asset management; Financial planning or analysis
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1642Formats specially adapted for sequence numbers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823Errors, e.g. transmission errors
    • H04L43/0847Transmission error
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/10Active monitoring, e.g. heartbeat, ping or trace-route

Description

ネットワークを介して送信されるメッセージは、一般的に、1つのデバイスから別のデバイスへ送信され、送り先のデバイスで受信したときに取り出される内容を含んでいる。続いて、様々な処理動作がその内容に基づいて行われる。
イベントは、メッセージの内容次第であるため、メッセージ・ストリームのインテグリティを保持することが望ましい。特に、ロスト・メッセージを検出及びメッセージ・ストリーム・データの低減の達成が可能であることは、特に有益である。そのようなロスト・メッセージの検出及びメッセージ・ストリーム・データの低減の1つの応用分野は、特に関連するもので電子取引の分野である。
特定の実施形態は、以下の図面を参照して開示されている。
図1は、特定の実施形態に係るコンピュータデバイスのブロック図を示す。 図2Aは、一定間隔手法を用いたハートビートを使用するメッセージ例を示す。 図2Bは、増大間隔手法を用いたハートビートを使用するメッセージ例を示す。 図2Cは、図2A―2Bに係るメッセージの送信方法の例のフロー図を示す。 図2Dは、図2A―2Bに係るメッセージの受信方法の例のフロー図を示す。 図3Aは、増大間隔手法を用いたハートビートを利用するメッセージの例を示す。 図3Bは、ストップ・メッセージ手法を利用するメッセージの例を示す。 図3Cは、ストップ・メッセージを使用するメッセージの例を示す。 図3Dは、ストップ・メッセージを使用するメッセージの例を示す。 図3Eは、ストップ・メッセージ及びメッセージ・ストリーム・クリアリングを使用するメッセージの例を示す。 図3Fは、ストップ・メッセージ、メッセージ・ストリーム・クリアリング、及びフェーズ番号を使用するメッセージの例を示す。 図3Gは、ストップ・メッセージ、メッセージ・ストリーム・クリアリング、及びフェーズ番号を使用するメッセージの例を示す。 図3Hは、ストップ・メッセージ、メッセージ・ストリーム・クリアリング、及びフェーズ番号を使用するメッセージの例を示す。 図4は、特定の実施形態に係るフェーズ番号を使用するメッセージの送信方法の例のフロー図を示す。 図5は、特定の実施形態に係るフェーズ番号を使用するメッセージの受信方法の例のフロー図を示す。 図6は、特定の実施形態に係る送信デバイスの例のブロック図を示す。 図7は、特定の実施形態に係る受信デバイスの例のブロック図を示す。 図8は、特定の実施形態が採用され得る電子取引システムのブロック図を示す。 図9は、図8の電子取引システムの例のブロック図を示す。
特定の実施形態は、例で示され、提供された図面と共に読むとき、より良く理解されるであろう。なお、実施形態は、添付図面に示す構成及び手段に限定されないことを理解するべきである。
メッセージ・ストリームは、関連するメッセージの論理通信チャンネルである。ロスト・メッセージ、特にデータを含むそれらのメッセージの検出は、メッセージ・ストリーム・インテグリティを向上させる。メッセージが失われた場合、様々な動作、例えば、ロスト・メッセージの再送信の要求、メッセージ・ストリームの終了又はリセット、ログファイルにエントリの作成、エラーメッセージの提供、割り込みの生成、ロスト・メッセージについての受信データを処理するアプリケーション又は高レベルプロトコルへの警告、プログラムの実行の中止、メッセージが失われたことを1人以上のユーザへの通知、メッセージ・ストリームの終了と新しいメッセージ・ストリームの確立、ライセンスのリリースと再取得、サーバの再認証、及び/又は完全なデータセットの再ダウンロードなどの動作がとられてもよい。
また、ステート情報が、メッセージ・ストリーム及びメッセージ・ストリーム・インテグリティを保持するために記憶される必要がある。ステート情報は、送信デバイス、受信デバイス、及び中間デバイスに記憶されてもよい。このステート情報は、メモリなどの限られたリソースを消費してもよい。これにより、メッセージ・ストリームのために記憶する必要があるステート情報を減らすことが望ましい。
ロスト・メッセージを検出するため、いくつかの現在のシステムは、各メッセージにおいて所定の量増大するシーケンス番号又はメッセージ識別器を使用し、受信者が、送信されたメッセージの順番と、どのメッセージが失われたかと、の両方を決定してもよい。なお、メッセージの送信頻度が低い場合、ロスト・メッセージが検出される前に許容できない遅延が生じることがある。
いくつかの現在のシステムは、ハートビートを利用し、ロスト・メッセージの検出の可能性を高めている。ハートビート・メッセージは、一定の間隔で送信され、妥当な時間内にロスト・メッセージを検出する。しかしながら、多数のハートビート・メッセージの送信は、限られたネットワーク帯域幅の使用を非効率にし、及び/又はネットワーク上の他のデータ・メッセージの配信のための待ち時間を増やすことがある。
開示された実施形態は、ロスト・メッセージを検出し、メッセージ・ストリームのために記憶されたステート情報を減らすことによって、メッセージ・ストリーム・インテグリティを向上させる技術に関する。いくつかの実施形態では、増大間隔手法を用いたハートビートが使用され、ハートビート・メッセージによるネットワーク・トラフィックを低減しつつ、ロスト・メッセージの検出の可能性を高めている。いくつかの実施形態では、ストップ・メッセージ手法が実施され、過度の非データ・ネットワーク・トラフィックを低減しつつ、ロスト・メッセージの検出の可能性を高めている。いくつかの実施形態では、メッセージ・ストリーム・ステート・クリアリング手法が実施され、メッセージ・ストリームのために記憶されたステート情報を減らし、メモリの使用量を減らしている。いくつかの実施形態では、フェーズ番号手法が実施され、ロスト・メッセージの検出の可能性を高めている。
以下は、他の構成要素のうち、ハードウェア上で実行されるソフトウェアを含む実施形態を開示しているが、実施形態は単なる例示であり、限定とみなされるべきではないことに留意すべきである。例えば、いずれか又はこれらのすべてのハードウェア及びソフトウェアコンポーネントが、ハードウェアのみに、ソフトウェアのみに、ファームウェアのみに、又はハードウェア、ソフトウェア、及び/又はファームウェアのいくつかの組み合わせで実施されてもよいことが想定される。したがって、開示された実施形態は、他の方法で実施されてもよい。
I.簡単な説明
特定の実施形態は、コンピュータデバイスが、第1のデータ・メッセージを送信するステップ、コンピュータデバイスが、第1のストップ・メッセージを送信するステップ、及びコンピュータデバイスが、第2のデータ・メッセージを送信するステップ、を含む方法を提供する。第1のデータ・メッセージは、所定の初期シーケンス番号の値を有する第1のデータ・メッセージ・シーケンス番号を含む。第1のデータ・メッセージは、第1のデータ・メッセージ・フェーズ番号を含む。第1のストップ・メッセージは、ストップ・メッセージ・フェーズ番号を含む。ストップ・メッセージ・フェーズ番号は、第1のデータ・メッセージ・フェーズ番号と同じである。第2のデータ・メッセージは、第1のストップ・メッセージの後に送信される。第2のデータ・メッセージは、所定の初期シーケンス番号の値を有する第2のデータ・メッセージ・シーケンス番号を含む。第2のデータ・メッセージは、第2のデータ・メッセージ・フェーズ番号を含む。第2のデータ・メッセージ・フェーズ番号は、第1のデータ・メッセージ・フェーズ番号と異なる。いくつかの実施形態では、第1のデータ・メッセージ及び第2のデータ・メッセージは、取引可能オブジェクトの注文に関連するデータを含んでもよい。
特定の実施形態は、命令を含む有形のコンピュータ読み取り可能な記録媒体であって、命令は、実行されるとき、コンピュータデバイスに少なくとも第1のデータ・メッセージを送信させ、第1のストップ・メッセージを送信させ、及び第2のデータ・メッセージを送信させる、コンピュータ読み取り可能な記録媒体を提供する。第1のデータ・メッセージは、所定の初期シーケンス番号の値を有する第1のデータ・メッセージ・シーケンス番号を含む。第1のデータ・メッセージは、第1のデータ・メッセージ・フェーズ番号を含む。第1のストップ・メッセージは、ストップ・メッセージ・フェーズ番号を含む。ストップ・メッセージ・フェーズ番号は、第1のデータ・メッセージ・フェーズ番号と同じである。第2のデータ・メッセージは、第1のストップ・メッセージの後に送信される。第2のデータ・メッセージは、所定の初期シーケンス番号の値を有する第2のデータ・メッセージ・シーケンス番号を含む。第2のデータ・メッセージは、第2のデータ・メッセージ・フェーズ番号を含む。第2のデータ・メッセージ・フェーズ番号は、第1のデータ・メッセージ・フェーズ番号と異なる。いくつかの実施形態では、第1のデータ・メッセージ及び第2のデータ・メッセージは、取引可能オブジェクトの注文に関連するデータを含んでもよい。
特定の実施形態は、第1のデータ・メッセージを送信する第1のデータ・メッセージ送信機、第1のストップ・メッセージを送信する第1のストップ・メッセージ送信機、及び第2のデータ・メッセージを送信する第2のデータ・メッセージ送信機、を含むシステムを提供する。第1のデータ・メッセージは、所定の初期シーケンス番号の値を有する第1のデータ・メッセージ・シーケンス番号を含む。第1のデータ・メッセージは、第1のデータ・メッセージ・フェーズ番号を含む。第1のストップ・メッセージは、ストップ・メッセージ・フェーズ番号を含む。ストップ・メッセージ・フェーズ番号は、第1のデータ・メッセージ・フェーズ番号と同じである、第2のデータ・メッセージは、第1のストップ・メッセージの後に送信される。第2のデータ・メッセージは、所定の初期シーケンス番号の値を有する第2のデータ・メッセージ・シーケンス番号を含む。第2のデータ・メッセージは、第2のデータ・メッセージ・フェーズ番号を含む。第2のデータ・メッセージ・フェーズ番号は、第1のデータ・メッセージ・フェーズ番号と異なる。いくつかの実施形態では、第1のデータ・メッセージ及び第2のデータ・メッセージは、取引可能オブジェクトの注文に関連するデータを含んでもよい。
特定の実施形態は、メッセージにフェーズ番号を提供するフェーズ番号生成器、メッセージにシーケンス番号を提供するシーケンス番号生成器、第1のデータ・メッセージを送信する第1のデータ・メッセージ送信機、第1のストップ・メッセージを送信する第1のストップ・メッセージ送信機、及び第2のデータ・メッセージを送信する第2のデータ・メッセージ送信機、を含むシステムを提供する。第1のデータ・メッセージは、フェーズ番号生成器によって提供される所定の初期シーケンス番号を有する第1のデータ・メッセージ・シーケンス番号を含む。第1のデータ・メッセージは、フェーズ番号生成器によって提供される第1のデータ・メッセージ・フェーズ番号を含む。第1のストップ・メッセージは、フェーズ番号生成器によって提供されるストップ・メッセージ・フェーズ番号を含む。ストップ・メッセージ・フェーズ番号は、第1のデータ・メッセージ・フェーズ番号と同じである。第2のデータ・メッセージは、第1のストップ・メッセージの後に送信される。第2のデータ・メッセージは、シーケンス番号生成器によって提供される所定のシーケンス番号の値を有する第2のデータ・メッセージ・シーケンス番号を含む。第2のデータ・メッセージは、フェーズ番号生成器によって提供される第2のデータ・メッセージ・フェーズ番号を含む。第2のデータ・メッセージ・フェーズ番号は、第1のデータ・メッセージ・フェーズ番号と異なる。いくつかの実施形態では、第1のデータ・メッセージ及び第2のデータ・メッセージは、取引可能オブジェクトの注文に関連するデータを含んでもよい。
特定の実施形態は、コンピュータデバイスが、送信されるべき新しいメッセージを検出するステップ、コンピュータデバイスが、新しいメッセージのフェーズ番号を決定するステップ、コンピュータデバイスが、新しいメッセージのシーケンス番号を決定するステップ、及びコンピュータデバイスが、フェーズ番号とシーケンス番号とを有する新しいメッセージを送信するステップ、を含む方法を提供する。
特定の実施形態は、命令を含む有形のコンピュータ読み取り可能な記録媒体であって、命令は、実行されるとき、コンピュータデバイスに少なくとも送信されるべき新しいメッセージを検出させ、新しいメッセージのフェーズ番号を決定させ、新しいメッセージのシーケンス番号を決定させ、及びフェーズ番号とシーケンス番号とを有する新しいメッセージを送信させる、コンピュータ読み取り可能な記録媒体を提供する。
特定の実施形態は、送信されるべき新しいメッセージを検出する新しいメッセージ検出器、新しいメッセージのフェーズ番号を決定するフェーズ番号生成器、新しいメッセージのシーケンス番号を決定するシーケンス番号生成器、及びフェーズ番号とシーケンス番号とを有する新しいメッセージを送信するメッセージ送信機、を含むシステムを提供する。
特定の実施形態は、コンピュータデバイスが、メッセージ・フェーズ番号とメッセージ・シーケンス番号とを含む新しいメッセージを受信するステップ、コンピュータデバイスが、新しいメッセージの予想フェーズ番号を決定するステップ、コンピュータデバイスが、新しいメッセージの予想シーケンス番号を決定するステップ、コンピュータデバイスが、メッセージ・フェーズ番号を予想フェーズ番号と比較するステップ、コンピュータデバイスが、メッセージ・シーケンス番号を予想シーケンス番号と比較するステップ、及びコンピュータデバイスが、(a)メッセージ・フェーズ番号と予想フェーズ番号、(b)メッセージ・シーケンス番号と予想シーケンス番号の少なくとも一方がマッチしないとき、ロスト・メッセージを報知するステップ、を含む方法を提供する。
特定の実施形態は、命令を含む有形のコンピュータ読み取り可能な記録媒体であって、命令は、実行されるとき、コンピュータデバイスに少なくとも、メッセージ・フェーズ番号とメッセージ・シーケンス番号とを含む新しいメッセージを受信させ、新しいメッセージの予想フェーズ番号を決定させ、新しいメッセージの予想シーケンス番号を決定させ、メッセージ・フェーズ番号を予想フェーズ番号と比較させ、メッセージ・シーケンス番号を予想シーケンス番号と比較させ、及び(a)メッセージ・フェーズ番号と予想フェーズ番号、(b)メッセージ・シーケンス番号と予想シーケンス番号の少なくとも一方がマッチしないとき、ロスト・メッセージを報知する、コンピュータ読み取り可能な記録媒体を提供する。
特定の実施形態は、メッセージ・フェーズ番号とメッセージ・シーケンス番号とを含む新しいメッセージを受信するメッセージ受信機、新しいメッセージの予想フェーズ番号を決定する予想フェーズ番号生成器、新しいメッセージの予想シーケンス番号を決定する予想シーケンス番号生成器、メッセージ・フェーズ番号を予想フェーズ番号と比較するフェーズ番号比較器、メッセージ・シーケンス番号を予想シーケンス番号と比較するシーケンス番号比較器、及び(a)メッセージ・フェーズ番号と予想フェーズ番号、(b)メッセージ・シーケンス番号と予想シーケンス番号の少なくとも一方がマッチしないとき、ロスト・メッセージを報知するロスト・メッセージ報知機、を含むシステムを提供する。
特定の実施形態は、コンピュータデバイスが、第1のメッセージを送信するステップ、コンピュータデバイスが、第1のハートビート・メッセージを送信するステップ、コンピュータデバイスが、第2のハートビート・メッセージを送信するステップ、を含む方法を提供する。第1のハートビート・メッセージは、第1のデータ・メッセージが送信された後、第1の時間間隔で送信される。第1の時間間隔は、所定の長さである。第2のハートビート・メッセージは、第1のハートビート・メッセージが送信された後、第2の時間間隔で送信される。第2の時間間隔は、第1の時間間隔より増加させる。
特定の実施形態は、命令を含む有形のコンピュータ読み取り可能な記録媒体であって、命令は、実行されるとき、コンピュータデバイスに少なくとも第1のメッセージを送信させ、第1のハートビート・メッセージを送信させ、及び第2のハートビート・メッセージを送信させる、コンピュータ読み取り可能な記録媒体を提供する。第1のハートビート・メッセージは、第1のデータ・メッセージが送信された後、第1の時間間隔で送信される。第1の時間間隔は、所定の長さである。第2のハートビート・メッセージは、第1のハートビート・メッセージが送信された後、第2の時間間隔で送信される。第2の時間間隔は、第1の時間間隔より増加させる。
特定の実施形態は、第1のデータ・メッセージを送信する第1のデータ・メッセージ送信機、第1のハートビート・メッセージを送信する第1のハートビート・メッセージ送信機、及び第2のハートビート・メッセージを送信する第2のハートビート・メッセージ送信機、を含むシステムを提供する。第1のハートビート・メッセージは、第1のデータ・メッセージが送信された後、第1の時間間隔で送信される。第1の時間間隔は、所定の長さである。第2のハートビート・メッセージは、第1のハートビート・メッセージが送信された後、第2の時間間隔で送信される。第2の時間間隔は、第1の時間間隔より増加させる。
特定の実施形態は、コンピュータデバイスが、第1のデータ・メッセージを送信するステップ、及びコンピュータデバイスが、第1のストップ・メッセージを送信するステップ、を含む方法を提供する。
特定の実施形態は、命令を含む有形のコンピュータ読み取り可能な記録媒体であって、命令は、実行されるとき、コンピュータデバイスに少なくとも第1のデータ・メッセージを送信させ、及び第1のストップ・メッセージを送信させる、コンピュータ読み取り可能な記録媒体。
特定の実施形態は、第1のデータ・メッセージを送信する第1のデータ・メッセージ送信機、及び第1のストップ・メッセージを送信する第1のストップ・メッセージ送信機、を含むシステムを提供する。
特定の実施形態は、コンピュータデバイスが、シーケンス番号とフェーズ番号とを含むメッセージを送信するステップを含む方法を提供する。
特定の実施形態は、命令を含む有形のコンピュータ読み取り可能な記録媒体であって、命令は、実行されるとき、コンピュータデバイスに少なくともシーケンス番号とフェーズ番号とを含むメッセージを送信させる、コンピュータ読み取り可能な記録媒体を提供する。
特定の実施形態は、シーケンス番号とフェーズ番号とを含むメッセージを送信するメッセージ送信機を含むシステムを提供する。
特定の実施形態は、コンピュータデバイスが、シーケンス番号とフェーズ番号とを含むメッセージを受信するステップ、及びコンピュータデバイスが、シーケンス番号とフェーズ番号とに基づき、ロスト・メッセージを報知するステップ、を含む方法を提供する。
特定の実施形態は、命令を含む有形のコンピュータ読み取り可能な記録媒体であって、命令は、実行されるとき、コンピュータデバイスに少なくともシーケンス番号とフェーズ番号とを含むメッセージを受信させ、及びシーケンス番号とフェーズ番号とに基づき、ロスト・メッセージを報知させる、コンピュータ読み取り可能な記録媒体を提供する。
特定の実施形態は、シーケンス番号とフェーズ番号とを含むメッセージを受信するメッセージ受信機、及びシーケンス番号とフェーズ番号に基づき、ロスト・メッセージを報知するロスト・メッセージ報知機、を含むシステムを提供する。
II.コンピュータデバイスの例
図1は、開示された実施形態を実施するために使用され得るコンピュータデバイス100の例のブロック図を示す。1つ以上のコンピュータデバイス100は、例えば、多くの別のデバイスから送受信されるデータを処理するように構成された端末コンピュータ又はサーバ・コンピュータに実装されてもよい。
コンピュータデバイス100は、プロセッサ102、相互接続バス104、チップセット106、メモリコントローラ108、入力/出力(I/O)コントローラ110、システムメモリ112、大容量記憶メモリ114、I/Oバス116、ネットワークインタフェース118、ディスプレイ120、入力デバイス122、及び出力デバイス124を含む。コンピュータデバイス100は、追加の、異なる、又はより少ない構成要素を含んでもよい。例えば、複数のバス、複数のプロセッサ、複数のメモリデバイス、複数のネットワークインタフェース、複数のディスプレイデバイス、複数の入力デバイス、複数の出力デバイス、又はそれらの任意の組み合わせが、提供されてもよい。別の例として、コンピュータデバイス100は、ディスプレイデバイス120と別の出力デバイス124を含まなくてもよい。別の例として、コンピュータデバイス100は、ディスプレイデバイス120を含まなくてもよい。別の例として、コンピュータデバイス100は、入力デバイス122を含まなくてもよい。代わりに、例えば、コンピュータデバイス100は、ネットワークインタフェース118を介して外部の又はリモートの入力デバイスによって制御されてもよい。
コンピュータデバイス100は、相互接続バス104と接続されるプロセッサ102を含む。相互接続バス104は、通信バス、チャンネル、ネットワーク、回路、スイッチ、ファブリック、又はコンピュータデバイス100の構成要素との間でデータを通信するための他の機構を含んでもよい。相互接続バス104は、コンピュータデバイス100のいくつかの構成要素と通信可能に接続され、データを転送してもよい。例えば、アプリケーションのインストールプロセス中に、プロセッサ102によって実行されるべき1つ以上のコンピュータ読み取り可能な命令が、入力デバイス122及び/又はネットワークインタフェース118から、システムメモリ112及び/又は大容量記憶メモリ114に転送されてもよい。コンピュータデバイス100がシステムメモリ112及び/又は大容量記憶メモリ114に記憶されたアプリケーションを実行しているとき、又は実行の準備をしているとき、プロセッサ102は、システムメモリ112及び/又は大容量記憶メモリ114から、相互接続バス104を介して命令を取り出してもよい。
プロセッサ102は、例えば、プロセッサ、処理ユニット、又はマイクロプロセッサであってもよい。プロセッサ102は、例えば、1つ以上の一般的なプロセッサ、デジタル信号プロセッサ、特定用途向け集積回路、フィールド・プログラマブル・ゲート・アレイ、アナログ回路、デジタル回路、プログラムされたプロセッサ、及び/又はそれらの組合せを含んでもよい。プロセッサ102は、単一のデバイス又は、ネットワーク若しくは分散処理に関連付けられた1つ以上のデバイスなどのデバイスの組み合わせであってもよい。いくつかの処理戦略では、例えば、マルチ処理、マルチタスク、並行処理、及び/又はリモート処理などが使用されてもよい。処理は、ローカル又はリモートであってもよく、1つのプロセッサから別のプロセッサに移動されてもよい。コンピュータデバイス100は、マルチプロセッサシステムであってもよく、そして相互接続バス104に通信可能に接続される1つ以上の追加のプロセッサを含んでいてもよい。
プロセッサ102は、1つ以上の有形メディア、例えば、システムメモリ112、大容量記憶メモリ114などで、及び/又はネットワークインタフェース118を介して、エンコードされたロジックを実行するように動作可能であってもよい。本明細書で使用されているように、1つ以上の有形メディアにエンコードされたロジックは、プロセッサ102又は別のプロセッサによって実行可能な命令を含んでいる。ロジックは、例えば、ソフトウェア、ハードウェア、集積回路、ファームウェア、及び/又はマイクロコードの一部として記憶されてもよい。ロジックは、外部の通信デバイスから、例えば、インターネットに接続された通信ネットワークを介して受信されてもよい。プロセッサ102は、ロジックを実行し、図に示され、若しくは本明細書に記載された機能、動作、又はタスクを行ってもよい。
図1のプロセッサ102は、メモリコントローラ108とI/Oコントローラ110とを含むチップセット106に接続されている。チップセットは、通常、I/O及びメモリ管理機能、並びに汎用及び/又は特殊用途レジスタ、及びアクセス可能であり、又はチップセット106に接続された1つ以上のプロセッサによって使用されるタイマーを提供する。メモリコントローラ108は、プロセッサ102(又はマルチプロセッサの場合に複数のプロセッサ)をシステムメモリ112と大容量記憶メモリ114にアクセス可能にする機能を実行する。
システムメモリ112と大容量記憶メモリ114は、例えば、1つ以上の有形メディア、例えば、コンピュータ読み取り可能な記録媒体であってもよい。システムメモリ112は、様々なタイプの揮発性及び不揮発性記録媒体を含んでもよく、例えば、ランダム・アクセス・メモリ(RAM)、リード・オンリー・メモリ(ROM)、プログラマブル・リード・オンリー・メモリ(PROM)、電気的プログラマブル・リード・オンリー・メモリ(PROM)、電気的に消去可能なリード・オンリー・メモリ(EPROM)、フラッシュメモリ、いくつかの他の有形データ記憶デバイス、それらのいくつかの組み合わせを含む。大容量記憶メモリ114は、様々なタイプの大容量記憶デバイスを含んでもよく、例えば、ハードディスクドライブ、光学メディア、磁気テープ、いくつかの他の有形データ記憶デバイス、又はそれらのいくつかの組み合わせを含む。特定の実施形態では、システムメモリ112と大容量記憶メモリ114は、非一時的である。
システムメモリ112と大容量記憶メモリ114は、例えば、単一のメモリモジュールであってもよい。システムメモリ112と大容量記憶メモリ114は、プロセッサ102に隣接し、の一部であり、にプログラムされ、にネットワーク接続され、及び/又はから離れており、システムメモリ112と大容量記憶メモリ114に記憶されたデータは、例えば、プロセッサ102によって取り出され、処理されるようになっている。命令が実行され、本明細書で記載されている、若しくは図に示されている動作又は機能のうち1つ以上を行ってもよい。
I/Oコントローラ110は、機能を実行し、プロセッサ102が、I/Oバス116を通って、ネットワークインタフェース118、ディスプレイ120、入力デバイス122、及び出力デバイス124と通信可能になる。メモリコントローラ108とI/Oコントローラ110は、チップセット106内に、別のブロックとして図1に示されているが、これらのブロックによって実行される機能は、単一の半導体回路内に統合されてもよく、又は2つ以上の別の集積回路を使用して実現されてもよい。コンピュータデバイス100の構成要素の1つ以上は、チップ上のシステム(例えば、IPHONE(商標)のチップ上のシステム)として実現されてもよい。
ネットワークインタフェース118は、一方向又は双方向の通信接続であってもよい。したがって、ネットワークインタフェース118は、1つ、2つ、又はそれ以上の通信ネットワーク又はデバイスに通信可能に接続されてもよい。例えば、相互接続バス104は、ネットワークインタフェース118を介して、サーバと接続されてもよく、1つ、いくつか、すべてのコンピュータデバイス100の構成要素がアクセス可能であり、又はサーバと通信するようになっている。別の例として、ネットワークインタフェース118は、他の通信接続を有する相互接続バス104に接続されてもよい。ネットワークインタフェース118は、例えば、総合デジタル通信網(ISDN)カード又はデータ通信接続を提供するモデムであってもよい。別の例として、ネットワークインタフェース118は、ローカル・エリア・ネットワーク(LAN)カードであってもよく、データ通信接続を、例えば、インターネットに接続された互換性のあるLANに提供する。無線リンクも実装されてもよい。ネットワークインタフェース118は、例えば、様々な種類の情報を表すアナログ又はデジタル・データ・ストリームを伝送する電気、電磁気、又は光信号を送受信してもよい。
ディスプレイデバイス120は、例えば、ビジュアル・アウトプット・デバイス、ブラウン管(CRT)ディスプレイ、電子ディスプレイ、電子ペーパー、フラットパネルディスプレイ、発光ダイオード(LED)ディスプレイ、エレクトロルミネッセント・ディスプレイ(ELD)、プラズマ・ディスプレイ・パネル(PDP)、液晶ディスプレイ(LCD)、薄膜トランジスタ・ディスプレイ(TFT)、有機発光ダイオード・ディスプレイ(OLED)、表面伝導型電子放出素子ディスプレイ(SED)、レーザテレビ、カーボンナノチューブ、ナノ液晶ディスプレイ、ヘッドマウント・ディスプレイ、プロジェクタ、3次元ディスプレイ、及び/又は透明ディスプレイデバイスを含んでもよい。
ディスプレイデバイス120は、画面を表示し、インタラクティブにユーザがデータを入力できるようになっている。
入力デバイス122は、例えば、キーボード、マウス、マイクロフォン、タッチスクリーン、トラックボール、キーパッド、ジョイスティック、及び/又は入力を提供するための他のデバイスを含んでもよい。入力デバイス122は、例えば、プロセッサ102にコマンド選択を提供するように使用されてもよい。例えば、入力デバイス122は、画面に表示されたカーソルを制御するように使用されるマウスであってもよい。マウスは、例えば、選択と制御をするための1つ以上のボタンを含んでもよい。
出力デバイス124は、例えば、キーボード、マウス、スピーカー、タッチスクリーン、トラックボール、キーパッド、触覚デバイス又はシステム、ジョイスティック、及び/又は出力を提供するための他のデバイスを含んでもよい。例えば、出力デバイス124は、1つ以上の信号、例えば、触覚信号又は音声信号、をユーザに出力するように使用されてもよい。入力デバイス122と出力デバイス124は、別のブロックとして図1に示されているが、これらのブロックによって実行される機能は、単一のI/Oデバイスに統合されてもよい。
III.メッセージ・ストリーム・インテグリティ技術
ユーザは、最新かつ正確に送信及び配信されたメッセージを信頼し、情報に基づいて意思決定を行う。メッセージがネットワークを介して送信されたとき、例えば、中間デバイスのメッセージのドロップ、リンク障害、リソース不足(例えば、メモリ又は処理)、又は中間デバイスのクラッシュ又はリセットに起因して、それらが遅延する及び/又は失われる可能性がある。したがって、送信又は受信に失敗したロスト・メッセージを適切に検出することは、メッセージ・ストリームのインテグリティを保持するために望ましい。
メッセージが失われたと決定されたとき、様々な動作、例えば、ロスト・メッセージの再送信の要求、メッセージ・ストリームの終了又はリセット、ログファイルにエントリの作成、エラーメッセージの提供、割り込みの生成、ロスト・メッセージについての受信データを処理するアプリケーション又は高レベルプロトコルへの警告、プログラムの実行の中止、メッセージが失われたことを1人以上のユーザへの通知、メッセージ・ストリームの終了と新しいメッセージ・ストリームの確立、ライセンスのリリースと再取得、サーバの再認証、及び/又は完全なデータセットの再ダウンロードなどの動作がとられてもよい。
いくつかの現在のシステムは、シーケンス番号又はメッセージ識別器を使用し、ロスト・メッセージの検出を補助してもよい。シーケンス番号又はメッセージ識別器は、各メッセージの所定の量によって変化し(通常、増加する)、受信者は、メッセージの送信された順番、どのメッセージが失われたかどうか、の両方を決定することができる。受信者は、例えば、ネットワークの動作に起因して順番が乱れて受信し得たメッセージをバッファリングしてもよい。メッセージが受信されないとき、欠落しているとみなすことができる。欠落しているメッセージは、例えば、中間デバイスで再び順番付けられることにより、又は再送信に起因して、しばらく経ってから受信されることがある。もし一定期間後に、シーケンス内の欠落しているメッセージが受信されない場合、受信者は、メッセージが失われたと決定することができる。別の例では、後のメッセージを順番が乱れて受信したとき、潜在的に前のメッセージを受信するまで一定時間待つよりむしろ、順序が乱れて後のメッセージを受信したとき、欠落している前のメッセージは、失われたと決定してもよい。
いくつかのシステムでは、例えば、データのソースから離れたデバイスで監視されているオブジェクトのデータを変更する場合など、メッセージの送信頻度が低い場合がある。
例えば、サーバがアクセス可能かアクセス不可能か、及びサーバとの接続がアクセス可能かアクセス不可能かなどのステート変化に関連するサーバについての情報を送信することがまれにある。別の例として、ニュース・メッセージなどのメッセージを送信することがまれにある。別の例として、起動時及びロスト・メッセージが続いて検出されたときなどに、データのダウンロードを行うことがまれにある。
メッセージ・ストリーム・インテグリティは、後の受信したメッセージのシーケンス暗号に基づいてロスト・メッセージを検出することに依存する場合、メッセージの送信がまれであると、ロスト・メッセージが検出される前に許容できない遅延が生じる可能性がある。例えば、データのステートにおける第1の変化に関連するメッセージが送信された場合、失われているが、受信者は、データのステートにおける第2の変化に関連するメッセージが受信されるまでロスト・メッセージを検出しない可能性がある。メッセージの送信頻度が低い場合、第2のメッセージは、第1のメッセージが失われて数時間経ってから受信する可能性がある。別の例として、ステートに第2の変化がない場合、第1のメッセージロスが検出されない可能性がある。したがって、第1のメッセージのロスとロスト・メッセージの検出との間の時間において、受信者は、誤ったデータを使用していることになる。
A.一定間隔手法を用いたハートビート
現在のシステムによって使用される1つの手法は、ロスト・メッセージを検出する可能性を高めるものであり、送信されるべき新しいデータがあるか否かに関係なく、いくつかの定義された間隔でメッセージが送信されるものである。この手法を使用するシステムは、例えば、最後のメッセージが送信されてから特定の時間が経過した場合に、ハートビート・メッセージを送信する。ハートビート・メッセージはまた、例えば、アライブ・メッセージ、キープ・アライブ・メッセージ、ステータス・メッセージ、又は同期メッセージと呼ばれてもよい。一定間隔手法を用いたハートビートは、図2Aのメッセージの例に示されている。
図2Aは、定義された時間間隔が“1”の場合の一定間隔手法を用いたハートビートを利用するメッセージの例を示す。この例では、データ・メッセージは“M”と表記され、ハートビート・メッセージは“HB”と表記されている。ここでは、各データ・メッセージのシーケンス番号が1増える。この例では、第1のデータ・メッセージM1が時間t=0のとき、シーケンス番号“0”と共に送信される。定義された時間間隔が“1”であるため、新しいデータがこの時間間隔内で送信されるべきではなく、システムは、時間t=1のとき、シーケンス番号“0”と共に第1のハートビート・メッセージHB1を送信する。この例では、ハートビート・メッセージは、送信された最後のデータ・メッセージのシーケンス番号を繰り返す。特定の実施形態では、ハートビート・メッセージは、それら自身のシーケンス番号に関連付けられてもよい。
時間t=2のとき、送信されるべき新しいデータがない場合、システムは、送信された最後のデータ・メッセージであるデータ・メッセージM1と同じシーケンス番号であるシーケンス番号“0”と共に第2のハートビート・メッセージHB2を送信する。時間t=3のとき、送信されるべき新しいデータがない場合、システムは、シーケンス番号“0”と共に第3のハートビート・メッセージHB3を送信する。時間t=4のとき、送信されるべき新しいデータがない場合、システムは、シーケンス番号“0”と共に第4のハートビート・メッセージHB4を送信する。時間t=5のとき、送信されるべき新しいデータがある。したがって、システムは、第2のデータ・メッセージM2を送信し、シーケンス番号を“1”に増やす。時間t=6のとき、送信されるべき新しいデータがある。システムは、第3のデータ・メッセージM3を送信し、シーケンス番号を“2”に増やす。時間t=7のとき、送信されるべき新しいデータがない場合、システムは、送信された最後のデータ・メッセージであるデータ・メッセージM3と同じシーケンス番号である、シーケンス番号“2” と共に第5のハートビート・メッセージHB5を送信する。
例えば、“1”などの定義された間隔でハートビート・メッセージを送信することによって、システムは、メッセージのロストとロスト・メッセージの検出との間の時間に上限を設けることができる。受信者が、定義された時間間隔を知っているため、システムは、ロスト・メッセージの検出に上限を設けることができ、メッセージが定義された時間内に受信されない場合に検出することができる。この例では、データ・メッセージM3が失われた場合、システムは、次にシーケンス番号“2”と共にハートビート・メッセージHB5を受信する。システムは、受信したハートビート・メッセージのシーケンス番号“2”を最後に受信したメッセージのシーケンス番号、ここではデータ・メッセージM2のシーケンス番号“1”と比較する。この例では、ハートビート・メッセージは、前回送信されたデータ・メッセージのシーケンス番号を保持するため、システムは、定義された時間“1”以内にロスト・メッセージを検出する。別の例では、定義された時間間隔よりも長い、例えば、少し、一定の時間長い、又は定義された間隔の2倍などのいくつかの時間レンジ内に受信されない場合、受信者は、ネットワーク遅延の変動を許容するように検出してもよい。
しかしながら、上述した定義された時間間隔を有するハートビートシステムでは、例えば、ステート情報の更新がまれであることが多い場合、対応するハートビート・メッセージが多数ある。多数のハートビート・メッセージは、限られたネットワーク帯域幅を非効率に使用し、及び/又はネットワーク上の他のデータ・メッセージの配信の待ち時間を増やす可能性がある。例えば、特定のサーバがアプリケーションを実行し、1500人のユーザを管理している場合であって、各ユーザに2つのエンドポイントが存在する場合、サーバによって管理されるエンドポイントは、3000存在する。アクティビティ又は更新されたステート情報がない場合、例えば、3000のハートビート・メッセージが毎秒必要とされる可能性があり、限られたネットワーク帯域幅を非効率的に使用し、別のサーバシステムから受信される情報のための処理機能へのアクセスを取り除く及び/又は遅延させる。
B.増大間隔手法を用いたハートビート
特定の実施形態は、ハートビート・メッセージ間の間隔を増大させることによって過度の非データ・ネットワーク・トラフィックのこの問題に対処している。例えば、第1のハートビートは、最後のデータ・メッセージが送信された後に、一定の時間送信することができる。後続のハートビート・メッセージは、時間間隔を増大させた後、それから送信されてもよい。例えば、間隔は、一定時間増大し、倍増し、幾何学的に増大し、指数関数的に増大し、又は様々な一定の間隔などの所定の時間だけ増大し、又はフィボナッチ若しくは素数などのシーケンスに基づいて増大してもよい。ロスト・メッセージの検出の効率を向上させるため、間隔は、最大値にキャップされる又は制限されてもよい。間隔を最大値にキャップする又は制限することは、時間間隔が事実上無制限になることを防止し、メッセージのロストとロスト・メッセージの検出との間の時間の上限を維持する。
図2Bは、時間間隔が2倍の場合の増大間隔手法を用いたハートビートの例を利用するメッセージの例を示す。この例では、データ・メッセージは、“M”と表記され、ハートビート・メッセージは、“HB”と表記されている。ここでは、各メッセージのシーケンス番号は、1増加し、ハートビート・メッセージが送信された最後のデータ・メッセージのシーケンス番号を含んでいる。この例では、第1のデータ・メッセージM1は、時間t=0のとき、シーケンス番号“0”と共に送信される。第1の時間間隔は“1”であり、この時間間隔内で新しいデータは送信されない。したがって、システムは、時間t=1のとき、シーケンス番号“0”と共に第1のハートビート・メッセージHB1を送信する。
この例では、時間間隔は2倍であって、それ故、前の時間間隔“1”の2倍の量である、時間t=3(t=1(最後のハートビート・メッセージが送信された時間)+1(前の間隔)*2(2倍))のときに、次のハートビート・メッセージが送信される。時間t=3のとき、送信されるべき新しいデータがない場合、システムは、送信された最後のデータ・メッセージであるデータ・メッセージM1と同じシーケンス番号である、シーケンス番号“0”と共に第2のハートビート・メッセージHB2を送信する。次のハートビート・メッセージは、前の時間間隔“2”の2倍の量である、時間t=7(t=3(最後のハートビート・メッセージが送信された時間)+2(前の間隔)*2(2倍))のときに送信される。なお、時間t=5のとき、新しいデータが送信される。したがって、システムは、第2のデータ・メッセージM2を送信し、シーケンス番号を“1”に増やす。時間t=6のとき、送信されるべき新しいデータがあり、それ故、システムは、第3のデータ・メッセージM3を送信し、シーケンス番号を“2”に増やす。次のハービートメッセージは、初期の時間間隔“1”に戻って、時間t=7のときに送信されるべきである。時間t=7のとき、送信されるべき新しいデータがない場合、システムは、送信された最後のデータ・メッセージであるデータ・メッセージM3と同じシーケンス番号である、シーケンス番号“2” と共に第3のハートビート・メッセージHB3を送信する。
上記の図2Bに示された増大間隔手法は、一定のハートビート間隔と比較すると、ハートビート・メッセージによりネットワーク・トラフィックを低減している。ここで、上記の図2Aに示された一定のハートビート間隔は、増大間隔手法の初期の間隔と同じである。図2Aの例では、4つのハートビート・メッセージが、2つのデータ・メッセージ(M1とM2)間に送信される。この例の場合では、2つのハートビート・メッセージのみが送信される。
また、増大間隔手法は、一時的なリンク障害に対するいくつかの許容範囲を提供する、例えば、リンクがダウンし、接続が増大した間隔の期間に復元され、新しいメッセージが送信されない場合、一時的なリンク障害が検出されない。データが失われないので、そのような障害は、ストリーム・インテグリティのために問題となることはないかもしれないが、一定間隔手法は、そのような一時的なリンク障害を検出する可能性が高い。
図2Cは、上記の増大間隔手法を用いたハートビートに基づいてメッセージを送信する方法200のフロー図の例を示す。この例では、各データ・メッセージは、異なるシーケンス番号を有している。例えば、各データ・メッセージは、前回のデータ・メッセージのシーケンス番号より1つ大きいシーケンス番号を有していてもよい。この例では、ハートビート・メッセージは、ハートビートの前に送信された最後のデータ・メッセージと同じシーケンス番号を使用する。
ブロック201で、送信されるべきメッセージのシーケンス番号がリセットされ、ハートビート・メッセージが送信されるべき時間が示された、次のハートビートタイムがセットされる。例えば、シーケンス番号は、“0”又は“−1”にリセットされてもよく、次のハートビートタイムは、データ・メッセージがまだ送信されないので、“無限”にセットされてもよい。
ブロック202で、新しいデータ・メッセージが送信されるかどうか、又は次のハートビートタイムに達したかどうかを決定する。例えば、送信するための新しいデータ・メッセージがアプリケーションから受信されてもよい。別の例として、ハートビートタイムと関連付けられたタイマーが終了してもよい。
新しいメッセージが送信されるべき場合(ブロック202で決定されるように)、ブロック203で、送信されるべきメッセージのシーケンス番号が増加する。例えば、シーケンス番号が“0”から“1”に、又は“−1”から“0”に1増加してもよい。
ブロック204で、新しいデータ・メッセージが図2Bのデータ・メッセージM1などの増加したシーケンス番号と共に送信される。
ブロック205で、次のハートビートタイムが、新しいデータ・メッセージが送信された時間に初期の間隔を足した時間にセットされる(及び前回設定された次のハートビートタイムがクリアされる)。例えば、新しいデータ・メッセージがt=0のときに送信され、初期のハートビート間隔が“1”であり、それから次のハートビートタイムがt=1にセットされてもよい。次いで制御は、ブロック202に戻る。
送信するべき新しいデータ・メッセージがなく、次のハートビートタイムに達している場合(ブロック202で決定されるように)、ブロック206で、ハートビート・メッセージが、図2Bのハートビート・メッセージHB2などの、送信された最後のデータ・メッセージのシーケンス番号である、現在のシーケンス番号と共に送信される。
ブロック207で、この例では、送信された最後のハートビート・メッセージの間隔を2倍にし、それをブロック206で送信された直近のハートビート・メッセージの時間に追加することによって、次のハートビートタイムが決定される。例えば、直近の送信されたハートビート・メッセージがハートビート間隔“2”の後、t=3のときに送信された場合、次のハートビートタイムがt=7(t=3(送信された直近のハートビート・メッセージ)+2(前のハートビート間隔)*2(2倍))にセットされる。次いで制御は、ブロック202に戻る。
上記の増大間隔手法を用いたハートビートに基づいてメッセージを送信する方法は、シーケンス番号をデータ・メッセージに関連付け、対応するシーケンス番号を、データ・メッセージの後に送信されたハートビート・メッセージに関連付ける。データ及びハートビート・メッセージへのシーケンス番号の関連付けは、データ・メッセージが失ってからその後のメッセージが受信される時間内に、ロスト・メッセージが検出されることを可能にする。
図2Dは、上記の増大間隔手法を用いたハートビートに基づいてメッセージを受信する方法210のフロー図の例を示す。この例では、各データ・メッセージは、異なるシーケンス番号を有している。例えば、各データ・メッセージは、前回のデータ・メッセージのシーケンス番号より1大きいシーケンス番号を有していてもよい。この例では、ハートビート・メッセージは、ハートビートの前に送信された最後のデータ・メッセージと同じシーケンス番号を使用している。
ブロック211で、受信されるべきメッセージの予想シーケンス番号がリセットされる。例えば、予想シーケンス番号は、“0”又は“−1”にリセットされてもよい。
ブロック212で、メッセージが受信される。メッセージは、例えば、データ・メッセージ又はハートビート・メッセージであってもよい。メッセージが予想時間間隔内に受信されない場合、ロスト・メッセージが報知されてもよい。予想時間間隔は、例えば、送信されるデータ・メッセージと第1のハートビート・メッセージとの間の初期の時間間隔に基づくものであってもよく、又は予想時間間隔は、2つのハートビート・メッセージ間の間隔に基づくものであってもよい。例えば、初期の時間間隔及び/又は2つのハートビート・メッセージ間の間隔は、一定時間又は2倍増加し、ネットワーク遅延の変動を許容し、予想時間間隔を決定してもよい。
ブロック213で、受信されたメッセージの予想シーケンス番号が決定される。受信されたメッセージがデータ・メッセージの場合、予想シーケンス番号は、前回受信されたメッセージ(又は前回受信されたメッセージがない場合、リセットされた予想シーケンス番号から)のシーケンス番号を増加することによって決定されてもよい。例えば、シーケンス番号は、“0”から“1”、又は“−1”から“0”に1増加されてもよい。受信されたメッセージがハートビート・メッセージの場合、この例では、予想シーケンス番号は、前回受信されたメッセージと同じシーケンス番号である。
ブロック214で、受信されたメッセージのシーケンス番号は、ブロック213で決定された予想シーケンス番号と比較される。
受信されたシーケンス番号が予想シーケンス番号と等しくない場合(ブロック214で決定されるように)、ブロック215で、ロスト・メッセージが報知されてもよい。特定の実施形態では、ロスト・メッセージは、ロスト・メッセージがデータ・メッセージの場合のみ報知されてもよい。特定の実施形態では、システムは、メッセージが欠落していることを決定し、欠落したメッセージを受信する時間待機してもよい。欠落したメッセージが時間内に受信されない場合、システムは、ロストとして欠落したメッセージを報知する。
受信されたメッセージのシーケンス番号が予想シーケンス番号と等しい場合(ブロック214で決定されるように)、受信されたメッセージがデータ・メッセージであるかを決定する。受信されたメッセージがデータ・メッセージである場合、ブロック217で、データ・メッセージが処理され、制御がブロック212に戻る。
上記の増大間隔手法を用いたハートビートに基づいてメッセージを受信する方法は、各データ・メッセージのシーケンス番号の増加を予測し、前回送信されたデータ・メッセージのシーケンス番号と同じハートビート・メッセージのシーケンス番号を予測する。データ及びハートビート・メッセージへのシーケンス番号の関連付けは、データ・メッセージのロストから次のメッセージが受信されるまでの時間内に、ロスト・メッセージが検出されることを可能にする。
C.ストップ・メッセージ手法
特定の実施形態は、ストップ・メッセージ手法を利用することによって、過度の非データ・ネットワーク・トラフィックの問題に対処している。ストップ・メッセージ手法では、ストップ・メッセージが送信され、送信機が追加のハートビート・メッセージを提供せずに、受信者の次に受信するメッセージがデータ・メッセージであることを受信者に示している。ストップ・メッセージはまた、例えば、エンド・メッセージ又はハートビート・サスペンション・メッセージと呼ばれてもよい。さらに、ストップ・メッセージは、異なるメッセージの種類であってもよく、又はハートビート・メッセージ又はデータ・メッセージなどの別のメッセージにおけるフラグによって表されてもよい。一例では、ストップ・メッセージは、データ・メッセージにおけるフラグによって表されてもよい。この例では、ストップ・メッセージ手法は、単独で使用されてもよく、又はハートビート・メッセージ手法との組み合わせで使用されてもよい。
さらに、使用されるハートビート・メッセージとストップ・メッセージの数は、変更してもよい。例えば、3つのハートビート・メッセージが送信され、ストップ・メッセージが続いてもよい。別の例では、3つのハートビート・メッセージは、ストップ・メッセージ・フラグを有する最後のハートビート・メッセージと共に送信されてもよい。別の例では、送信されるべきハートビート・メッセージの数は、使用されるリンク/トランスポートの待ち時間に基づいてもよい。
ストップ・メッセージ手法は、図2A−2Dを参照して上記したような同様の方法でロスト・メッセージの検出を増やしている。さらに、ストップ・メッセージ手法は、過度のハートビート・メッセージに起因するネットワーク・トラフィックを更に低減し、図2Bを参照して上記した増大間隔手法と同様に一時的なリンク障害に対していくつかの許容範囲を提供する。
図3A及び図3Bは、送信されるハートビート・メッセージの数を減らした場合のストップ・メッセージ手法の利点を示す。図3Aは、上記したような増大間隔手法を用いたハートビートの例を利用するメッセージの例を示す。この例では、データ・メッセージは“M”と表記され、ハートビート・メッセージは“HB”と表記される。ここでは、ハートビート・メッセージの時間間隔は、2倍されており、ハートビート・メッセージは、送信された最後のデータ・メッセージのシーケンス番号を含む。この例では、第1のデータ・メッセージM1が、時間t=0のときに、シーケンス番号“0”と共に送信される。第1の時間間隔は“1”であり、この時間間隔内に送信されるべき新しいデータはない。したがって、システムは、時間t=1のとき、シーケンス番号“0”と共に第1のハートビート・メッセージHB1を送信する。時間t=3(1(前の間隔)*2(2倍)=2の間隔後)のとき、送信されるべき新しいデータはなく、システムは、シーケンス番号“0”と共に第2のハートビート・メッセージHB2を送信する。時間t=7(2(前の間隔)*2(2倍)=4の間隔後)のとき、送信されるべき新しいデータがない場合、システムは、シーケンス番号“0”と共に第3のハートビート・メッセージHB3を送信する。時間t=11(ハートビート・メッセージが送信される次の時間の前)のとき、送信されるべき新しいデータがある。したがって、システムは、第2のデータ・メッセージM2を送信し、シーケンス番号を“1”に増やす。図3Aの例では、3つのハートビート・メッセージは、第2のデータ・メッセージが送信される前に送信される。これらのハートビート・メッセージは、過剰となる可能性があり、ネットワーク・トラフィックを増大させることになる可能性もある。
図3Bは、上記したストップ・メッセージ手法の例を利用するメッセージを示す。この例では、ストップ・メッセージは“SM”と表記され、ハートビート・メッセージは、使用されない。代わりに、初期の間隔“1”の後、ストップ・メッセージが送信され、送信された最後のデータ・メッセージのシーケンス番号を含む。この例では、第1のデータ・メッセージM1が、時間t=0のとき、シーケンス番号“0”と共に送信される。時間t=1のとき、送信されるべき新しいデータがない場合、ストップ・メッセージSM1がシーケンス番号“0”と共に送信される。このストップ・メッセージは、追加のハートビート・メッセージが送信されず、受信されるべき次のメッセージがデータ・メッセージであることを示している。時間t=11のとき、データ・メッセージM2がシーケンス番号“1”と共に送信される。図3Bに示されるストップ・メッセージ手法は、ハートビート・メッセージの数を減らすことによって、ネットワーク・トラフィックを低減している。図3Aの例では、3つのハートビート・メッセージが2つのデータ・メッセージの間に送信され、この例の場合、1つのストップ・メッセージのみが送信される。
D.メッセージ・ストリーム・ステートをクリアする手法
特定の実施形態は、送信機及び受信機の両方によって維持されるメッセージ・ストリームについてのステート情報に対処している。メッセージ・ストリーム・ステートは、特定のメッセージ・ストリームに特有の情報である。メッセージ・ストリームは、特定のオブジェクト、項目などに関連するメッセージの論理通信チャンネルである。例えば、監視される各オブジェクトが、そのオブジェクトに関連付けられたメッセージのメッセージ・ストリームに関連付けられてもよい。別の例として、各ユーザは、パーソナル・インボックス・ストリームなどの明確にユーザに向けられたメッセージのメッセージ・ストリームを有していてもよい。送信機のために、例えば、メッセージ・ストリーム・ステートは、最後に送信されたシーケンス番号、最後に送信された時間、再送信のための送信されたデータのコピー、受信者のアドレス又は主題、及びハートビート・メッセージの時間間隔の送信に関連する情報を含んでもよい。
受信者のアドレスは、基本的なリンク及び/トランスポートアドレスと異なっていてもよく、例えば、IPネットワーク、プロセス間通信(“IPC”)、共有メモリ、及び/又はインフィニバンド(登録商標)などのメッセージ・パッシング・ファブリックを含む。例えば、特定の実施形態は、IPマルチキャストメカニズムのトップに使用され、1人以上の受信者が単一のIPマルチキャストグループに参加してもよい。受信者は、メッセージに含まれる対象アドレスに基づいて、それらのために意図されたメッセージを識別する。別の受信者は、異なる対象に興味がある可能性があり、さらにIPマルチキャストグループの各メンバーがすべてのマルチキャストメッセージを受信する。特定の主題に興味がない受信者は、それが受信されていなかったかのように、そのメッセージをドロップする。単一のIPマルチキャストグループは所定の値であってもよいが、対象アドレスは、メッセージ・ストリーム・ステートの一部である。なぜならば、それは、例えば、監視されるオブジェクトに関連付けられたメッセージ・ストリームに対して特有であるためである。
受信機のために、メッセージ・ストリーム・ステートは、例えば、最後に受信されたシーケンス番号、最後に受信した時間、順番が乱れたメッセージのコピー、送信機に関連するアドレス又は主題、ロスト・メッセージを検出するための送信間隔に関連する情報を含んでもよい。例えば、メッセージの順番付けをする中間デバイスもまた各メッセージ・ストリームのメッセージ・ストリーム・ステートを維持してもよい。
そのようなメッセージ・ストリーム・ステート情報は、数千のオブジェクト及び/又はユーザとして考えても、メモリ又は強力なサーバのソケット、プロセス、接続、又はポートなどの他のリソースの小さい部分のみを占有するとして退けられる可能性がある。しかしながら、サーバが一度に、数ヶ月、又はそれ以上長く動作すると予想される場合、メッセージ・ストリーム・ステートを維持しなければならないオブジェクト及びユーザの数が無限となり、理論的には、サーバがメモリ又は他のリソースを使い果たす可能性がある。さらに、メッセージの並べ替えがサポートされている場合、各メッセージ・ストリームに対してバッファが必要とされる可能性、又は望まれる可能性がある。メッセージ・ストリームが多数の場合、これは、メモリ使用量のかなりの量を表すことができる。
また、受信者の特定のタイプは、より限られたメモリ及び/又はリソースの制約を有していてもよい。例えば、大容量メモリ及び/又はリソースの要件は、モバイルデバイスなどのいくつかのデバイスにおける実用性又は費用効果でなくてもよい。別の例として、特殊なネットワーク・インタフェース・コントローラ(“NIC”)・カードがメッセージ処理を実行してもよく、維持することができるストリームの数に影響を与えるリソース制限を有していてもよい。別の例として、ルータ及び/又はブリッジなどのデバイスは、リモートサイト又はネットワークで多数のクライアントに情報を提供することができるアプリケーション・プロトコル・ルータを含み、様々な構成において、受信者又は中間デバイスと見なすことができる。いくつかのデバイスは、例えば、メモリ及び/又はリソースの制約を有する特別な目的のハードウェアデバイスとして実現されてもよい。これにより、頻度の低いメッセージに関連するメッセージ・ストリームのために記憶する必要があるステート情報を低減することが望ましい。
特定の実施形態は、上記したストップ・メッセージ手法、メッセージステート情報のクリアリングの組み合わせによってメッセージ・ストリーム・ステート情報を記憶する問題に対処している。伝送制御プロトコル(“TCP”)接続又はマルチキャストグループなどの基本的なトランスポート接続は、閉じられる可能性がないかもしれないが、メッセージ・ストリーム・ステートは、クリアされ、破棄され、上書きされ、及び/又はメモリから割り当て解除され、関連付けられたソケットなどのリソースを開放してもよい。送信されるべきメッセージがなく、メッセージ・ストリーム・ステート情報を記憶する必要がないため、メッセージ・ストリーム・ステートのクリアが行われてもよい。したがって、ストップ・メッセージが送信及び/又は受信された後、ステート情報がクリアされてもよい。
新しいデータ・メッセージが送信されるとき、新しいメッセージ・ストリームが作成され、所定のシーケンス番号で開始される。例えば、ストップ・メッセージが送信された後、新しいデータ・メッセージが送信される各時間では、新しいデータ・メッセージのシーケンス番号が“0”にリセットされてもよい。データ・メッセージの宛先は、ソース及び/メッセージ自体の内容に由来してもよい。例えば、メッセージの主題は、ユーザ情報に基づいて構成されてもよい。別の例として、宛先は、ユーザ情報、グループメンバーシップ情報、アプリケーション識別子、ユーザネーム、及び/又はアカウントに基づいて構成されてもよい。新しいデータ・メッセージが送信されたため、送信間隔に関連する状態は、所定の初期値にセットされる。これにより、ストリーム状態は、効果的に再作成される。
図3Cは、上記したメッセージ・ストリーム・ステートをクリアする手法の例を組み合わせたストップ・メッセージ手法の例を利用するメッセージの例を示す。この例では、メッセージ・ストリームにおける各メッセージ(データ・メッセージとストップ・メッセージの両方)のシーケンス番号が“1”増える。データ・メッセージM1は、シーケンス番号“0”と共に送信され、データ・メッセージM2はシーケンス番号“1”と共に送信され、そしてストップ・メッセージSM1はシーケンス番号“2”と共に送信される。ストップ・メッセージSM1を送信した後、送信機、受信機のうち1つ以上、及び1つ以上の中間デバイスによって、メッセージ・ストリーム・ステートがクリアされる。送信されるべき後続のデータ・メッセージのシーケンス番号はまた、メッセージ・ストリーム・ステートがクリアされたため、所定の値“0”にリセットされる。ストップ・メッセージSM1の送信は、次の受信されるメッセージがデータ・メッセージであるべきであって、データ・メッセージのシーケンス番号が“0”であるべきであることを受信者(又はいくつかの中間デバイス)に示す。この例では、後で、データ・メッセージM3がシーケンス番号“0”と共に送信され、データ・メッセージM4がシーケンス番号“1”と共に送信され、そしてストップ・メッセージSM2がシーケンス番号“2”と共に送信される。ストップ・メッセージSM1を受信した後、受信者は、シーケンス番号“0”と共にデータ・メッセージを受信することを予測する。例えば、データ・メッセージM3が失われた場合、受信者は、代わりにシーケンス番号“1”と共にデータ・メッセージM4を受信する。受信者は、受信されたデータ・メッセージM4のシーケンス番号が“0”でないことから、データ・メッセージが失われたと決定する。別の例では、データ・メッセージM3とM4が失われた場合、受信者は、受信したメッセージがシーケンス番号“2”のストップ・メッセージSM2であり、シーケンス番号“0”と“1”のデータ・メッセージM3とM4ではないことから、両方のデータ・メッセージが失われたと決定する。
E.フェーズ番号手法
上記したように、メッセージ・ストリーム・ステートをクリアする手法を使用するとき、新しいメッセージ・ストリーム・ステートが作成され、所定のシーケンス番号で開始される。例えば、各時間では、ストップ・メッセージが送信された後、新しいデータ・メッセージが送信され、新しいデータ・メッセージのシーケンス番号が“0”にリセットされる。ストップ・メッセージの送信後にメッセージ・ストリーム・ステートをクリアするシステムは、全体のメッセージ・シーケンスが失われたとき、失われたデータ・メッセージを検出することができない。メッセージ・シーケンスは、データ・メッセージのシーケンス及び対応する後続のストップ・メッセージである。そのようなシステムは、間違った順番のシーケンス番号に起因してロスト・メッセージを検出することができるが、全体のシーケンス番号が失われた場合、受信されたメッセージのシーケンス番号は、正しい順序に保持される。新しいメッセージ・シーケンスが“0”などのシーケンス番号で再開するため、受信されたメッセージは、正しい順序に保持される。新しいメッセージ・シーケンスのシーケンス番号がリセットされた場合、全体のメッセージ・シーケンスのロスが検出されない可能性がある。この問題の例は、図3Dに示されている。
図3Dは、全体のメッセージ・シーケンスが検出されずに失われた場合のメッセージの例を示す。この例では、各メッセージのシーケンス番号が1増えて、ストップ・メッセージの送信の際に“0”にリセットされる。したがって、データ・メッセージM1は、シーケンス番号“0”と共に送信され、データ・メッセージM2は、シーケンス番号“1”と共に送信され、そしてストップ・メッセージSM1は、シーケンス番号“2”と共に送信される。ストップ・メッセージが送信されるため、後続のデータ・メッセージのシーケンス番号が“0”にリセットされる。データ・メッセージM3がシーケンス番号“0”と共に送信され、データ・メッセージM4がシーケンス番号“1”と共に送信され、そしてストップ・メッセージSM2がシーケンス番号“2”と共に送信される。別のストップ・メッセージが送信された場合、後続のデータ・メッセージのシーケンス番号がリセットされる。データ・メッセージM5がシーケンス番号“0”と共に送信され、データ・メッセージM6がシーケンス番号“1”と共に送信され、そしてストップ・メッセージSM3がシーケンス番号“2”と共に送信される。
この例では、データ・メッセージM3、データ・メッセージM4、及びストップ・メッセージSM2が失われる。データ・メッセージのシーケンス番号がリセットされ、次いでストップ・メッセージが送信されるため、この例の受信者は、ロスト・メッセージM3、M4、及びSM2を検出することができない。受信者は、ここでは、シーケンス番号“0”と共にデータ・メッセージを受信すると予測し、次いでSM1を受信すると、そのようにするが、メッセージM3、M4及びSM2のロスを検出しない。
別の例として、ネットワーク遅延及びメッセージロスの両方に起因して、1つのメッセージ・シーケンスの一部が第2のメッセージ・シーケンスの一部と検出不可能に組み合わされている可能性があり、それ故に、システムは、これらの組み合わされたメッセージのロスを検出することができない場合がある。図3Eは、一例を示す。この例では、図3Dに示した上記の例と同様に、各メッセージのシーケンス番号が“1”増加し、ストップ・メッセージの送信の際に“0”にリセットされる。図3Eの例では、データ・メッセージM1がシーケンス番号“0”と共に送信され、データ・メッセージM2がシーケンス番号“1”と共に送信され、データ・メッセージM3がシーケンス番号“2”と共に送信され、そしてストップ・メッセージSM1がシーケンス番号“3”と共に送信される。シーケンス番号がリセットされ、データ・メッセージM4がシーケンス番号“0”と共に送信され、データ・メッセージM5がシーケンス番号“1”と共に送信され、データ・メッセージM6がシーケンス番号“2”と共に送信され、ストップ・メッセージSM2がシーケンス番号“3”と共に送信される。
この例では、メッセージM3、SM1、M4、及びM5が失われる。シーケンス番号“1”と共にデータ・メッセージM2を受信した後、受信者は、シーケンス番号“2”と共にデータ・メッセージを受信することを予測する。ストップ・メッセージの送信後にシーケンス番号がリセットされるため、受信者は、シーケンス番号“2”と共にデータ・メッセージを受信するが、メッセージM3、SM1、M4、及びM5のロスを検出しない。メッセージが大きな間隔で送信されるが、中間デバイスでバッファされ及び/又は遅延し、いくつかのメッセージがその後ドロップされる場合、このシナリオが発生する可能性がある。
メッセージ・ストリーム・ステートがクリアされ、後続の送信されたデータ・メッセージのシーケンス番号がリセットされ、メッセージ・シーケンスが失われる可能性がある場合のシナリオに対処するため、特定の実施形態は、シーケンス番号に加えて、各メッセージに含まれるフェーズ番号を提供する。フェーズ番号は、全体のメッセージ・シーケンスと同じに保持し、例えば、ストップ・メッセージが送信された後、後続のメッセージ・シーケンスのために別の値にセットされる識別子である。
図3Fは、フェーズ番号手法に基づくフェーズ番号を有する図3Dのメッセージの例を示す。図3Fに示す例では、各メッセージ・シーケンスのフェーズ番号は、1増える。それ故、第1のメッセージ・シーケンスがフェーズ番号“0”と共に送信され、第2のメッセージ・シーケンスがフェーズ番号“1”と共に送信され、そして第3のメッセージ・シーケンスがフェーズ番号“2”と共に送信される。この例では、受信者は、1増えたフェーズ番号と共にメッセージ・シーケンスを受信することを予測する。したがって、第1のメッセージ・シーケンスがフェーズ番号“0”と共に受信された後、第3のメッセージ・シーケンスがフェーズ番号“2”と共に受信されたとき、受信者は、フェーズ番号“1”を有するメッセージ・シーケンスが失われたことを決定できる。
図3Gは、フェーズ番号が含まれた図3Eのメッセージの例を示す。図3Gでは、各メッセージ・シーケンスのフェーズ番号が1増える。それ故、第1のメッセージ・シーケンスがフェーズ番号“0”と共に送信され、第2のメッセージ・シーケンスがフェーズ番号“1”と共に送信される。この例では、受信者は、1増えたフェーズ番号と共にメッセージ・シーケンスを受信すると予測する。シーケンス番号“1”及びフェーズ番号“0”と共にデータ・メッセージM2を受信した後、受信者は、シーケンス番号“2”及びフェーズ番号“0”と共にデータ・メッセージを受信することを予測する。メッセージM3、SM1、M4、及びM5が失われた場合、受信者は、代わりにシーケンス番号“2”及びフェーズ番号“1”と共にデータ・メッセージM6を受信する。受信されたデータ・メッセージのフェーズ番号が“0”ではないため、受信者は、ロスト・メッセージのシーケンスを検出することができる。
別の例では、同じメッセージ・シーケンスの各メッセージが同じフェーズであるため、フェーズ番号は、クリアされ得るメッセージ・ストリーム・ステートの一部である。メッセージ・ストリーム・ステートをクリアすることの利点は、上記している。新しいメッセージ・シーケンスが開始するとき、次のメッセージ・シーケンスのフェーズの値は、新しいシーケンスが送信機から送信されることを繰り返さない、又は非常にまれに繰り返す方法で変更される送信機で入手可能なグローバル値又は関数から取得される。これは、受信者が次のフェーズ番号を予測することができなくなる。例えば、送信機は、プロトコルに実装可能であって新しいメッセージ・シーケンスが開始するそれぞれの時間に1増える1つの32ビット符号なし整数値を保持する可能性がある。新しいシーケンスが送信機から送信される時間毎に、受信者にかかわらず、新しいフェーズ番号が選択される。したがって、この例では、送信機が多くの異なる受信者にメッセージ・シーケンスを送信し得るため、受信者は、メッセージ・シーケンスのフェーズ番号を予測することができない。
図3Hは、受信者がメッセージ・シーケンスのフェーズ番号を予測することができないメッセージの例を示す。図3Hは、図3Gに示された例と同様であるが、図3Hでは、フェーズ番号がランダムに関連付けられている。図3Hの例では、第1のメッセージ・シーケンスがフェーズ番号“0”と共に送信され、第2のメッセージ・シーケンスがフェーズ番号“5”と共に送信される。シーケンス番号“1”及びフェーズ番号“0”と共にデータ・メッセージM2を受信した後、受信者は、フェーズ番号“0”と共にストップ・メッセージ又はデータ・メッセージを受信することを予測する。メッセージM3、SM1、M4、及びM5が失われた場合、受信者はシーケンス番号“2”及びフェーズ番号“5”と共にデータ・メッセージM6を受信する。データ・メッセージM6のフェーズ番号“5”とデータ・メッセージM2のフェーズ番号“0”とを比較し、受信者は、メッセージのシーケンスが失われたことを決定する。
別の例では、受信者がメッセージ・シーケンスのフェーズ番号を予測できない場合、フェーズ番号がメッセージ・ストリームと共にクリアされると、受信者は、全体のメッセージ・シーケンスのロスを検出することができない可能性がある。この例においてロスト・メッセージを検出するため、リンク・ステート問題を検出可能なメカニズムが採用されていてもよい。例えば、複数のメッセージ・ストリームが同じリンク/トランスポートを介して送信される可能性があるため、各リンク/トランスポート・メカニズムに周期的にハートビートを送信し、特有のメッセージ・ストリームから独立した別のメカニズムが、これらのタイプのリンク障害を検出し、その結果アプリケーションがシーケンスを完全に失うことによって生じる問題を防止するように動作してもよい。また、いくつかの状況では、データの性質によって、後のシーケンスの処理中に、メッセージ・シーケンスのロスが受信者に明らかになる可能性がある。
図4は、上記したフェーズ番号を使用するメッセージを送信する方法400のフロー図の例を示す。この例では、フェーズ番号は、シーケンス番号と共に各メッセージと一緒に使用されており、ハートビート・メッセージは使用されず、データ・メッセージが送信されていない初期の間隔の後にストップ・メッセージのみが使用される。特定の実施形態では、ハートビート・メッセージはまた、ストップ・メッセージが送信される前に送信されてもよい。また、上記のメッセージ・ストリーム・ステートをクリアする手法の実施形態も、組み込まれている。
ブロック401で、新しいメッセージが送信されたかどうかを決定する。新しいメッセージは、例えば、新しいデータ・メッセージ又はストップ・メッセージであってもよい。例えば、送信されるべき新しいデータ・メッセージは、アプリケーションから受信されてもよい。別の例では、初期の間隔と関連付けられたタイマーが終了となり、ストップ・メッセージが送信されるべきことを示してもよい。特定の実施形態では、送信されるべき新しいメッセージがハートビート・メッセージであってもよい。新しいメッセージが送信されるべきではないと決定した場合、その後、制御は、ブロック401に戻る。
新しいメッセージが送信されるべきである場合(ブロック401で決定されるように)、ブロック402で、フェーズ番号が決定される。新しいメッセージがメッセージ・シーケンス内の第1のデータ・メッセージである場合、フェーズ番号は、例えば、前回のメッセージ・シーケンスのフェーズ番号を増加する(又はこれが送信された第1のメッセージ・シーケンスの場合、“0”などの所定の値を開始する)、又はグローバル値又は関数から新しいフェーズ番号を取得することによって決定されてもよい。例えば、最後のメッセージ・シーケンスのフェーズ番号が、“0”から“1”まで1増やしてもよい。新しいメッセージがメッセージ・シーケンス内の第1のデータ・メッセージではない場合、フェーズ番号は、送信された最後のメッセージのフェーズ番号であると決定されてもよい。例えば、送信された最後のメッセージのフェーズ番号が“1”である場合、その後、送信されるべき新しいメッセージのフェーズ番号も“1”である。
ブロック403で、シーケンス番号が決定される。新しいメッセージがデータ・メッセージである場合、シーケンス番号は、前回送信されたデータ・メッセージのシーケンス番号を増加する(又はこれがメッセージ・シーケンス内の第1のデータ・メッセージの場合、“0”などの所定の値で開始する)ことによって決定されてもよい。例えば、シーケンス番号が“0”から“1”に1だけ増やしてもよい。新しいメッセージがストップ・メッセージ(又は、特定の実施形態では、ハートビート・メッセージ)である場合、シーケンス番号がメッセージ・シーケンス内の送信された最後のデータ・メッセージのシーケンス番号であると決定されてもよい。
ブロック404で、新しいメッセージがデータ・メッセージである場合、制御は、ブロック405に進む。新しいメッセージがストップ・メッセージである場合、制御は、ブロック406に進む。
ブロック405で、新しいメッセージ(データ・メッセージ)が送信され、制御は、ブロック401に戻る。
ハートビート・メッセージを組み込んだ特定の実施形態では、ブロック404から、制御がブロックを通過し、新しいハートビート・メッセージを送信し、制御がブロック401に戻る前に新しい次のハートビートタイムを決定する。
ブロック406で、次のメッセージ(データ・メッセージ)が送信される。ブロック407で、上述したように、メッセージ・ストリーム・ステートがクリアされ、制御がブロック401に戻る。
図5は、上記したフェーズ番号手法に基づくメッセージの受信方法500のフロー図の例を示す。この例では、フェーズ番号がシーケンス番号と共に各メッセージと一緒に使用され、各メッセージ・ストリームは、異なるフェーズ番号を有している。例えば、各メッセージ・ストリームは、前回のメッセージ・ストリームのフェーズ番号より1つ大きいフェーズ番号を有していてもよい。別の例として、各メッセージ・ストリームは、受信者に予測不可能なフェーズ番号を有している可能性がある。また、この例では、各データ・メッセージは、異なるシーケンス番号を有している。例えば、各データ・メッセージは、前回のデータ・メッセージのシーケンス番号よりも1つ大きいシーケンス番号を有していてもよい。この例では、ハートビート・メッセージは使用されず、データ・メッセージが送信されていない初期の間隔の後のストップ・メッセージのみが使用される。特定の実施形態では、ハートビート・メッセージはまた、ストップ・メッセージが送信される前に送信されてもよい。また、上述したメッセージ・ストリーム・ステートをクリアする手法の実施形態もまた、組み込まれている。
ブロック501で、メッセージが受信される。メッセージは、例えば、データ・メッセージ又はストップ・メッセージであってもよい。メッセージを予想時間間隔内に受信しない場合、ロスト・メッセージが報知されてもよい。例えば、予想時間間隔は、データ・メッセージと第1のハートビート・メッセージ(又はここではストップ・メッセージ)との間の初期の時間間隔に基づいてもよく、又は予想時間間隔は、1つのハートビート・メッセージ間の間隔に基づいてもよい。例えば、初期の時間間隔及び/又は2つのハートビート・メッセージ間の間隔は、一定時間又は2倍増加し、ネットワーク遅延の変動を許容し、予想時間間隔を決定してもよい。
ブロック502で、受信されたメッセージの予想フェーズ番号を決定する。受信されたメッセージの予想フェーズ番号は、この例では、メッセージ・シーケンス内の前回受信されたメッセージのフェーズ番号と同じである。受信されたメッセージが、メッセージ・シーケンスの第1のメッセージ(前回のメッセージが受信されていないかどうか又は前回のメッセージがストップ・メッセージであるかどうかに基づいて決定されてもよい)である場合、予想フェーズ番号は、フェーズ番号が受信機によって予測可能であるか否かに基づいて決定されてもよい。フェーズ番号が受信機によって予測可能である場合、予想フェーズ番号は、所定の関数に基づいて決定することができる。例えば、予想フェーズ番号は、前回のメッセージ・シーケンスのフェーズ番号を増加する(又はこれが受信された第1のメッセージ・シーケンスである場合、“0”などの所定の値で開始する)ことによって、決定されてもよい。フェーズ番号が、受信機によって予測不可能である場合、メッセージ・シーケンス内の受信された第1のメッセージのフェーズ番号は、予想フェーズ番号として取得され、前回のメッセージ・シーケンスのフェーズ番号と異なることが予想される。
ブロック503で、受信されたメッセージの予想シーケンス番号が決定される。受信されたメッセージがデータ・メッセージである場合、予想シーケンス番号が前回受信されたメッセージのシーケンス番号(又は前回のメッセージがこのメッセージ・シーケンス内で受信されなかった場合、所定の初期のシーケンス番号から)を増加することによって、決定されてもよい。例えば、シーケンス番号は、“0”から“1”に1増やしてもよい。受信されたメッセージがストップ・メッセージである場合、この例では、予想シーケンス番号は、前回受信されたメッセージのシーケンス番号と同じである。
ブロック504で、受信されたメッセージのフェーズ番号がブロック502で決定された予想フェーズ番号と比較される。
受信されたメッセージのフェーズ番号が予想フェーズ番号と等しくない場合(ブロック504で決定されたように)、ブロック505で、ロスト・メッセージが報知されてもよい。特定の実施形態では、ロスト・メッセージがデータ・メッセージである場合のみ、ロスト・メッセージが報知されてもよい。特定の実施形態では、システムは、メッセージが欠落していると決定し、欠落しているメッセージを受信するための時間待機してもよい。欠落しているメッセージが時間内に受信されない場合、システムは、ロストとして欠落しているメッセージを報知してもよい。
受信されたメッセージのフェーズ番号が予想フェーズ番号と等しい場合(ブロック504で決定されるように)、ブロック506で、受信されたメッセージのシーケンス番号がブロック503で決定された予想シーケンス番号と比較される。
受信されたメッセージのシーケンス番号が予想シーケンス番号と等しくない場合(ブロック506で決定されるように)、ブロック505で、ロスト・メッセージが上記したように報知されてもよい。
受信されたメッセージのシーケンス番号が予想シーケンス番号と等しい場合(ブロック506で決定されるように)、ブロック507で、受信されたメッセージがデータ・メッセージである場合、制御はブロック508に進む。受信されたメッセージがストップ・メッセージである場合、制御はブロック509に進む。
受信されたメッセージがデータ・メッセージである場合、ブロック508で、データ・メッセージが処理される。例えば、受信されたデータ・メッセージは、アプリケーションに渡されてもよい。その後、制御はブロック501に戻る。
受信されたメッセージがストップ・メッセージである場合、ブロック509で、メッセージ・ストリーム・ステートが上述したようにクリアされ、制御がブロック501に戻る。
ハートビート・メッセージが組み込まれた特定の実施形態では、ブロック507から、制御はブロックに渡り、次の予想ハートビートタイムを更新し、制御が501に戻る。
IV.送信デバイス及び受信デバイスの例
図6は、送信デバイス600の例のブロック図を示す。送信デバイス600は、上述した手法を別々に及び組み合わせて実装されている。送信デバイス600は、メッセージ送信機601、メッセージ識別器602、フェーズ番号生成器603、シーケンス番号生成器604、及びメッセージ・ストリーム・ステート・クリヤラ605を含む。
特定の実施形態では、上述した手法のサブセット(及び/又は組み合わせのサブセット)のみが実装されてもよい。例えば、フェーズ番号手法を提供しない送信デバイスは、フェーズ番号生成器603を含まなくてもよい。
メッセージ送信機601がメッセージを送信する。例えば、メッセージ送信機601がデータ・メッセージ、ハートビート・メッセージ、及びストップ・メッセージを送信してもよい。利用される特定の手法に応じて、いくつかのメッセージタイプが送信されない場合がある。例えば、ストップ・メッセージのみを用いたフェーズ番号手法を利用する場合、ハートビート・メッセージは、送信されない。別の例として、フェーズ番号手法が増大間隔手法を用いたハートビート及びストップ・メッセージを利用し、それによってデータ・メッセージ、ハートビート・メッセージ、及びストップ・メッセージが送信されてもよい。また、特定の手法が利用されることに応じて、メッセージは、シーケンス番号、又はフェーズ番号とシーケンス番号の両方を含んでもよい。例えば、送信されたメッセージが増大間隔手法を用いたハートビートを利用し、フェーズ番号を含まなくてもよい。別の例として、送信されたメッセージがフェーズ番号手法を利用し、フェーズ番号とシーケンス番号の両方を含んでいてもよい。
メッセージ送信機601は、データを受信し、アプリケーションからデータ・メッセージを送信してもよい。メッセージ送信機601は、次のハートビートタイムを追跡してもよく、ハートビート・メッセージ及び/又はストップ・メッセージが、利用される特定の手法に基づいて、適切な間隔で送信されてもよい。
特定の実施形態では、別のメッセージ送信機が利用され、別のメッセージタイプを送信してもよい。
メッセージ識別器602は、送信されたメッセージのタイプを識別する。例えば、メッセージ識別器602は、データ・メッセージ、ハートビート・メッセージ、又はストップ・メッセージとして送信されるメッセージを識別してもよい。
フェーズ番号生成器603は、送信されるべきメッセージのフェーズ番号を決定し、提供する。フェーズ番号は、メッセージ送信機601に提供され、送信されるべきメッセージにはフェーズ番号が含まれる。フェーズ番号は、上述されたように決定されてもよい。送信されるべきメッセージがメッセージ・シーケンス内の第1のメッセージであるとき、例えば、前回のメッセージ・シーケンスのフェーズ番号を増加させる(又はこれ送信された第1のメッセージ・シーケンスである場合、“0”などの所定の値で開始する)、又はグローバル値又は関数から新しいフェーズ番号を取得することによって、フェーズ番号が取得されてもよい。送信されるべきメッセージがメッセージ・シーケンス内の第1のメッセージではない場合、フェーズ番号は、送信された最後のメッセージのフェーズ番号であると決定されてもよい。
シーケンス番号生成器604は、送信されるべきメッセージのシーケンス番号を決定し、提供する。シーケンス番号は、送信されるべきメッセージのタイプに基づいて決定されてもよい。シーケンス番号は、上述したように決定されてもよい。いくつかの実施形態では、ハートビート・メッセージ及び/又はストップ・メッセージのシーケンス番号は、送信された最後のデータ・メッセージのシーケンス番号と同じである。いくつかの実施形態では、ハートビート・メッセージ及び/又はストップ・メッセージのシーケンス番号は、最後のメッセージがデータ・メッセージであるかハートビート・メッセージであるかで、送信された最後のメッセージのシーケンス番号から増加される。いくつかの実施形態では、新しいメッセージ・シーケンスの第1のメッセージのために、シーケンス番号が所定の値にリセットされる。
メッセージ・ストリーム・ステート・クリヤラ605は、上述したようにストップ・メッセージが送信された後、メッセージ・ストリームをクリアする。
図7は、受信デバイス700の例のブロック図を示す。受信デバイス700は、上述した手法を別々に及び組み合わせて実装している。受信デバイス700は、メッセージ受信機701、メッセージ識別器702、フェーズ番号比較器705、シーケンス番号比較器706、ロスト・メッセージ報知機707、メッセージ・プロセッサ708、及びメッセージ・ストリーム・ステート・クリヤラ709を含む。
特定の実施形態では、上述した手法のサブセットのみ(及び/又は組み合わせのサブセット)が実装されてもよい。例えば、フェーズ番号手法を提供しない受信デバイスは、予想フェーズ番号生成器703及び/又はフェーズ番号比較器705を含まなくてもよい。
メッセージ受信機701は、メッセージを受信する。例えば、メッセージ受信機701は、データ・メッセージ、ハートビート・メッセージ、及びストップ・メッセージを受信してもよい。利用される特定の手法に応じて、いくつかのメッセージタイプが受信されなくてもよい。例えば、フェーズ番号手法は、ストップ・メッセージのみを利用し、ハートビート・メッセージを受信しない。別の例として、フェーズ番号手法は、増大間隔手法とストップ・メッセージ手法を用いたハートビートを利用してもよく、そしてデータ・メッセージ、ハートビート・メッセージ、及びストップ・メッセージを受信してもよい。また、利用される特定の手法に応じて、メッセージは、シーケンス番号又は、フェーズ番号とシーケンス番号の両方を含んでもよい。例えば、受信されたメッセージは、増大間隔手法を用いたハートビートを利用し、フェーズ番号を含まなくてもよい。別の例として、受信されたメッセージは、フェーズ番号手法を利用し、フェーズ番号とシーケンス番号の両方を含んでもよい。
メッセージ受信機701は、次の予想ハートビートタイムを追跡し、予想時間間隔内に受信された場合、ロストとしてハートビート・メッセージ及び/又はストップ・メッセージが検出されてもよい。例えば、予想時間間隔は、データ・メッセージと第1のハートビート・メッセージとの間の初期の時間間隔に基づいてもよく、又は予想時間間隔は、2つのハートビート・メッセージ間の間隔に基づいてもよい。例えば、初期の時間間隔及び/又は2つのハートビート・メッセージ間の間隔は、一定時間又は2倍増加し、ネットワーク遅延の変動を許容し、予想時間間隔を決定してもよい。
特定の実施形態では、別のメッセージ受信機が利用され、別のメッセージタイプを受信してもよい。
メッセージ識別器702は、受信されたメッセージのタイプを識別する。例えば、メッセージ識別器702は、受信されたメッセージをデータ・メッセージ、ハートビート・メッセージ、又はストップ・メッセージであることを識別してもよい。
予想フェーズ番号生成器703は、受信されたメッセージの予想フェーズ番号を決定し、提供する。フェーズ番号は、上述したように決定されてもよい。受信されたメッセージの予想フェーズ番号は、メッセージ・シーケンス内の前回受信されたメッセージのフェーズ番号と同じである、受信されたメッセージがメッセージ・シーケンスの第1のメッセージである(受信されたメッセージがないか、前回のメッセージがストップ・メッセージであるかどうかに基づいて決定され得る)場合、予想フェーズ番号は、受信機によってフェーズ番号が予測可能であるか否かに基づいて決定される。フェーズ番号が、受信機によって予測可能である場合、予想フェーズ番号は、所定の関数に基づいて決定されてもよい。例えば、予想フェーズ番号が、前回のメッセージ・シーケンスのフェーズ番号を増加する(又はこれが受信された第1のメッセージ・シーケンスの場合、“0”などの所定の値で開始する)ことによって決定されてもよい。フェーズ番号が受信機によって予測不可能である場合、メッセージ・シーケンス内の受信された第1のメッセージのフェーズ番号が予想フェーズ番号として取得され、前回のメッセージ・シーケンスのフェーズ番号と異なることが予想される。
予想シーケンス番号生成器704は、受信されたメッセージの予想シーケンス番号を決定し、提供する。予想シーケンス番号は、受信されたメッセージのタイプに基づいて決定されてもよい。予想シーケンス番号は、上述されたように決定されてもよい。いくつかの実施形態では、ハートビート・メッセージ及び/又はストップ・メッセージの予想シーケンス番号は、受信された最後のデータ・メッセージのシーケンス番号と同じである。いくつかの実施形態では、ハートビート・メッセージ及び/又はストップ・メッセージの予想シーケンス番号は、受信された最後のデータ・メッセージのシーケンス番号から増えている。いくつかの実施形態では、新しいメッセージ・シーケンスの第1のメッセージのために、予想シーケンス番号が所定の値にリセットされる。
フェーズ番号比較器705は、受信されたメッセージのフェーズ番号が、予想フェーズ番号生成器703によって提供された予想フェーズ番号と等しいかどうかを決定する。等しくない場合、ロスト・メッセージ報知機707が使用され、ロスト・メッセージが報知される。
シーケンス番号比較器706は、受信されたメッセージのシーケンス番号が予想シーケンス番号生成器704によって提供された予想シーケンス番号と等しいかどうかを決定する。等しくない場合、ロスト・メッセージ報知機707が使用され、ロスト・メッセージが報知される。
ロスト・メッセージ報知機707は、ロスト・メッセージを報知する。特定の実施形態では、ロスト・メッセージがデータ・メッセージである場合のみロスト・メッセージが報知されてもよい。特定の実施形態では、メッセージ受信機701は、メッセージが欠落していることを決定し、欠落しているメッセージを受信する時間待機する。欠落しているメッセージが時間内に受信されない場合、メッセージ受信機701は、その後、ロスト・メッセージ報知機707を使用し、ロストとして欠落しているメッセージを報知する。
メッセージ・プロセッサ708は、受信されたメッセージを処理する。例えば、受信されたデータ・メッセージは、アプリケーションに渡されてもよい。
メッセージ・ストリーム・ステート・クリヤラ709は、ストップ・メッセージが受信された後、上述したようにメッセージ・ストリーム・ステートをクリアする。
V.電子商取引システムの例
以上の説明から明らかなように、実施の形態は、データが接続されたデバイスによって送信される、及び、から受信されるネットワーク化された環境に適用される。そのような環境の例は、電子取引システムであり、電子取引所は市場データに関連するメッセージを取引デバイスに送信する。市場データは、例えば、価格データ、市場の深さデータ、最終取引量データ、及び/又は取引可能オブジェクトの市場に関連するいくつかのデータを含む。いくつかの電子取引システムでは、取引デバイスは、取引注文に関連するメッセージを電子取引所に送信する。取引注文を受信する際に、電子取引所は、取引注文を取引所注文ブックに入力し、取引注文の量と1つ以上の反対側の注文の量とをマッチさせるように試みる。特定の実施形態では、各注文は、その注文に関連するメッセージのために、関連付けられたメッセージ・ストリームを有していてもよい。
いくつかの電子取引システムでは、メッセージは、まれに送信される可能性がある。メッセージは、例えば、注文などの監視されるオブジェクトに関連付けられてもよい。例えば、注文のステートについての情報は、その注文のステートに変化があるときのみ送信されてもよい。注文のステートの変化は、例えば、フィル、部分的なフィル、注文価格の変化、又はキャンセルされた注文を含んでいてもよい。注文が市場から離れて実行中である場合、そのステートが1時間以上にわたって変化しない可能性がある。いくつかの場合、注文は、トリガされた注文などの、市場内で現在実行されていない注文であってもよく、ステートは数時間又は数日にわたって変化しない場合がある。そのようなトリガされた注文は、例えば、ホールド注文、取り消すまで有効な注文(good till canceled order)(“GTC”)、期間指定注文(good till date order)(“GTD”)、リミット・イフ・タッチド・オーダー(limit−if−touched order)、マーケット・イフ・タッチド・オーダー(market−if−touched order)、リミット・オン・クローズ・オーダー(limit−on−close order)、マーケット・オン・クローズ・オーダー(market−on−close order)、リミット・オン・オープン・オーダー(limit−on−open order)、及びマーケット・オン・オープン・オーダー(market−on−open order)を含んでもよい。満たされた注文はまた、市場内では現在実行されていない。
別の例として、例えば、サーバがアクセス可能であるかアクセス不可能であるか、及び取引所への接続がアクセス可能であるかアクセス不可能であるかなどのステート変化に関連するサーバについての情報が、まれに送信される場合がある。別の例として、ニュース・メッセージなどの注文に関連しないメッセージが、まれに送信される場合がある。別の例として、ファイル及び初期の注文ブックのダウンロードが、例えば、起動時及びロスト・メッセージが続いて検出されたときに、まれに行われる場合がある。シングルトレーダーは、大量の注文をする必要はないかもしれないが、注文ブックが複数のユーザによって共有されている場合、組み合わせで、大量の注文又は共有された注文ブックに関連するステートの他のタイプが、まれに情報を送信することがある。例えば、リスク管理などの管理者が、トレーダーごとに注文ブックにアクセスする可能性がある。別の例として、特定の会社ですべてのトレーダーは、取引所で、同じアカウントで取引することから、特定の会社ですべてのトレーダーが注文ブックを共有する可能性がある。注文ブックを提供する場合、注文ブックを共有している各受信者は、潜在的に注文ブックに関連したメッセージを受信してもよい。
図8は、特定の実施形態で採用され得る電子取引システム800のブロック図を示す。システム800は、取引デバイス810、ゲートウェイ820、及び電子取引所830を含む。取引デバイス810は、ゲートウェイ820と通信する。ゲートウェイ820は、取引所830と通信する。
本明細書で使用するように、語句“通信する”とは、直接通信及び1つ以上の中間構成要素を介しての間接通信を含んでもよい。
操作中、取引デバイス810は、注文を送信し、取引所830で取引可能オブジェクトを買ってもよく、又は売ってもよい。例えば、ユーザは、取引デバイス810を利用し、注文を送信してもよい。注文は、ゲートウェイ820を通って取引所830に送信される。また、市場データは、取引所830からゲートウェイ820を通って取引デバイス810に送信される。ユーザはまた、取引デバイス810を利用し、この市場データを監視し、及び/又は決定をベースとし、市場データ上の取引可能オブジェクトの注文を送信してもよい。
取引可能オブジェクトは、量及び/又は価格と共に取引できるものである。例えば、株、オプション、債券、先物、通貨、ワラント、ファンドデリバティブ、証券、商品、スワップ、金利商品、インデックスベースの製品、取引されるイベント、グッズ、及びコレクション、及び/又はこれらの組み合わせなどが、取引可能オブジェクトであってもよい。取引可能オブジェクトは、「リアル(real)」又は「合成(synthetic)」であってもよい。リアル取引可能オブジェクトは、取引所によってリストに記載された及び/又は管理された生産物を含む。合成取引可能オブジェクトは、ユーザによって定義された生産物を含む。例えば、合成取引可能オブジェクトは、取引デバイス810を利用するトレーダーによって作成されたリアル(又は他の合成)の生産物の組み合わせ、例えば、合成スプレッドなどを含んでもよい。合成取引オブジェクトに対応する及び/又は同様のリアル取引可能オブジェクトがあってもよい。
取引デバイス810は、例えば、ハンドヘルドデバイス、ラップトップ、デスクトップコンピュータ、シングル又はマルチコアプロセッサを有するワークステーション、複数のプロセッサを有するサーバ、及び/又はコンピュータのクラスタを含んでいてもよい。例えば、単一のデバイスとして論理的に表されているが、取引デバイス810は、サーバと通信する取引端末を含んでいてもよく、取引端末とサーバは、一括して取引デバイスであってもよい。取引端末は、取引画面をユーザに提供してもよく、コマンドをサーバに送信し、さらに取引画面を介して、発注などのユーザの入力の処理を行ってもよい。
取引デバイス810は、一般的に、ユーザによって、所有され、操作され、制御され、プログラムされ、構成され、又は他のものが使用される。本明細書で使用されるように、語句「ユーザ」は、限定されるものではないが、人(例えば、トレーダ)又は電子取引デバイス(例えば、アルゴリズム取引システム)を含んでもよい。1人以上のユーザは、例えば、所有権、操作、制御、プログラミング、構成、又は他の使用に関与してもよい。
取引デバイス810は、1つ以上の取引アプリケーションを含んでいてもよい。取引アプリケーションは、例えば、取引ウィンドウ及びチャートウィンドウに市場データを配置し、表示することによって市場データを処理してもよい。市場データは、例えば、取引所830から受信してもよい。別の例として、市場データは、履歴データを提供する及び/又は実際の世界の取引を実現せずに取引をシミュレートするシミュレーション環境から受信されてもよい。処理は、例えば、ユーザの好みに基づいてもよい。取引アプリケーションが取引デバイス810のコンピュータデバイスの1つ以上にわたって分散されてもよい。例えば、取引アプリケーションの特定の構成要素が、取引ワークステーションで実行されてもよく、取引アプリケーションの他の構成要素が、ワークステーションと通信するサーバ上で実行されてもよい。
取引デバイス810は、例えば、電子取引ワークステーション、ポータブル取引デバイス、“ブラックボックス”又は“グレーボックス”システムなどのアルゴリズム取引システム、組み込み取引システム、及び/又は自動取引ツールを含んでいてもよい。例えば、取引デバイス810は、イリノイ州のシカゴのトレーディング・テクノロジーズ・インターナショナル・インコーポレイテッドによって提供される電子取引プラットフォームである、X_TRADER(登録商標)のコピーを実行するコンピュータシステムであってもよい。別の例として、取引デバイス810は、トレーディング・テクノロジーズ・インターナショナル・インコーポレイテッドによってまた提供されるAutospreader(登録商標)及び/又はAutotrader(商標)などの自動取引ツールを実行するコンピュータデバイスであってもよい。
別の例として、取引デバイス810は、アルゴリズム的に市場データを処理し、アルゴリズムの処理に基づいて注文を手動で配置するためのユーザインタフェースを含み、発注された注文を自動的に操作する取引アプリケーションを含んでいてもよい。アルゴリズム取引アプリケーションは、特定の動作を行う自動処理アルゴリズムを含む取引アプリケーションである。即ち、取引アプリケーションは、例えば、定義された動作を実行する自動化された一連の命令を含む。動作は、特定の方法で市場データを処理すること、発注すること、既存の注文を変更すること、注文を削除すること、発注しないこと、どの取引可能オブジェクトが実行されるかを選択すること、発注又は注文変更の価格を決定すること、発注又は注文の量を決定すること、注文が買いか売りかを決定すること、ある時間動作を遅延させること、を含んでもよい。
本明細書で使用されるように、アルゴリズム(取引アルゴリズムとも呼ばれている)は、取引に使用されるアルゴリズムを記述する論理式及びパラメータを含む定義によって特定される。論理式は、パラメータ間の関係を特定し、より多くのパラメータを生成してもよい。パラメータは、例えば、アルゴリズムの論理式への入力を含んでもよい。アルゴリズムの定義は、少なくとも一部では、アルゴリズム取引アプリケーションによって特定されてもよい。例えば、アルゴリズム取引アプリケーションは、ユーザにパラメータを特定させるのみを可能にし、所定の論理式によって使用されてもよい。別の例として、アルゴリズム取引アプリケーションは、ユーザに論理式のうちのいくつか又はすべて及びパラメータのうちのいくつか又はすべてを特定することを可能にしてもよい。論理式がユーザによって特定された取引アルゴリズムは、ユーザ定義の取引アルゴリズムである。
取引アプリケーションは、取引デバイス810のコンピュータ読み取り可能な記録媒体に記憶されてもよい。特定の実施形態では、取引アプリケーションの1つ以上の構成要素が取引ワークステーションに記憶されてもよく、取引アプリケーションの他の構成要素がワークステーションと通信するサーバ上に記憶されてもよい。特定の実施形態では、取引アプリケーションの1つ以上の構成要素が別のコンピュータ読み取り可能な記録媒体から取引デバイス810のコンピュータ読み取り可能な記録媒体へロードされてもよい。例えば、取引アプリケーション(又は取引アプリケーションの更新)は、メーカー、開発者、又は1つ以上のCD若しくはDVDの発行者によって記憶されてもよく、その後アプリケーションを取引デバイス810上に、又は取引デバイス810が取引アプリケーションを取得するサーバに、アプリケーションをロードする責任のある者に提供される。別の例として、取引デバイス810は、例えば、インターネット又は内部ネットワークを介して、サーバから取引アプリケーション(又は取引アプリケーションの更新)を受信してもよい。取引デバイス810は、取引デバイス810によって要求されたとき(“プル配信”)、及び/又は取引デバイスによって要求されないとき(“プッシュ配信”)、取引アプリケーション又は更新を受信してもよい。
取引デバイス810は、取引可能オブジェクトの注文を送信するように構成される。注文は、例えば、1つ以上のメッセージ若しくはデータパケットに、又は共有メモリシステムを通して送信される。取引デバイス810はまた、例えば、注文のキャンセル、注文の変更、及び/又は取引所への問合せをするように構成されてもよい。別の例として、取引デバイス810は、実際の世界の取引を実現しないシミュレーション環境にシミュレートされた取引所に注文を送信するように構成されてもよい。
取引デバイス810によって送信された注文は、例えば、ユーザの要求又は自動的に送信されてもよい。例えば、トレーダーは、電子取引ワークステーションを利用し、特定の取引可能オブジェクトを発注し、注文価格及び/又は量などの注文のための1つ以上のパラメータを手動で提供する。別の例として、自動化された取引ツールが注文のための1つ以上のパラメータを計算し、注文を自動的に送信してもよい。いくつかの場合では、自動化された取引ツールは、送信されるべき注文を準備し、実際それをユーザからの確認することなしに送信することはない。
特定の実施形態では、取引デバイス810は、ユーザインタフェースを含む。ユーザインタフェースは、取引アプリケーションのテキストベース及び/又はグラフィカルインタフェースを表す1つ以上のディスプレイデバイスを含んでいてもよい。例えば、ディスプレイデバイスは、コンピュータモニタ、ハンドヘルド・デバイス・ディスプレイ、プロジェクタ、及び/又はテレビを含んでいてもよい。ユーザインタフェースは、例えば、入力を受信するための1つ以上の入力デバイスを含んでもよい。例えば、入力デバイスは、キーボード、トラックボール、2つ又は3つのボタンマウス、及び/又はタッチスクリーンを含んでいてもよい。ユーザインタフェースは、ユーザと対話するための他のデバイスを含んでいてもよい。例えば、情報が音声でスピーカーを介してユーザに提供されてもよく、及び/又はマイクを介して受信されてもよい。
特定の実施形態では、取引アプリケーションは、1つ以上の取引画面を含み、ユーザが1つ以上の市場と対話可能にしている。取引画面は、例えば、様々な取引戦略を実施しながら、ユーザが市場情報を取得し、かつ見て、注文エントリーパラメータをセットし、注文を入力及びキャンセルし、及び/又はポジションを監視することを可能にしてもよい。例えば、取引アプリケーションが、取引所830から情報(例えば、ビッド価格、ビッド量、アスク価格、アスク量、過去に売った価格及び量、及び/又は他の市場の関連情報など)を受信してもよく、それらのいくつか又はすべてが順番に取引デバイスのユーザインタフェースを用いて表示されてもよい。受信された情報に基づいて、取引画面は、価格レベルのレンジと、取引可能オブジェクトに関する価格レベルの対応するビッド及びアスク量と、を表示してもよい。関連取引情報をユーザに提供するために、取引画面は、内部市場の周囲に価格(と対応するビッド及びアスク量)のレンジを表示してもよい。情報は、連続的に又は定期的に取引アプリケーションに提供され、取引アプリケーションが現在の市場情報と共に取引画面を更新可能にしてもよい。ユーザは、例えば、取引画面を使用し、取引可能オブジェクトの買い及び売り注文を出し、又はそれ以外の場合、表示された情報に基づいて取引可能オブジェクトを取引してもよい。
取引画面は、1つ以上の取引ツールを表示してもよい。取引ツールは、電子ツールであり、電子取引を可能にし、補助し、及び/又は容易にする。代表的な取引ツールは、限定されるものではないが、チャート、取引ラダー、注文入力ツール、自動化された取引ツール、自動化されたスプレッドツール、リスク管理ツール、注文パラメータツール、注文入力システム、市場グリッド、フィルウィンドウ、及び市場注文ウィンドウ、それらの組み合わせ、取引、取引の準備、取引の管理、又は市場の分析に使用される他の電子ツールを含んでいてもよい。
特定の実施形態では、取引デバイス810からの注文は、ゲートウェイ820を通って取引所830に送信される。取引デバイス810は、例えば、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、無線ネットワーク、仮想プライベート・ネットワーク、T1ライン、T3回線、統合サービスデジタル網(“ISDN”)線、ポイント・オブ・プレゼンス(POP)、インターネット、及び/又は共有メモリシステムを使用してゲートウェイ820と通信することができる。
ゲートウェイ820は、取引デバイス810及び取引所830と通信するように構成されている。ゲートウェイ820は、取引デバイス810と取引所830との間の通信を簡単にする。例えば、ゲートウェイ820は、取引デバイス810から注文を受信し、取引所830に注文を送信してもよい。別の例として、ゲートウェイ820は、取引所830から市場データを受信し、取引デバイス810に市場データを送信してもよい。
特定の実施形態では、ゲートウェイ820は、取引デバイス810と取引所830との間で通信されたデータの処理を行う。例えば、ゲートウェイ820は、取引デバイス810から受信された注文を取引所830によって理解されるデータフォーマットに処理してもよい。同様に、ゲートウェイ820は、取引所830から受信された取引所の特有のフォーマットの市場データを、取引デバイスによって理解されるフォーマットに変換してもよい。ゲートウェイ820の処理はまた、例えば、取引デバイス810からの取引注文を追跡すること、及び取引所830から受信されたフィル確認に基づいて注文の状態を更新することを含んでもよい。別の例として、ゲートウェイ820は、取引所830からの市場データをまとめ、それを取引デバイス810に提供してもよい。
特定の実施形態では、ゲートウェイ820は、取引デバイス810と取引所830との間で通信されるデータを処理する以外のサービスを提供する。例えば、ゲートウェイ820は、リスク処理を提供してもよい。
ゲートウェイ820は、例えば、ハンドヘルドデバイス、ラップトップ、デスクトップコンピュータ、シングルコア又はマルチコアプロセッサを有するワークステーション、複数のプロセッサを有するサーバ、及び/又はコンピュータのクラスタなどの1つ以上のコンピュータプラットフォームを含んでいてもよい。
ゲートウェイ820は、1つ以上のゲートウェイアプリケーションを含んでいてもよい。ゲートウェイアプリケーションは、例えば、注文処理及び市場データ処理を扱うことができる。この処理は、例えば、ユーザの好みに基づいてもよい。
特定の実施形態では、ゲートウェイ820は、例えば、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、仮想プライベート・ネットワーク、T1ライン、T3回線、ISDN回線、ポイント・オブ・プレゼンス(POP)、インターネット、及び/又は共有メモリシステムを使用して取引所830と通信する。
一般的に、取引所830は、取引所エンティティによって所有され、操作され、制御され、又は使用され得る。取引所エンティティの例は、CMEグループ、ロンドン国際金融先物取引所(“LIFFE”)、インターコンチネンタル取引所(“ICE”)、及びユーレックスを含む。取引所830は、例えば、取引所によって取引を申し込まれた、取引可能オブジェクトが売買されることを可能にするよう構成された、コンピュータ、サーバ、又は他のコンピュータデバイスなどの電子マッチングシステムを含んでいてもよい。電子マッチングシステムは、別のエンティティを含み、例えば、いくつかが取引可能オブジェクト及び注文を受信してマッチする他のものをリストにしてもよく、及び/又は管理してもよい。取引所830は、例えば、電子通信ネットワーク(“ECN”)を含んでもよい。
取引所は、取引可能オブジェクトを売買するために注文をマッチするよう構成されている。取引可能オブジェクトは、取引所830によって取引のためにリストにされてもよい。注文は、例えば、取引デバイス810から受信された注文を含んでもよい。注文は、例えば、ゲートウェイ820を通って取引デバイス810から受信されてもよい。また、注文は、取引所830と通信する他のデバイスから受信されてもよい。即ち、典型的に、取引所830は、マッチすべき注文も提供する(取引デバイス810と同様であり得る)様々な他の取引デバイスと通信する
取引所830は、市場データを提供するよう構成されてもよい。市場データは、例えば、1つ以上のメッセージ若しくはデータパケットに、又は共有メモリシステムを通って提供されてもよい。市場データは、例えば、取引デバイス810に提供されてもよい。市場データは、例えば、取引デバイス810にゲートウェイ820を通って提供されてもよい。市場データは、例えば、内部市場を示すデータを含んでもよい。市場データは、(内部市場が時間と共に変化するので)特定の時点での最低の売り価格(“ベストアスク”とも呼ばれる)と最高の買い価格(“ベストビッド”とも呼ばれる)である。市場データは、市場の深さを含んでいてもよい。市場の深さは、内部市場で入手可能な量を示しており、また内部市場から離れた他の価格で入手可能な量を示している。したがって、内部市場は、市場の深さの第1のレベルと見なすことができる。内部市場から離れた1つのティックは、例えば、内部市場の第2のレベルと見なしてもよい。特定の実施形態では、市場の深さは、全ての価格レベルに提供されている。特定の実施形態では、市場の深さは、全ての価格レベルより少なく提供されている。例えば、市場の深さは、内部市場の両側の最初の5つの価格レベルのみに提供されてもよい。別の例として、市場の深さは、市場内で入手可能な量である最初の10個の価格レベルに提供されてもよい。市場データはまた、最終取引価格(LTP)、最終取引量(LTQ)、及び注文フィル情報などの情報を含んでいてもよい。
特定の実施形態では、システム800は、複数の取引デバイス810を含んでいる。例えば、上述の取引デバイス810と同様の複数の取引デバイスは、ゲートウェイ820と通信し、注文を取引所830に送信してもよい。
特定の実施形態では、システム800は、複数のゲートウェイ820を含んでいる。例えば、上述のゲートウェイ820と同様の複数のゲートウェイは、取引デバイス810及び取引所830と通信してもよい。そのような構成は、例えば、1つのゲートウェイに障害が発生した場合に、冗長性を提供するために使用され得る。
特定の実施形態では、システム800は、複数の取引所830を含んでいる。例えば、ゲートウェイ820は、上述の取引所830と同様の複数の取引所と通信してもよい。そのような構成は、例えば、取引デバイス810が、ゲートウェイ820を通して複数の取引所で取引可能にすることができる。
特定の実施形態では、システム800は、複数の取引所830と複数のゲートウェイ820とを含んでいる。例えば、ゲートウェイ820と同様の複数のゲートウェイは、上述の取引所830と同様の複数の取引所と通信してもよい。各ゲートウェイは、例えば、1つ以上の別の取引所と通信してもよい。そのような構成は、例えば、1つ以上の取引デバイス810が複数の取引所で取引可能にすること(及び/又は複数の取引所への接続の冗長性を提供すること)ができる。
特定の実施形態では、取引デバイス810は、1つ以上のコンピュータデバイス又は処理コンポーネントを含んでいる。言い換えれば、取引デバイス810の機能は、複数のコンピュータデバイスによって実行されてもよい。例えば、1つのコンピュータデバイスが、取引所830に送信されるべき注文を生成してもよく、一方で別のコンピュータデバイスがユーザにグラフィカル・ユーザ・インタフェースを提供してもよい。特定の実施形態では、ゲートウェイ820は、1つ以上のコンピュータデバイス又は処理コンポーネントを含んでいる、言い換えれば、ゲートウェイ820の機能は、複数のコンピュータデバイスによって実行されてもよい。特定の実施形態では、取引所830は、1つ以上のコンピュータデバイス又は処理コンポーネントを含んでいる。言い換えれば、取引所830の機能は、複数のコンピュータデバイスによって実行されてもよい。
特定の実施形態では、ゲートウェイ820は、取引デバイス810の一部である。例えば、ゲートウェイ820のコンポーネントは、取引デバイス810と同じコンピュータプラットフォームの一部であってもよい。別の例として、ゲートウェイ820の機能は、取引デバイス810のコンポーネントによって実行されてもよい。特定の実施形態では、ゲートウェイ820は存在しない。例えば、取引デバイス810が、取引所830と通信するために、ゲートウェイ820を利用する必要がない場合に、そのような構成にしてもよい。例えば、取引デバイス810が、取引所830と直接通信するように構成されている場合である。
特定の実施形態では、ゲートウェイ820は、取引デバイス810と同じ側に物理的に配置されている。特定の実施形態では、ゲートウェイ820は、取引所830と同じ側に物理的に配置されている。特定の実施形態では、取引デバイス810は、取引所830と同じ側に物理的に配置されている。特定の実施形態では、ゲートウェイ820は、取引デバイス810と取引所830との両方と別の側に物理的に配置されている。
特定の実施形態では、システム800は、ミドルウェア、ファイアーウォール、ハブ、スイッチ、ルータ、取引所特有の通信設備、モデム、セキュリティ管理、及び/又は暗号化/復号化デバイスなどの通信アーキテクチャに固有の他のデバイスを含んでもよい。
図9は、図8の電子取引システム800の実施例900を示す。システム900は、取引デバイス810a−810e、ゲートウェイ820、取引所830、第1のWANルータ940、第2のWANルータ950、及びWANリンク960を含んでいる。取引デバイス810aと810bは、ゲートウェイ820と通信している。ゲートウェイ820は、取引所830と通信している。取引デバイス810c−810eは、WANルータ940とWANルータ950とを使用してゲートウェイ820と通信する。
操作中、取引デバイス810a−810eは、注文を送信し、取引所830で取引可能オブジェクトを買ってもよく、又は売ってもよい。例えば、ユーザは、取引デバイス810a−810eを利用し、注文を送信してもよい。注文は、取引デバイス810aと810bから、ゲートウェイ820を通って、取引所830に送信される。注文は、取引デバイス810c−810eから、WANルータ950と940を通って、ゲートウェイ820に送信され、ゲートウェイ820を通って、取引所830に送信される。また、市場データは、取引所830からゲートウェイ820を通って取引デバイス810aと810bとWANルータ940とに送信される。市場データは、WANルータ940からWANルータ950に送信され、その後WANルータ950から取引デバイス810c−810eに送信される。
電子取引システム800の実施例900では、例えば、WANルータ940でメッセージ遅延及び/又はロスが生じる可能性がある。メッセージ遅延及び/又はロスは、例えば、WANルータ940のメッセージのドロップに起因する、又はWANルータ940、WANルータ950、及び/又はWANリンク960の障害に起因する可能性がある。例えば、WANルータ940は、メモリ又は処理容量を使い果たすなどのリソースの制限に起因して、及び/又はWANリンク960経由でメッセージを送信することの遅延によって、メッセージをドロップする可能性がある。別の例として、WANルータ940及び/又はWANルータ950は、電力損失又はハードウェアの障害に起因して失敗することがある。別の例として、WANリンク960は、ケーブル切断又はハードウェア障害によって失敗することがある。
上述した様々な手法及び実施形態は、電子取引システムに採用され得る。例えば、図8の電子取引システム800の例は、図2Cに関連して記載された例示の方法を実施できる。例示の方法は、図8のゲートウェイ820から取引デバイス810に送信されるメッセージに、シーケンス番号を関連付ける。例示の方法によってシーケンス番号をデータ及びハートビート・メッセージに関連付けることは、図8の取引デバイス810が、データ・メッセージが失われて、次のメッセージが受信されるまでの時間内にロスト・メッセージを検出可能にする。
別の例として、図8の電子取引システムの例は、図2Dに関連して記載された例示の方法を実施してもよい。図8の取引デバイス810は、ゲートウェイ820からメッセージを受信する。取引デバイス810は、ゲートウェイ820から送信されるべきメッセージの予想シーケンス番号を決定する。取引デバイス810は、受信されたメッセージのシーケンス番号を予想シーケンス番号と比較し、データ・メッセージが失われたかどうかを決定する。
別の例として、図8の電子取引システム800の例は、図4に関連して記載された例示の方法を実施してもよい。例示の方法は、図8のゲートウェイ820によって取引デバイス810に送信されるメッセージにシーケンス番号及びフェーズ番号を関連付ける。例示の方法によって、シーケンス番号及びフェーズ番号をメッセージ・シーケンスに関連付けることは、図8の取引デバイス810が、ロスト・メッセージ・シーケンスを検出可能にする。さらに、例示の方法は、ゲートウェイ820が、メッセージ・シーケンスを完全に送信した後、メッセージ・ストリーム・ステートをクリアすることを可能にする。
別の例として、図8の電子取引システム800の例は、図5に関連して記載された例示の方法を実施してもよい。図8の取引デバイス810は、ゲートウェイ820からメッセージを受信する。取引デバイス810は、ゲートウェイ820から受信されたメッセージのフェーズ番号及びシーケンス番号をそれぞれ、予想フェーズ番号及びシーケンス番号と比較し、メッセージが失われたかどうかを決定する。また、例示の方法は、取引デバイス810が、メッセージ・シーケンスを完全に受信した後、メッセージ・ストリーム・ステートをクリアすることを可能にする。
説明された図のいくつかは、例示のブロック図、システム、及び/又は特定の実施形態のすべて又は一部を実施するために使用され得る方法を示したフロー図が図示されている。構成要素、要素、ブロックのうちの1つ以上、及び/又は例示のブロック図、システムの機能、及び/又はフロー図は、例えば、単独、又は有形のコンピュータ読み取り可能な記録媒体上に記憶された一連のコンピュータ読み取り可能な命令として、ハードウェア、ファームウェア、個別論理の組み合わせ、及び/又はそれらのいくつかの組み合わせを実施してもよい。
例示のブロック図、システム、及び/又はフロー図は、例えば、特定用途向け集積回路(ASIC)、プログラム可能論理デバイス(PLD)、フィールド・プログラマブル・ロジック・デバイス(FPLD)、離散論理、ハードウェア、及び/又はファームウェアのいくつかの組み合わせを使用して実施することができる。
例示のブロック図、システム、及び/又はフロー図は、例えば、1つ以上のプロセッサ、コントローラ、及び/又は他の処理デバイスを使用して実行することができる。例えば、それらの例は、例えば、有形のコンピュータ読み取り可能な記録媒体に記憶されたコンピュータ読み取り可能な命令などのコード化された命令を使用して実行されてもよい。有形のコンピュータ読み取り可能な記録媒体は、様々なタイプの揮発性及び不揮発性記録メディアを含んでもよく、例えば、ランダム・アクセス・メモリ(RAM)、リード・オンリー・メモリ(ROM)、プログラマブル・リード・オンリー・メモリ(PROM)、電気的プログラマブル・リード・オンリー・メモリ(PROM)、電気的に消去可能なリード・オンリー・メモリ(EPROM)、フラッシュメモリ、ハードディスクドライブ、光学メディア、磁気テープ、ファイルサーバ、いくつかの他の有形データ記憶デバイス、又はそれらのいくつかの組み合わせを含んでもよい。有形のコンピュータ読み取り可能な記録媒体は、非一時的である。
さらに、例示のブロック図、システム、及び/又はフロー図は、図に関連して上記されており、他の実施形態を採用してもよい。例えば、コンポーネント、要素、ブロック、及び/又は機能の実行の順番は、変更されてもよく、上記したコンポーネント、要素、ブロック、及び/又は機能は、変更、削除、細分化、又は組み合わせてもよい。また、コンポーネント、要素、ブロック、及び/又は機能のいくつか又はすべては、例えば、別の処理スレッド、プロセッサ、デバイス、個別論理、及び/又は回路によって、連続して及び/又は並行して行われてもよい。
実施の形態が開示されているが、様々な変更を行ってもよく、同等のものに置換されてもよい。さらに、特定の状況又は材料に適合させるように、多くの修正が行われてもよい。したがって、開示された技術は、開示された特定の実施形態に限定されないが、添付の特許請求の範囲内にすべての実施形態を包含することを意図している。

Claims (31)

  1. コンピュータが、メッセージ・ストリームを通じて送信するべき新しいメッセージを検出するステップ、ここでメッセージ・ストリームとは、関連するメッセージの論理通信チャンネルである、
    コンピュータが、新しいメッセージのフェーズ番号を決定するステップ、ここでフェーズ番号は、あるメッセージ・シーケンスに対して同じ値に保持される一方、前記新しいメッセージの前に送信されたメッセージがストップ・メッセージである場合、メッセージ・ストリームを遮断することなく、別の値にセットされる、
    コンピュータが、新しいメッセージのシーケンス番号を決定するステップ、ここでシーケンス番号は、前記新しいメッセージの前に送信されたメッセージがストップ・メッセージである場合、リセットされる、
    コンピュータが、フェーズ番号とシーケンス番号とを有する新しいメッセージを、メッセージ・ストリームを通じて送信するステップ、
    を含む方法。
  2. 送信するべき新しいメッセージを検出するステップは、タイマーの時間切れに基づいて行われる、ここでタイマーは、最後のメッセージが送信された後の第1の時間間隔である、請求項1に記載の方法。
  3. 最後のメッセージは、データ・メッセージである、請求項2に記載の方法。
  4. 最後のメッセージは、ハートビート・メッセージである、請求項2に記載の方法。
  5. 第1の時間間隔は、前回の時間間隔から一定時間増加させた時間間隔である、ここで前回の時間間隔は、最後から2つめのメッセージが送信されたときと最後のメッセージが送信されたときとの間の時間間隔である、請求項4に記載の方法。
  6. 第1の時間間隔は、前回の時間間隔の倍数、前回の時間間隔の指数、素数シーケンス、及びフィボナッチ・シーケンスのうちの1つに基づいて、前回の時間間隔から増加させた時間間隔である、請求項5に記載の方法。
  7. 送信するべき新しいメッセージを検出するステップは、アプリケーションから受信するデータに基づく、請求項1に記載の方法。
  8. 新しいメッセージは、データ・メッセージである、請求項1または7に記載の方法。
  9. データ・メッセージは、取引可能オブジェクトの注文に関連するデータを含む、請求項8に記載の方法。
  10. 新しいメッセージは、ハートビート・メッセージである、請求項1〜6のいずれか一項に記載の方法。
  11. ハートビート・メッセージのシーケンス番号は、送信された最後のデータ・メッセージのシーケンス番号と同じである、請求項10に記載の方法。
  12. 新しいメッセージは、ストップ・メッセージもあることを示すフラグを含む、請求項1〜11のいずれか一項に記載の方法。
  13. 新しいメッセージは、ストップ・メッセージである、請求項1〜11のいずれか一項に記載の方法。
  14. 更に、コンピュータが、メッセージ・ストリーム・ステートをクリアするステップを含む、ここでメッセージ・ストリーム・ステートは、ストップ・メッセージが送信された後にクリアされ、又、メッセージ・ストリーム・ステートは、メッセージ・ストリームを特定する情報を含むものであり、関連するメッセージの論理通信チャンネルである、請求項12または13に記載の方法。
  15. メッセージ・ストリームを特定する情報は、フェーズ番号を含む、請求項14に記載の方法。
  16. メッセージ・ストリーム・ステートをクリアするステップは、コンピュータのメモリからメッセージ・ストリーム・ステートを割り当て解除することを含む、請求項14または15に記載の方法。
  17. コンピュータに請求項1〜16のいずれか一項に記載の方法を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
  18. コンピュータに請求項1〜16のいずれか一項に記載の方法を実行させるためのプログラム。
  19. メッセージ・ストリームを通じて送信するべき新しいメッセージを検出する新しいメッセージ検出器、ここでメッセージ・ストリームとは、関連するメッセージの論理通信チャンネルである、
    新しいメッセージのフェーズ番号を決定するフェーズ番号生成器、ここでフェーズ番号は、あるメッセージ・シーケンスに対して同じ値で保持される一方、前記新しいメッセージの前に送信されたメッセージがストップ・メッセージである場合、メッセージ・ストリームを遮断することなく、別の値にセットされる、
    新しいメッセージのシーケンス番号を決定するシーケンス番号生成器、ここでシーケンス番号は、前記新しいメッセージの前に送信されたメッセージがストップ・メッセージである場合、リセットされる、
    フェーズ番号とシーケンス番号とを有する新しいメッセージを、メッセージ・ストリームを通じて送信するメッセージ送信機、
    を含む、システム。
  20. コンピュータが、メッセージ・ストリームを通じて新しいメッセージを受信するステップ、ここでメッセージ・ストリームとは、関連するメッセージの論理通信チャンネルであり、新しいメッセージは、メッセージ・フェーズ番号とメッセージ・シーケンス番号とを含む一方、フェーズ番号は、あるメッセージ・シーケンスに対して同じ値で保持される一方、前記新しいメッセージの前に送信されたメッセージがストップ・メッセージである場合、メッセージ・ストリームを遮断することなく、別の値にセットされており、且つシーケンス番号は、前記新しいメッセージの前に送信されたメッセージがストップ・メッセージである場合、リセットされている、
    コンピュータが、新しいメッセージの予想フェーズ番号を決定するステップ、
    コンピュータが、新しいメッセージの予想シーケンス番号を決定するステップ、
    コンピュータが、メッセージ・フェーズ番号を予想フェーズ番号と比較するステップ、
    コンピュータが、メッセージ・シーケンス番号を予想シーケンス番号と比較するステップ、
    コンピュータが、(a)メッセージ・フェーズ番号と予想フェーズ番号、(b)メッセージ・シーケンス番号と予想シーケンス番号の少なくとも一方がマッチしないとき、ロスト・メッセージを報知するステップ、
    を含む、方法。
  21. 予想フェーズ番号は、前回のメッセージがストップ・メッセージではなかったとき、前回のメッセージのメッセージ・フェーズ番号と同じである、請求項20に記載の方法。
  22. 予想フェーズ番号は、前回のメッセージがストップ・メッセージであったとき、メッセージ・フェーズ番号と同じである、請求項20に記載の方法。
  23. 予想シーケンス番号は、前回のメッセージのシーケンス番号に基づく、請求項20〜22のいずれか一項に記載の方法。
  24. 予想シーケンス番号は、前回のシーケンス番号を増加することによって決定される、請求項23に記載の方法。
  25. 予想シーケンス番号は、新しいメッセージがハートビート・メッセージであるとき、前回のデータ・メッセージのシーケンス番号と同じである、請求項20〜22のいずれか一項に記載の方法。
  26. 予想シーケンス番号は、新しいメッセージがストップ・メッセージであるとき、前回のデータ・メッセージのシーケンス番号と同じである、請求項20〜22のいずれか一項に記載の方法。
  27. 更に、新しいメッセージがデータ・メッセージであるとき、コンピュータが、新しいメッセージ内のデータを処理するステップを含む、請求項20〜24及び26のいずれか一項に記載の方法。
  28. 更に、新しいメッセージがストップ・メッセージであるとき、コンピュータが、メッセージ・ストリーム・ステートをクリアするステップを含む、ここでメッセージ・ストリーム・ステートは、メッセージ・ストリームを特定する情報を含むものであり、関連するメッセージの論理通信チャンネルである、請求項20〜27のいずれか一項に記載の方法。
  29. コンピュータに請求項20〜28のいずれか一項に記載の方法を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
  30. コンピュータに請求項20〜28のいずれか一項に記載の方法を実行させるためのプログラム。
  31. メッセージ・ストリームを通じて新しいメッセージを受信するメッセージ受信機、ここでメッセージ・ストリームとは、関連するメッセージの論理通信チャンネルであり、新しいメッセージは、メッセージ・フェーズ番号とメッセージ・シーケンス番号とを含む一方、フェーズ番号は、あるメッセージ・シーケンスに対して同じ値で保持される一方、前記新しいメッセージの前に送信されたメッセージがストップ・メッセージである場合、メッセージ・ストリームを遮断することなく、別の値にセットされており、且つシーケンス番号は、前記新しいメッセージの前に送信されたメッセージがストップ・メッセージである場合、リセットされている、
    新しいメッセージの予想フェーズ番号を決定する予想フェーズ番号生成器、
    新しいメッセージの予想シーケンス番号を決定する予想シーケンス番号生成器、
    メッセージ・フェーズ番号を予想フェーズ番号と比較するフェーズ番号比較器、
    メッセージ・シーケンス番号を予想シーケンス番号と比較するシーケンス番号比較器、
    (a)メッセージ・フェーズ番号と予想フェーズ番号、(b)メッセージ・シーケンス番号と予想シーケンス番号の少なくとも一方がマッチしないとき、ロスト・メッセージを報知するロスト・メッセージ報知機、
    を含む、システム。
JP2015104809A 2011-09-02 2015-05-22 メッセージ・ストリーム・インテグリティ Expired - Fee Related JP6091545B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/225,047 2011-09-02
US13/225,047 US8745157B2 (en) 2011-09-02 2011-09-02 Order feed message stream integrity

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2014528605A Division JP5840782B2 (ja) 2011-09-02 2012-08-30 メッセージ・ストリーム・インテグリティ

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2016244575A Division JP6313842B2 (ja) 2011-09-02 2016-12-16 メッセージ・ストリーム・インテグリティ

Publications (2)

Publication Number Publication Date
JP2015172963A JP2015172963A (ja) 2015-10-01
JP6091545B2 true JP6091545B2 (ja) 2017-03-08

Family

ID=46832626

Family Applications (4)

Application Number Title Priority Date Filing Date
JP2014528605A Expired - Fee Related JP5840782B2 (ja) 2011-09-02 2012-08-30 メッセージ・ストリーム・インテグリティ
JP2015104809A Expired - Fee Related JP6091545B2 (ja) 2011-09-02 2015-05-22 メッセージ・ストリーム・インテグリティ
JP2016244575A Active JP6313842B2 (ja) 2011-09-02 2016-12-16 メッセージ・ストリーム・インテグリティ
JP2018006579A Pending JP2018077905A (ja) 2011-09-02 2018-01-18 メッセージ・ストリーム・インテグリティ

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2014528605A Expired - Fee Related JP5840782B2 (ja) 2011-09-02 2012-08-30 メッセージ・ストリーム・インテグリティ

Family Applications After (2)

Application Number Title Priority Date Filing Date
JP2016244575A Active JP6313842B2 (ja) 2011-09-02 2016-12-16 メッセージ・ストリーム・インテグリティ
JP2018006579A Pending JP2018077905A (ja) 2011-09-02 2018-01-18 メッセージ・ストリーム・インテグリティ

Country Status (14)

Country Link
US (5) US8745157B2 (ja)
EP (3) EP2652895B1 (ja)
JP (4) JP5840782B2 (ja)
KR (4) KR101875915B1 (ja)
CN (3) CN103907306B (ja)
AU (1) AU2012301829B2 (ja)
BR (4) BR112014004455A2 (ja)
CA (2) CA3027550A1 (ja)
ES (1) ES2488672T3 (ja)
HK (4) HK1188520A1 (ja)
IL (1) IL230900A0 (ja)
MX (3) MX2014002222A (ja)
SG (2) SG2014011753A (ja)
WO (1) WO2013033416A1 (ja)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8232962B2 (en) 2004-06-21 2012-07-31 Trading Technologies International, Inc. System and method for display management based on user attention inputs
US7725764B2 (en) * 2006-08-04 2010-05-25 Tsx Inc. Failover system and method
US8745157B2 (en) 2011-09-02 2014-06-03 Trading Technologies International, Inc. Order feed message stream integrity
US9021109B1 (en) * 2012-01-23 2015-04-28 Amazon Technologies, Inc. Controlling requests through message headers
US10755351B2 (en) * 2012-03-29 2020-08-25 Trading Technologies International, Inc. Controlling operation of a trading algorithm based on operating condition rules
US9756089B2 (en) * 2012-08-28 2017-09-05 Facebook, Inc. Maintain persistent connections between servers and mobile clients
US10467691B2 (en) * 2012-12-31 2019-11-05 Trading Technologies International, Inc. User definable prioritization of market information
AU2013392579A1 (en) * 2013-06-13 2015-11-26 Tsx Inc. Failover system and method
US10664548B2 (en) 2013-07-12 2020-05-26 Trading Technologies International, Inc. Tailored messaging
CN104703146B (zh) * 2013-12-09 2019-03-08 腾讯科技(深圳)有限公司 信息推送方法、客户端及系统
US10142202B2 (en) * 2014-01-30 2018-11-27 Qualcomm Incorporated Determination of end-to-end transport quality
JP6514165B2 (ja) * 2016-09-16 2019-05-15 株式会社東芝 通信装置および通信方法
CA2984275A1 (en) * 2016-11-01 2018-05-01 Tsx Inc. Electronic trading system and method for mutual funds and exchange traded funds
US10776428B2 (en) * 2017-02-16 2020-09-15 Nasdaq Technology Ab Systems and methods of retrospectively determining how submitted data transaction requests operate against a dynamic data structure
FR3074396A1 (fr) * 2017-11-30 2019-05-31 Orange Procedes de detection, de gestion et de relais d'un probleme de communication multimedia, entites d'execution, de controle et de gestion de regles et programme d'ordinateur correspondants.
CN111107509B (zh) * 2018-10-26 2023-04-14 深圳市理邦精密仪器股份有限公司 一种监护数据传输方法、系统及探头
JP7288662B2 (ja) * 2019-04-15 2023-06-08 明京電機株式会社 障害監視復旧システム、その方法、およびそのプログラム
CN110806993B (zh) * 2019-11-05 2021-06-01 积成电子股份有限公司 一种定制的modbus通信方法及利用该方法的低耦合远动装置
CN112511368A (zh) * 2020-10-16 2021-03-16 深圳市科漫达智能管理科技有限公司 一种服务心跳监控方法及相关装置

Family Cites Families (102)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3268875B2 (ja) * 1993-02-26 2002-03-25 株式会社野村総合研究所 同報ファイル転送方法およびシステム
JPH0832531A (ja) * 1994-07-20 1996-02-02 Hitachi Ltd 同報通信方式
JP3833746B2 (ja) * 1996-07-31 2006-10-18 株式会社東芝 チェックポイント通信処理システム、及びチェックポイント通信処理方法
US6072857A (en) * 1996-12-19 2000-06-06 Bellsouth Intellectual Property Management Corporation Methods and system for monitoring the operational status of a network component in an advanced intelligent network
US6574234B1 (en) 1997-09-05 2003-06-03 Amx Corporation Method and apparatus for controlling network devices
US6144669A (en) 1997-12-12 2000-11-07 Newbridge Networks Corporation Prioritized PVC management queues for improved frame processing capabilities
US6178439B1 (en) * 1997-12-23 2001-01-23 British Telecommunications Public Limited Company HTTP session control
US6389016B1 (en) * 1998-10-14 2002-05-14 Nortel Networks Limited Data communication system and method for transporting data
US8862507B2 (en) * 1999-06-14 2014-10-14 Integral Development Corporation System and method for conducting web-based financial transactions in capital markets
AU6610300A (en) * 1999-07-28 2001-02-19 Terrance A. Tomkow System and method for verifying delivery and integrity of electronic messages
US6631431B1 (en) * 1999-09-15 2003-10-07 Koninklijke Philips Electronics N.V. Semaphore coding method to ensure data integrity in a can microcontroller and a can microcontroller that implements this method
US7107240B1 (en) * 1999-10-06 2006-09-12 Goldman Sachs & Co. Order centric tracking system and protocol for communications with handheld trading units
JP3509847B2 (ja) * 2000-01-20 2004-03-22 日本電気株式会社 Nmsシステムにおける通信の信頼性向上方法及びnmsシステム
US7133407B2 (en) * 2000-01-25 2006-11-07 Fujitsu Limited Data communications system
US6983317B1 (en) * 2000-02-28 2006-01-03 Microsoft Corporation Enterprise management system
US6904593B1 (en) 2000-03-24 2005-06-07 Hewlett-Packard Development Company, L.P. Method of administering software components using asynchronous messaging in a multi-platform, multi-programming language environment
US7539638B1 (en) * 2000-04-10 2009-05-26 Stikine Technology, Llc Representation of order in multiple markets
US8249975B1 (en) * 2000-04-10 2012-08-21 Stikine Technology, Llc Automated first look at market events
US6907044B1 (en) * 2000-08-04 2005-06-14 Intellon Corporation Method and protocol to support contention-free intervals and QoS in a CSMA network
US6744765B1 (en) 2000-08-24 2004-06-01 Sun Microsystems, Inc. Mechanism for completing messages in memory
US8692695B2 (en) * 2000-10-03 2014-04-08 Realtime Data, Llc Methods for encoding and decoding data
JP2002135350A (ja) * 2000-10-30 2002-05-10 Sony Corp データ配信方法、データ受信方法、端末状態通知サービス提供方法および通信端末
US6615221B2 (en) * 2001-03-09 2003-09-02 Hewlett-Packard Development Company, Lp. Scalable transport layer protocol for multiprocessor interconnection networks that tolerates interconnection component failure
US6782496B2 (en) 2001-04-13 2004-08-24 Hewlett-Packard Development Company, L.P. Adaptive heartbeats
GB2395041A (en) * 2001-08-14 2004-05-12 Bloomberg Lp Distribution and mapping of financial records from data stream
JP2003067264A (ja) * 2001-08-23 2003-03-07 Hitachi Ltd ネットワークシステムの監視間隔制御方法
US8090640B2 (en) * 2002-06-05 2012-01-03 The Nasdaq Omx Group, Inc. Order delivery in a securities market
US7747506B2 (en) * 2002-06-05 2010-06-29 The Nasdaq Omx Group, Inc. Recipient status indicator system and method
US8176186B2 (en) * 2002-10-30 2012-05-08 Riverbed Technology, Inc. Transaction accelerator for client-server communications systems
US7720043B2 (en) * 2002-11-20 2010-05-18 Qualcomm Incorporated Use of idle frames for early transmission of negative acknowledgement of frame receipt
JP4167511B2 (ja) * 2003-02-25 2008-10-15 株式会社東芝 伝送路二重化判定処理方法
US20050021836A1 (en) * 2003-05-01 2005-01-27 Reed Carl J. System and method for message processing and routing
US20040236829A1 (en) * 2003-05-13 2004-11-25 Yikang Xu Reliable delivery of multi-cast conferencing data
JP2004364168A (ja) * 2003-06-06 2004-12-24 Daikin Ind Ltd 通信制御装置、通信制御システム及び通信制御方法
CN1820262A (zh) * 2003-06-09 2006-08-16 范拉诺公司 事件监控及管理
JP2005109849A (ja) * 2003-09-30 2005-04-21 Fujitsu Ltd 送信サーバ用データ交換処理プログラムおよび受信サーバ用データ交換処理プログラム
US9350565B1 (en) * 2003-10-14 2016-05-24 Amazon Technologies, Inc. Method and system for reliable distribution of messages
US7778915B2 (en) * 2003-10-14 2010-08-17 Ften, Inc. Financial data processing system
US7355975B2 (en) 2004-04-30 2008-04-08 International Business Machines Corporation Method and apparatus for group communication with end-to-end reliability
US7228331B2 (en) * 2004-05-04 2007-06-05 Nokia, Inc. User oriented penalty count random rejection of electronic messages
US7477749B2 (en) * 2004-05-12 2009-01-13 Nokia Corporation Integrity protection of streamed content
US8949395B2 (en) * 2004-06-01 2015-02-03 Inmage Systems, Inc. Systems and methods of event driven recovery management
GB0414057D0 (en) 2004-06-23 2004-07-28 Koninkl Philips Electronics Nv Method of,and system for,communicating data, and a station for transmitting data
US20060056403A1 (en) * 2004-09-13 2006-03-16 Pleasant Daniel L System and method for robust communication via a non-reliable protocol
US7483943B2 (en) * 2004-09-21 2009-01-27 Microsoft Corporation Reliable messaging using clocks with synchronized rates
US8095601B2 (en) * 2004-10-22 2012-01-10 Microsoft Corporation Inter-proximity communication within a rendezvous federation
US8458467B2 (en) * 2005-06-21 2013-06-04 Cisco Technology, Inc. Method and apparatus for adaptive application message payload content transformation in a network infrastructure element
US8082304B2 (en) * 2004-12-10 2011-12-20 Cisco Technology, Inc. Guaranteed delivery of application layer messages by a network element
US7292665B2 (en) * 2004-12-16 2007-11-06 Genesis Microchip Inc. Method and apparatus for reception of data over digital transmission link
US8700738B2 (en) * 2005-02-01 2014-04-15 Newsilike Media Group, Inc. Dynamic feed generation
US8239449B2 (en) 2005-07-20 2012-08-07 Wms Gaming Inc. Transmission protocol for a gaming system
US9471925B2 (en) * 2005-09-14 2016-10-18 Millennial Media Llc Increasing mobile interactivity
US8200563B2 (en) * 2005-09-23 2012-06-12 Chicago Mercantile Exchange Inc. Publish and subscribe system including buffer
US20070174429A1 (en) * 2006-01-24 2007-07-26 Citrix Systems, Inc. Methods and servers for establishing a connection between a client system and a virtual machine hosting a requested computing environment
CN101060424A (zh) * 2006-04-21 2007-10-24 英业达股份有限公司 一种实现负载平衡与高可用性的系统及其方法
US7752123B2 (en) * 2006-04-28 2010-07-06 Townsend Analytics Ltd. Order management system and method for electronic securities trading
US7725764B2 (en) * 2006-08-04 2010-05-25 Tsx Inc. Failover system and method
US8041985B2 (en) * 2006-08-11 2011-10-18 Chicago Mercantile Exchange, Inc. Match server for a financial exchange having fault tolerant operation
US7434096B2 (en) * 2006-08-11 2008-10-07 Chicago Mercantile Exchange Match server for a financial exchange having fault tolerant operation
US8015294B2 (en) * 2006-08-22 2011-09-06 Embarq Holdings Company, LP Pin-hole firewall for communicating data packets on a packet network
US9479341B2 (en) * 2006-08-22 2016-10-25 Centurylink Intellectual Property Llc System and method for initiating diagnostics on a packet network node
US9026575B2 (en) * 2006-09-28 2015-05-05 Alcatel Lucent Technique for automatically configuring a communication network element
US20160277261A9 (en) * 2006-12-29 2016-09-22 Prodea Systems, Inc. Multi-services application gateway and system employing the same
US9648147B2 (en) * 2006-12-29 2017-05-09 Futurewei Technologies, Inc. System and method for TCP high availability
WO2009100444A1 (en) * 2008-02-08 2009-08-13 Verbal World, Inc. Methods and apparatus for exhange of electronic communications
KR20090000228A (ko) * 2007-02-05 2009-01-07 삼성전자주식회사 무결성 검증이 가능한 컨텐츠 제공 방법 및 컨텐츠 이용방법과 그 장치
JP4808645B2 (ja) * 2007-02-15 2011-11-02 富士通株式会社 装置監視ネットワークシステム及びsnmpのトラップ管理方法
US7809841B1 (en) 2007-03-29 2010-10-05 Trading Technologies International, Inc. System and method for communicating with an electronic exchange in an electronic trading environment
US7916741B2 (en) * 2007-04-02 2011-03-29 William Marsh Rice University System and method for preventing count-to-infinity problems in ethernet networks
US8275905B2 (en) * 2007-04-17 2012-09-25 Oracle International Corporation System and method for store-and-forward for highly available message production
US8307114B2 (en) * 2007-05-22 2012-11-06 International Business Machines Corporation High availability message transmission
US7782851B2 (en) * 2007-06-26 2010-08-24 At&T Intellectual Property I, L.P. System and method of detecting lost video data packets
US20090018944A1 (en) * 2007-07-13 2009-01-15 Omx Technology Ab Method and system for trading
US8782274B2 (en) * 2007-10-19 2014-07-15 Voxer Ip Llc Method and system for progressively transmitting a voice message from sender to recipients across a distributed services communication network
US7907533B2 (en) 2007-11-28 2011-03-15 Tekelec Methods, systems, and computer program products for performing IP link proving using heartbeat messages
CN101188527B (zh) * 2007-12-24 2012-03-14 杭州华三通信技术有限公司 一种心跳检测方法和装置
FR2926939A1 (fr) * 2008-01-30 2009-07-31 Canon Kk Procede de transmission de donnees avec anticipation des acquittements, dispositif d'entree, produit programme d'ordinateur et moyen de stockage correspondants
JP4964164B2 (ja) * 2008-02-15 2012-06-27 三菱電機株式会社 通信装置の冗長構成制御方法
US7983622B1 (en) * 2008-03-12 2011-07-19 Sprint Spectrum L.P. Using phase difference to determine valid neighbors
US8958460B2 (en) * 2008-03-18 2015-02-17 On-Ramp Wireless, Inc. Forward error correction media access control system
JP4557028B2 (ja) * 2008-03-19 2010-10-06 ソニー株式会社 情報処理装置、情報処理方法、クライアント機器、情報処理システム
US8022822B2 (en) 2008-06-27 2011-09-20 Microsoft Corporation Data collection protocol for wireless sensor networks
US8165080B2 (en) 2008-08-22 2012-04-24 Qualcomm Incorporated Addressing schemes for wireless communication
US9119165B2 (en) * 2009-09-10 2015-08-25 Nextnav, Llc Coding in a wide area positioning system (WAPS)
EP2254046B1 (en) * 2009-05-18 2014-07-30 Amadeus S.A.S. A method and system for managing the order of messages
US8880524B2 (en) 2009-07-17 2014-11-04 Apple Inc. Scalable real time event stream processing
US20110040668A1 (en) * 2009-08-17 2011-02-17 Darren Lee Automated spread trading system
US8417618B2 (en) * 2009-09-03 2013-04-09 Chicago Mercantile Exchange Inc. Utilizing a trigger order with multiple counterparties in implied market trading
US9979589B2 (en) * 2009-12-10 2018-05-22 Royal Bank Of Canada Coordinated processing of data by networked computing resources
US20110178915A1 (en) * 2010-01-15 2011-07-21 Lime Brokerage Holding Llc Trading Order Validation System and Method and High-Performance Trading Data Interface
WO2011100529A1 (en) * 2010-02-12 2011-08-18 Mastercard International Incorporated Apparatus and method for bill presentment and payment
US8595234B2 (en) * 2010-05-17 2013-11-26 Wal-Mart Stores, Inc. Processing data feeds
US8732324B2 (en) * 2010-05-25 2014-05-20 Cisco Technology, Inc. Keep-alive hiatus declaration
US9373102B2 (en) * 2010-07-30 2016-06-21 Mcgraw Hill Financial, Inc. System and method using a simplified XML format for real-time content publication
US9160806B1 (en) * 2010-08-04 2015-10-13 Open Invention Network, Llc Method and apparatus of organizing and delivering data to intended recipients
CN102014416B (zh) * 2010-12-03 2014-07-16 中兴通讯股份有限公司 一种对连接进行双向检测的方法及系统
WO2012118871A2 (en) * 2011-02-28 2012-09-07 Nyse Group, Inc. Apparatuses, methods and systems for a locked-in trade facilitation engine
US8676937B2 (en) * 2011-05-12 2014-03-18 Jeffrey Alan Rapaport Social-topical adaptive networking (STAN) system allowing for group based contextual transaction offers and acceptances and hot topic watchdogging
US8799135B2 (en) * 2011-06-13 2014-08-05 Trading Technologies International, Inc Generating market information based on causally linked events
US8812708B2 (en) * 2011-07-22 2014-08-19 Cisco Technology, Inc. Transient unpruning for faster layer-two convergence
US8745157B2 (en) 2011-09-02 2014-06-03 Trading Technologies International, Inc. Order feed message stream integrity
US9461876B2 (en) * 2012-08-29 2016-10-04 Loci System and method for fuzzy concept mapping, voting ontology crowd sourcing, and technology prediction

Also Published As

Publication number Publication date
AU2012301829A1 (en) 2013-05-02
CN108055169A (zh) 2018-05-18
WO2013033416A1 (en) 2013-03-07
JP2015172963A (ja) 2015-10-01
US20190066210A1 (en) 2019-02-28
JP5840782B2 (ja) 2016-01-06
SG10201607252VA (en) 2016-10-28
CA3027550A1 (en) 2013-03-07
CN103907306A (zh) 2014-07-02
EP2793417A1 (en) 2014-10-22
US10152751B2 (en) 2018-12-11
KR101995058B1 (ko) 2019-07-01
CA2847350A1 (en) 2013-03-07
HK1255332A1 (zh) 2019-08-16
US20150371331A1 (en) 2015-12-24
CA2847350C (en) 2019-02-12
JP2018077905A (ja) 2018-05-17
EP3496315A1 (en) 2019-06-12
EP2793417B1 (en) 2018-10-10
EP2652895B1 (en) 2014-05-14
KR20160093103A (ko) 2016-08-05
US20140344363A1 (en) 2014-11-20
EP2652895A1 (en) 2013-10-23
AU2012301829B2 (en) 2014-09-11
US10311518B2 (en) 2019-06-04
BR122015015223A2 (pt) 2019-08-27
US8745157B2 (en) 2014-06-03
BR112014004455A2 (pt) 2017-03-28
KR20180078357A (ko) 2018-07-09
US20190236707A1 (en) 2019-08-01
JP6313842B2 (ja) 2018-04-18
BR122015015211A2 (pt) 2019-08-27
MX346140B (es) 2017-03-08
KR101644996B1 (ko) 2016-08-02
IL230900A0 (en) 2014-03-31
CN108055113A (zh) 2018-05-18
SG2014011753A (en) 2014-09-26
KR20140060333A (ko) 2014-05-19
KR20190076077A (ko) 2019-07-01
US20130060887A1 (en) 2013-03-07
ES2488672T3 (es) 2014-08-28
HK1188520A1 (en) 2014-05-02
MX2014002222A (es) 2014-05-28
JP2017097889A (ja) 2017-06-01
US9154393B2 (en) 2015-10-06
HK1255333A1 (zh) 2019-08-16
JP2014529828A (ja) 2014-11-13
CN103907306B (zh) 2018-06-05
MX337872B (es) 2016-03-23
BR122015015215A2 (pt) 2019-08-27
HK1202725A1 (en) 2015-10-02
KR101875915B1 (ko) 2018-07-06

Similar Documents

Publication Publication Date Title
JP6313842B2 (ja) メッセージ・ストリーム・インテグリティ
EP3605951A1 (en) Message processing protocol which mitigates manipulative messaging behavior
AU2016269451B2 (en) Message stream integrity
AU2014265010B2 (en) Message stream integrity

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160414

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160426

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160722

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20160816

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161216

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20161222

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170117

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170207

R150 Certificate of patent or registration of utility model

Ref document number: 6091545

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees