通信システム、通信方法、および通信プログラム
【課題】 通信のリアルタイム性を高める。
【解決手段】 通信時に、１つの通信装置が送信用と受信用に１つずつ、合計２つのコネクションを確立し、当該通信装置内でトランスポート層の通信プロトコルを処理するトランスポート層エンティティとして、当該通信装置から情報を送信するときに機能する送信用ポートと受信するときに機能する受信用ポートを用いるコネクション型の通信システムにおいて、前記２つのコネクションうちの１つしか確立されない場合、所定のタイムアウト時間が経過する前であっても、その１つのコネクションに送信用ポートと受信用ポートを対応付けて、当該コネクションを送信用および受信用に割り当てるコネクション制御部を備える。
【解決手段】 通信時に、１つの通信装置が送信用と受信用に１つずつ、合計２つのコネクションを確立し、当該通信装置内でトランスポート層の通信プロトコルを処理するトランスポート層エンティティとして、当該通信装置から情報を送信するときに機能する送信用ポートと受信するときに機能する受信用ポートを用いるコネクション型の通信システムにおいて、前記２つのコネクションうちの１つしか確立されない場合、所定のタイムアウト時間が経過する前であっても、その１つのコネクションに送信用ポートと受信用ポートを対応付けて、当該コネクションを送信用および受信用に割り当てるコネクション制御部を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信システム、通信方法、および通信プログラムに関し、例えば、ＩＴＵ−Ｔ勧告Ｔ．３８のファクシミリ通信を実現するためのゲートウエイ装置などに適用して好適なものである。
【背景技術】
【０００２】
コネクション型の通信に関する技術として下記の非特許文献１に記載されたものがある。
【０００３】
この非特許文献１は、ＩＰネットワーク上でＧ３ファクシミリ通信を行うための規格を定めたものである。当該非特許文献１には、ゲートウエイ装置間に２本のＴＣＰセッション（ＴＣＰコネクション）を確立した上でファクシミリ通信を行うケースについて記載されている。
【０００４】
２本のコネクションを確立した場合、１つのコネクションを送信用とし、もう１つのコネクションを受信用とすることができる。
【非特許文献１】ＩＴＵ−Ｔ勧告Ｔ．３８
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところで、上述した非特許文献１に比較的忠実な実装を行ったゲートウエイ装置では、１つのコネクションのみが確立され、もう１つのコネクションがタイムアウトによって確立に失敗したことが確定した場合、確立された１つのコネクションを用いて送信と受信を行うことができる。しかしながら、例えば、確立されたものが受信用のコネクションで、確立に失敗したものが送信用のコネクションである場合、確立に失敗したことが確定する前に、収容しているＧ３ファクシミリ装置から送信すべき情報が届くと、ゲートウエイ装置はこの情報を正常に送信することができないため、Ｇ３ファクシミリ装置を使用するユーザは、確立に失敗したことが確定するまでの時間（前記タイムアウトが判定されるまでの時間）、ファクシミリ通信の開始を待たされることになり、通信のリアルタイム性が低かった。
【課題を解決するための手段】
【０００６】
かかる課題を解決するために、第１の本発明では、通信時に、１つの通信装置が送信用と受信用に１つずつ、合計２つのコネクションを確立し、当該通信装置内でトランスポート層の通信プロトコルを処理するトランスポート層エンティティとして、当該通信装置から情報を送信するときに機能する送信用ポートと受信するときに機能する受信用ポートを用いるコネクション型の通信システムにおいて、前記２つのコネクションうちの１つしか確立されない場合、所定のタイムアウト時間が経過する前であっても、その１つのコネクションに送信用ポートと受信用ポートを対応付けて、当該コネクションを送信用および受信用に割り当てるコネクション制御部を備えたことを特徴とする。
【０００７】
また、第２の本発明では、通信時に、１つの通信装置が送信用と受信用に１つずつ、合計２つのコネクションを確立し、当該通信装置内でトランスポート層の通信プロトコルを処理するトランスポート層エンティティとして、当該通信装置から情報を送信するときに機能する送信用ポートと受信するときに機能する受信用ポートを用いるコネクション型の通信方法において、前記２つのコネクションうちの１つしか確立されない場合、所定のタイムアウト時間が経過する前であっても、その１つのコネクションに送信用ポートと受信用ポートを対応付けて、当該コネクションを送信用および受信用に割り当てることを特徴とする。
【０００８】
さらに、第３の本発明では、通信時に、１つの通信装置が送信用と受信用に１つずつ、合計２つのコネクションを確立し、当該通信装置内でトランスポート層の通信プロトコルを処理するトランスポート層エンティティとして、当該通信装置から情報を送信するときに機能する送信用ポートと受信するときに機能する受信用ポートを用いるコネクション型の通信プログラムにおいて、コンピュータに、前記２つのコネクションうちの１つしか確立されない場合、所定のタイムアウト時間が経過する前であっても、その１つのコネクションに送信用ポートと受信用ポートを対応付けて、当該コネクションを送信用および受信用に割り当てるコネクション制御機能を実現させることを特徴とする。
【発明の効果】
【０００９】
本発明によれば、通信のリアルタイム性を高めることができる。
【発明を実施するための最良の形態】
【００１０】
（Ａ）実施形態
以下、本発明にかかる通信システム、通信方法、および通信プログラムをＩＰネットワークを用いるファクシミリ通信システムに適用した場合を例に、実施形態について説明する。
【００１１】
（Ａ−１）実施形態の構成
本実施形態にかかるファクシミリ通信システム１０の全体構成例を図３に示す。なお、当該ファクシミリ通信システム１０中に、図示しないサーバ類（例えば、ＤＮＳサーバやＤＨＣＰサーバなど）やネットワーク機器（ハブやルータなど）が存在していてもよいことは当然である。
【００１２】
図３において、当該ファクシミリ通信システム１０は、ネットワーク１１と、ゲートウエイ装置１２，１３と、ファクシミリ装置１４，１５とを備えている。
【００１３】
このうちネットワーク１１は、例えば、ある企業の内部で使用されるＬＡＮ（ローカルエリアネットワーク）などであってもよく、インターネットなどであってもよいが、当該ネットワーク１１はＯＳＩ参照モデルのネットワーク層でＩＰプロトコルが通用するものである。
【００１４】
ファクシミリ装置１４は通常のＧ３ファクシミリ装置である。したがって、当該ファクシミリ装置１４自体はＩＰプロトコルを処理する機能などを持たないため、直接、ネットワーク１１に接続することはできず、ゲートウエイ装置１２経由で接続されることになる。
【００１５】
この点は、ファクシミリ装置１５も同様で、ゲートウエイ装置１３経由でネットワーク１１に接続される。ゲートウエイ装置１２，１３はＶｏＩＰゲートウエイを構成する。
【００１６】
ファクシミリ装置１４はユーザＵ１によって使用され、ファクシミリ装置１５はユーザＵ２によって使用されるものとする。
【００１７】
ゲートウエイ装置１２は前記非特許文献１のＩＴＵ−Ｔ勧告Ｔ．３８に準拠した構成を備えているが、従来とは異なる特徴も有する。以下では、主として、当該ゲートウエイ装置１２側からみて、相手のゲートウエイ装置１３とのあいだの送信、受信を説明する。相手のゲートウエイ装置１３が取り得る構成については、大きく３つのタイプに分けることができる。
【００１８】
その第１は、前記ゲートウエイ装置１２と同じ構成を持つタイプ、第２は、従来と同様の２コネクション型のゲートウエイ装置であるタイプ、第３は、１コネクション型のゲートウエイ装置であるタイプである。ここで、コネクションとはＯＳＩ参照モデルのトランスポート層の通信プロトコルであるＴＣＰのコネクション（ＴＣＰセッション）を指す。コネクションは論理的な通信路であって、そのほぼ両端に、ゲートウエイ装置１２のＴＣＰポート（ソケット）とゲートウエイ装置１３のＴＣＰポート（ソケット）が位置する形になる。
【００１９】
第２のタイプに対応する２コネクション型のゲートウエイ装置１３は、［発明が解決しようとする課題］の項で説明したゲートウエイ装置にあたる。すなわち、当該ゲートウエイ装置１３で、１つのコネクションのみが確立され、もう１つのコネクションがタイムアウトによって確立に失敗したことが確定した場合、確立された１つのコネクションを用いて送信と受信を行うことができるものの、例えば、確立されたものが受信用のコネクションで、確立に失敗したものが送信用のコネクションである場合、確立に失敗したことが確定する前に、収容しているＧ３ファクシミリ装置（ここでは、１５）から送信すべき情報が届くと、ゲートウエイ装置１３はこの情報を正常に送信することができないため、Ｇ３ファクシミリ装置を使用するユーザ（ここでは、Ｕ２）は、確立に失敗したことが確定するまでの時間、ファクシミリ通信の開始を待たされることになる。
【００２０】
第１のタイプに対応する本実施形態に特徴的なゲートウエイ装置も２コネクション型のゲートウエイ装置の一種であるとみることができるが、タイムアウトの前であっても、確立された１つのコネクションを送信と受信に利用できる点が異なる。その詳細については後述する。
【００２１】
第３のタイプに対応するゲートウエイ装置は、元々、１つのコネクションを確立する機能しか持たないもので、確立された１つのコネクションを利用して送信と受信を行う。
【００２２】
前記ゲートウエイ装置１２の内部構成は例えば図２に示す通りである。前記第１のタイプの場合、相手のゲートウエイ装置１３の内部構成もこれと同じになる。
【００２３】
（Ａ−１−１）ゲートウエイ装置の内部構成例
図２において、当該ゲートウエイ装置１２は、ネットワークインタフェース部２０と、制御部２１と、アナログインタフェース部２２と、ソケット管理部２３と、タイムアウト判定部２４と、ゲートウエイ部２５と、記憶部２６とを備えている。
【００２４】
このうちネットワークインタフェース部２０は、前記ネットワーク１１に接続されるインタフェースで、ＯＳＩ参照モデルの物理層やデータリンク層などを処理する機能を有する。
【００２５】
アナログインタフェース部２２は、前記ファクシミリ装置１４を接続するためのインタフェースである。
【００２６】
制御部２１はハードウエア的には当該ゲートウエイ装置１２のＣＰＵ（中央処理装置）などに相当し得る部分であり、ソフトウエア的には当該ゲートウエイ装置１２のＯＳ（オペレーティングシステム）などに相当し得る部分である。
【００２７】
記憶部２６はハードウエア的には揮発性または不揮発性の各種記憶手段（例えば、ＲＡＭやハードディスクなど）に相当する部分であり、ソフトウエア的には各種のファイルに相当する。前記ＯＳなどを収容したプログラムファイルもこのようなファイルの１つであるから、物理的には、前記ＯＳも当該記憶部２６に位置することになる。
【００２８】
ゲートウエイ部２５は、ゲートウエイ（ＶｏＩＰゲートウエイ）の機能を提供する部分である。すなわち、ファクシミリ装置１４から１５へ送信される情報は、当該ゲートウエイ部２５で必要な各種の処理（例えば、符号化など）を経たあと、ＩＰパケットに収容されてネットワーク１１に送出されることになる。反対に、ファクシミリ装置１５から１４に届けられる情報は当該ゲートウエイ部２５でＩＰパケットから抽出されたあと、必要な各種の処理（例えば、復号化など）を経たあとで、前記アナログインタフェース部２２を介してファクシミリ装置１４に届けられることになる。
【００２９】
なお、ネットワーク１１では宛先を識別するための識別子として有効な識別子はＩＰアドレスだけであるが、その一方で、ユーザＵ１が宛先を指定するために入力するのは、通常、宛先となるファクシミリ装置１５のファクシミリ番号ＦＮ１５である。
【００３０】
したがって、ファクシミリ番号とＩＰアドレスの対応関係を調べ、入力されたファクシミリ番号ＦＮ１５から宛先のゲートウエイ装置１３のＩＰアドレスＩＡ１３を特定するためのアドレス解決の過程が必要となる。ゲートウエイ装置１２内でこのアドレス解決を分担するのも、当該ゲートウエイ部２５である。ＩＴＵ−Ｔ勧告Ｔ．３８では、呼制御プロトコルとしてＨ．３２３を用いるため、ファクシミリ番号とＩＰアドレスの対応関係を蓄積しているのは図示しないＨ．３２３ゲートキーパであり、ゲートウエイ部２５は当該ゲートキーパと通信することによってアドレス解決を行い、その結果として宛先ＩＰアドレスにＩＡ１３を持つＩＰパケットを送信することになる。
【００３１】
ソケット管理部２３は前記ソケットを管理する部分である。ソケットが前記ＴＣＰポートを備えている。ソケットは例えばＡＰＩ（アプリケーション・プログラミング・インタフェース）などの形式で実現され得るプログラムである。ＯＳＩ参照モデルやＴＣＰ／ＩＰプロトコル体系に忠実なモジュール分けを行う場合、トランスポート層に位置付けられる当該ソケット（ＴＣＰポート）は、それ自体、独立した１つのプログラムとして実現される。必要に応じて、当該ソケットはＯＳＩ参照モデルのセッション層に属する機能も有する。
【００３２】
同じトランスポート層のなかでさらにモジュール分けを行うか否かは自由であるが、ここでは、２つのソケットＳＴ１，ＳＴ２を別個のモジュールとして構成するものとする。
【００３３】
また、プログラムとしてのソケットＳＴ１，ＳＴ２に送信用の機能と受信用の機能をどのように持たせるかについてはいくつかのケースがあり、例えば、送信用の機能のみしか持たないソケットと、受信用の機能のみしか持たないソケットを用意することも考えられるが、ここでは、各ソケットＳＴ１，ＳＴ２が送信用の機能と受信用の機能を備えており、必要なときにいずれか一方または双方の機能を発揮するものとする。ただし、当初、送信用のポート（送信用ソケット）として機能するほうをＳＴ１とし、受信用のポート（受信用ソケット）として機能するほうをＳＴ２とする。
【００３４】
ソケット管理部２３は、当該ソケットＳＴ１，ＳＴ２の状態遷移（例えば、実行可能状態、実行状態、待ち状態のあいだの遷移）などを管理する。この状態遷移のタイミングの違いに本実施形態の特徴の本質がある。
【００３５】
タイムアウト判定部２４は、タイムアウトの判定を行う部分で、所定の手順を実行しタイムアウト時間ＭＴ１が経過してもそのコネクションの確立が検知できない場合にタイムアウトであると判定する。この手順には様々なものが考えられるが、相手のゲートウエイ装置１３に対して送信用コネクション（このコネクションは、ゲートウエイ装置１３からみると受信用コネクション）の確立を要求するためのコネクション確立制御信号であるConnect信号を所定時間置きに所定回数送信しても、応答信号（必ずしも応答のために予め定められた信号である必要はない）が返送されてこない場合には、タイムアウトと判定するものであってよい。これは、例えば、ネットワーク１１上でのパケット損失や相手のゲートウエイ装置１３の一時的な障害発生などが起きてもコネクションを確立するための手順である。具体的なタイムアウト時間ＭＴ１がどの程度の時間になるかは、この手順の内容によるが、その性質上、かなり長時間になることが避けられない。一例としては、最初にConnect 信号を送信してから３０秒程度の時間になる可能性がある。
【００３６】
受信用コネクション（このコネクションは相手のゲートウエイ装置１３からみると送信用コネクション）の確立は相手のゲートウエイ装置１３がConnect 信号を送信してきたときに行われる受動的な処理であるが、相手のゲートウエイ装置１３も２コネクション型であり、ゲートウエイ装置１２からConnect 信号を先に送信する場合を想定すると、ゲートウエイ装置１２がConnect 信号を送信し、それに応えて相手のゲートウエイ装置１３もConnect 信号を送信し、このConnect 信号がゲートウエイ装置１２まで届いたときに当該受信用コネクションの確立が行われる。したがって、受信用コネクションの確立に関するタイムアウトは、ゲートウエイ装置１２がConnect 信号の送信を開始した時刻から所定のタイムアウト時間ＭＴ２（ＭＴ２は必要に応じて、前記ＭＴ１と同じ値としてもよい）が経過しても相手のゲートウエイ装置１３からConnect 信号が届かない場合に、受信用コネクションの確立がタイムアウトによって失敗したものと確定的に判定するものであってよい。
【００３７】
以上の説明からも明らかなように、本実施形態で特徴的な構成要素２３，２４の機能は、通常、ＯＳの一部として実装され得るものであるが、図２では、制御部２１の外部に図示している。
【００３８】
図２に示したゲートウエイ装置１２のソフトウエア的な構成は別な観点から図４に示す形にまとめることができる。
【００３９】
図４において、当該ゲートウエイ装置１２は、ＯＳ４０と、ネットワーク管理部４１と、呼制御部４２と、電話回線管理部４３と、Ｔ．３８ＦＡＸ管理部４４と、タイマ４５とを備えている。
【００４０】
このうちＯＳ４０は上述したＯＳに対応する。ネットワーク管理部４１はネットワーク機能を管理する部分で、タイマ４５は前記タイムアウトを判定するとき等に必要な時間の計測を行う部分である。ＯＳ４０の構成にも依存するが、当該ネットワーク管理部４１やタイマ４５等はＯＳ４０の一部として実装される可能性が高い。その他の構成要素４２〜４４は、ＯＳ４０上で動作する通信アプリケーションである。
【００４１】
構成要素４２〜４４のうち電話回線管理部４３は、ゲートウエイ装置１２に収容されているファクシミリ装置１４（一般電話機などでも同じ）などＶｏＩＰ機能を持たない通信装置を接続する部分である。
【００４２】
また、Ｔ．３８ＦＡＸ管理部４４は、ＩＰプロトコル上でファクシミリ通信を実現するための伝送制御プロトコルであるＴ．３８を処理する部分である。
【００４３】
呼制御部４２は、ファクシミリ通信のための呼制御を実行する部分である。
【００４４】
電話回線管理部４３は前記アナログインタフェース部２２に対応し、呼制御部４２およびＴ．３８ＦＡＸ管理部４４は、前記ゲートウエイ部２５に対応する。また、ネットワーク管理部４１の一部として、前記ソケット管理部２３が含まれ得る。
【００４５】
以下、上記のような構成を有する本実施形態の動作について図１、図５，図６を用いて説明する。
【００４６】
図１は前記ソケットＳＴ１，ＳＴ２に関連する動作を示すフローチャートで、Ｓ１０〜Ｓ２４の各ステップから構成されている。
【００４７】
図５（Ａ）〜（Ｄ）は、典型的な４つのケースごとに、ソケットＳＴ１、ＳＴ２に関連する動作を示すシーケンス図で、Ｓ３０〜Ｓ３４、Ｓ４０〜Ｓ４２，Ｓ５０〜Ｓ５４，Ｓ６０〜Ｓ６１の各ステップを備えている。
【００４８】
図６（Ａ）〜（Ｄ）は、ソケットＳＴ１、ＳＴ２に関連する動作を示す概念図である。図６（Ａ）〜（Ｄ）上で１つのソケット（例えば、ＳＴ１）を示すブロック内に「送・受」とあるのは、そのソケットが送信機能と受信機能を備えていることを示している。また、「送」および／または「受」を括弧で括って「（送）」などと記述したものは、その時点で、その機能が使用されない状態にあることを示している。逆に、括弧で括っていないものはその機能が使用される状態にあることを示している。したがって、例えば、図６（Ｂ）のソケットＳＴ１のように「送・（受）」とあれば、そのとき当該ソケットＳＴ１の送信機能は使用される状態にあるが、受信機能は使用されない状態にあることを示している。
【００４９】
（Ａ−２）実施形態の動作
所定の開始イベントが発生したとき、それに応じて、前記ゲートウエイ装置１２内のソケット管理部２３がソケットＳＴ１と、ＳＴ２に対応するプロセス（タスク）を生成する。このとき、２つのソケットＳＴ１，ＳＴ２に対応する２つのプロセスを生成するのは、当該ゲートウエイ装置１２が２コネクション型のゲートウエイ装置だからである。
【００５０】
また、開始イベントとしては様々なものがあり得るが、例えば、ユーザＵ１がファクシミリ装置１４でファクシミリ送信を行うために相手のファクシミリ装置１５のファクシミリ番号ＦＮ１５の最初の１桁を入力し、それを前記アナログインタフェース部２２や制御部２１が検知したときに生成するものであってもよいし、逆に、相手のゲートウエイ装置１３から呼設定を要求する呼設定メッセージを含むＩＰパケットが届いたことを検知したとき等に生成するものであってもよい。前者は、ユーザＵ１がユーザＵ２へファクシミリ送信を行う場合であり、後者は、ユーザＵ２がユーザＵ１へファクシミリ送信を行う場合であるものとする。以下では、主として、ユーザＵ１からユーザＵ２へファクシミリ送信を行う場合を前提に説明を進める。
【００５１】
上述したように、２つのソケットＳＴ１，ＳＴ２はともに送信機能と受信機能を持つが、最初にそのプロセスが生成された直後には、ソケットＳＴ１は受信機能のみ用いられてConnect 信号の到着を待つものの、送信機能は用いられない。これと反対に、ソケットＳＴ２のほうは、最初にそのプロセスが生成された直後には、送信機能のみ用いられてConnect 信号を送信するが、受信機能は用いられない。
【００５２】
これは図６（Ｂ）に示すゲートウエイ装置１２内の状態にあたる。
【００５３】
したがって当初は、図１のステップＳ１０に示すように、ソケットＳＴ１が相手のゲートウエイ装置１３から届くConnect 信号を待ち受け、ソケットＳＴ２は相手のゲートウエイ装置１３へConnect 信号を送信する。
【００５４】
ステップＳ１０のあと、４つのイベントのうちいずれが検知されるかに応じて４つの分岐先に分岐する。
【００５５】
第１のイベントは相手側からConnect 信号が到来してListen側の接続（受信用コネクション）が確立することであり、このイベントは前記ソケットＳＴ１がそのConnect信号を受信することによってステップＳ１１で検知される。第２のイベントはソケットＳＴ２が送信したConnect信号が相手のゲートウエイ装置１３内の該当するソケット（例えば、ＳＴ１１やＳＴ２１）に受信されたことによってConnect側の接続（送信用コネクション）が確立することである。図５（Ａ）〜（Ｄ）に示したシーケンスにしたがう限り、Connect 信号の送信元であるゲートウエイ装置１２内のソケットＳＴ２自身が直接、このイベントの発生を検知する方法はない。ただし、例えばConnect信号にソケットＳＴ２が持つポート（または、ソケットＳＴ１が持つポート）のポート番号を記述しておき、相手のゲートウエイ装置１３が当該ポート番号宛てに何らかの信号（前記応答信号に対応）を返送してきた場合には、その信号を受信したことをもって、ステップＳ１４で送信用コネクションの確立を検知することができる。
【００５６】
相手のゲートウエイ装置１３が上述した第１または第２のタイプに属する２コネクション型である場合には、ゲートウエイ装置１２からConnect 信号が届いたことによって確立された１本目のコネクション（ゲートウエイ装置１２からみると送信用コネクション）のほかに、２本目のコネクション（ゲートウエイ装置１２からみると受信用コネクション）を確立しようとしてConnect 信号を送信するが、そのConnect 信号をゲートウエイ装置１２が受信したことをもって、ゲートウエイ装置１２からみた前記送信用コネクションが確立されたことを検知するようにしてもよい。
【００５７】
第３のイベントはConnect 側の接続に失敗（送信用コネクションの確立に失敗）したことが確定したことである。このイベントの発生は、前記タイムアウト判定部２４が上述した方法によって判定を行うことで、前記ステップＳ１７で検知することができる。
【００５８】
第４のイベントはListen側の接続に失敗したことが確定したことである。このイベントの発生は、前記タイプアウト判定部が上述した方法によって判定を行うことで、ステップＳ２０で検知することができる。
【００５９】
前記ステップＳ１１につづくステップＳ１２では、すでに送信用コネクションが確立されているか否かを検査する。確立されていない場合、ステップＳ１２はＮｏ側に分岐して処理はステップＳ１３に進む。ステップＳ１３では、ソケットＳＴ１を送信用および受信用として用いるための設定を行う。
【００６０】
ステップＳ１２がＮｏ側に分岐したということは相手のゲートウエイ装置１３には、ゲートウエイ装置１２内のソケットＳＴ２の存在が認められていない可能性が高いが、前記ステップＳ１１が処理されたことにより、相手側のゲートウエイ装置１３にゲートウエイ装置１２内のソケットＳＴ１の存在が認められていることは明らかであるためである。このとき、前記タイムアウト時間ＭＴ１またはＭＴ２を経過することによるタイムアウトが発生している必要はないため、ゲートウエイ装置１２はタイムアウト時間ＭＴ１，ＭＴ２の経過より早いタイミングで、ユーザＵ１の望むファクシミリ送信を開始することが可能となる。
【００６１】
相手のゲートウエイ装置１３が上述した第２のタイプである場合には、ゲートウエイ装置１２がファクシミリ送信を行っても、相手のゲートウエイ装置１３内でタイムアウト時間（ＭＴ１，ＭＴ２に相当）が経過するまでは、図６（Ｃ）に示すようにソケットＳＴ２１内の受信機能のみが用いられて送信機能は用いられないため、正常な通信が行えない可能性があるが、信頼性の高いＴＣＰプロトコルを用いているから、ＴＣＰプロトコルの機能により、最終的には、ユーザＵ１が望む情報が相手のゲートウエイ装置１３およびファクシミリ装置１５まで送達される。ソケットＳＴ２１やＳＴ２２自体の機能は、前記ソケットＳＴ２などと同じである。なお、図６（Ｃ）上、実線で示したコネクションＣＮ１１はすでに確立されたコネクションであり、一点鎖線で示したコネクションＣＮ１２はまだ確立されていないコネクションである。この点は、図６（Ｄ）も同様である。
【００６２】
相手ゲートウエイ装置１３が第２のタイプであっても、ゲートウエイ装置１３内でタイムアウト時間ＭＴ１が経過しタイムアウト判定が行われれば、図６（Ｄ）に示すように、それまで用いられていなかったソケットＳＴ２１内の送信機能が用いられるようになるため、正常な通信を行うことが可能となる。
【００６３】
これに対し相手のゲートウエイ装置１３が上述した第１または第３のタイプである場合には、すでに相手のゲートウエイ装置１３内でソケットの受信機能および送信機能が有効になっていて、タイムアウト時間ＭＴ１，ＭＴ２の経過より早いタイミングで、ユーザＵ１の望む情報を、相手のゲートウエイ装置１３およびファクシミリ装置１５まで送達できる可能性が高い。
【００６４】
相手のゲートウエイ装置１３が前記第３のタイプに対応する１コネクション型である場合、図６（Ａ）に示すように、ゲートウエイ装置１２内の前記ソケットＳＴ２と、ゲートウエイ装置１３内のソケットＳＴ１１のあいだに確立された１つのコネクションＣＮ１を用いて情報が双方向にやり取りされ得る。
【００６５】
ソケットＳＴ１１は基本的にソケットＳＴ２と同じものであるが、ゲートウエイ装置１３が１コネクション型なので、ゲートウエイ装置１３内にソケットは１つしか存在しない。
【００６６】
相手のゲートウエイ装置１３のタイプやネットワーク１１の状態などにも依存するが、ゲートウエイ装置１２側からファクシミリ送信を行おうとする場合、相手ゲートウエイ装置１３は、ゲートウエイ装置１２が送信したConnect信号を受信したからこそConnect信号を返送したものである可能性が高いから、ゲートウエイ装置１２からみた送信用のコネクションが確立されず、受信用のコネクションのみが確立されるという現象（これは、ステップＳ１２がＮｏ側に分岐することに対応）は、確率的に起こりにくいものと考えられる。
【００６７】
ゲートウエイ装置１２と１３のあいだに１本のコネクションが確立し、そのコネクションを用いて情報の送受が行えることが確認された時点で、２本目のコネクションを確立するための試みを中止するようにしてもかまわないが、図１の例では、前記ステップＳ１０が実行され、前記ソケットＳＴ１がConnect 信号を送ることによって、２本目のコネクションの確立のための試みを繰り返している。
【００６８】
この試みは、図５（Ａ）のステップＳ３１〜Ｓ３３に対応する。この試みが繰り返されている間、図１上では、ステップＳ１０，Ｓ１１，Ｓ１２、Ｓ１３によって構成されるループが繰り返し処理される。なお、図５（Ｄ）の例では、Connect 信号の送信が繰り返されることなく、ゲートウエイ装置１２が送信したConnect 信号も、ゲートウエイ装置１３が送信したConnect 信号も１度で宛先に届いている（Ｓ６０、Ｓ６１）。これは、例えば、ステップＳ６０でConnect 信号を受信した相手のゲートウエイ装置１３が、その応答として送信したConnect 信号がゲートウエイ装置１２に受信されたものであってよい。
【００６９】
一方、図１に示す前記ステップＳ１２がＹｅｓ側に分岐する場合、前記ステップＳ１０の内部ですでに、ゲートウエイ装置１２からみた送信用コネクションの確立は完了しており、ステップＳ１１で受信用コネクションが確立されたことによって、２本のコネクションが確立されたことになるため、今回、ステップＳ２３でソケットＳＴ１を受信用に設定して接続処理を終了する（Ｓ２４）。
【００７０】
送信用コネクションはすでに確立済みなので、相手のゲートウエイ装置１３において、当該ソケットＳＴ２はゲートウエイ装置１２における送信用ソケットであるものとしてすでに認められている可能性が高いが、今回、ステップＳ１１が処理されたことにより、ソケットＳＴ１がゲートウエイ装置１２における受信用ソケットとして認められることになる。したがって、ステップＳ１２のＹｅｓ側の分岐につづくステップＳ２３では、ソケットＳＴ１を受信用として設定している。
【００７１】
この場合、ゲートウエイ装置１３がゲートウエイ装置１２側に届けたい情報があるなら、ソケットＳＴ１のポートを示すポート番号宛てに送信する可能性が高いと考えられるが、ソケットＳＴ２のポート番号宛てに送信してくる可能性に備えて、ソケットＳＴ２の受信機能も有効にしておいてもよい。
【００７２】
このように、ゲートウエイ装置１２と１３のあいだに２本のコネクションＣＮ１１，ＣＮ１２が確立された状態は、図６（Ｂ）の形に示すことができる。ただし、図６（Ｂ）の例では、ソケットＳＴ２の受信機能は用いないものとし、受信はソケットＳＴ１で行い、送信はソケットＳＴ２で行うものとしている。図６（Ｂ）の状態となり得るのは、相手のゲートウエイ装置１３が前記第１または第２のタイプに属する場合である。
【００７３】
ステップＳ１４〜Ｓ１７は、このステップＳ１１〜Ｓ１３およびＳ２３の部分と対応する処理となっている。
【００７４】
すなわち、ステップＳ１４は前記ステップＳ１１に対応し、ステップＳ１５は前記ステップＳ１２に対応し、ステップＳ１６は前記ステップＳ１３に対応し、ステップＳ１７は前記ステップＳ２３に対応するので、その詳しい説明は省略する。
【００７５】
ただし、ステップＳ１４は、ゲートウエイ装置１２からみたConnect 側の接続（送信用コネクション）の確立を検知するものであり、ステップＳ１５は、受信用コネクションがすでに確立済みであるか否かを検査するものであり、ステップＳ１６は１本だけ確立されているコネクションを用いて送信と受信を行うため、ソケットＳＴ２を送信用および受信用として設定するものであり、ステップＳ１７はソケットＳＴ２が２本目のコネクションを確立できたときソケットＳＴ１を送信用として設定するものである。
【００７６】
なお、相手のゲートウエイ装置１３のタイプやネットワーク１１の状態などにも依存するが、ゲートウエイ装置１２側からファクシミリ送信を行おうとする場合、ステップＳ１５がＮｏ側に分岐する可能性は、前記ステップＳ１２がＮｏ側に分岐する可能性よりも、はるかに高いものと考えられる。
【００７７】
例えば、相手のゲートウエイ装置１３が前記第３のタイプに属する１コネクション型である場合には、１本目のコネクションが確立されたとき、（もし送信すべき情報があれば）そのコネクションを用いて情報を送信してくるため、ゲートウエイ装置１３によって２本目のコネクションの確立が試みられることもない。
【００７８】
前記ステップＳ１７で送信用コネクションの確立のための試みに関してタイムアウトが判定された場合には、その事実を示す情報を保存したうえで（Ｓ１８）、受信用コネクションを確立するための試みに関してもタイムアウトが判定されているか否かを検査し（Ｓ１９）、判定されている場合には、送信用コネクションも受信用コネクションも確立できないことが確定して接続処理が終了する（Ｓ２４）。例えば、ネットワーク１１に障害や輻輳状態が発生している場合や、相手のゲートウエイ装置１３に障害が発生している場合などに、送信用コネクションも受信用コネクションも確立できないことが確定する。この場合には、ファクシミリ装置１４を介して前記ユーザＵ１にその旨のメッセージを伝え、ファクシミリ送信ができないことを知らせるようにするとよい。
【００７９】
ただし、受信用コネクションの確立のための試みに関してタイムアウトが判定されていない場合には、ステップＳ１９がＮｏ側に分岐して、前記ステップＳ１０，Ｓ１７，Ｓ１８、Ｓ１９によって構成されるループが繰り返し処理される。これは例えば図５（Ｂ）に対応する処理である。図５（Ｂ）の例では、受信用コネクションの確立のための試みに関してタイムアウトが判定されている（Listen TimeOut）が、実際には、タイムアウトが判定される前に相手のゲートウエイ装置１３からConnect 信号が到来して受信用コネクションが確立できる可能性もある。
【００８０】
ステップＳ２０〜Ｓ２２は、このステップＳ１７〜Ｓ１９と対応する処理となっている。すなわち、ステップＳ２０は前記ステップＳ１７に対応し、ステップＳ２１は前記ステップＳ１８と対応し、ステップＳ２２は前記ステップＳ１９と対応するので、その詳しい説明は省略する。
【００８１】
ただし、ステップＳ２１は受信用コネクションを確立するための試みに関してタイムアウトの判定がなされたときに処理され、ステップＳ２２は、送信用コネクションを確立するための試みに関してもすでにタイムアウトが判定されているか否かが検査される。
【００８２】
このステップＳ２０〜Ｓ２２およびＳ１０によって構成されるループが繰り返し処理されるとき、図５（Ｃ）のステップＳ５０〜Ｓ５２に示すように、ゲートウエイ装置１２のソケットＳＴ２からConnect 信号が繰り返し送信される。図５（Ｃ）の例では、ゲートウエイ装置１２送信するConnect 信号が届くより先に、相手のゲートウエイ装置１３が送信したConnect 信号がゲートウエイ装置１２へ届いている（Ｓ５３）。このステップＳ５３により、ゲートウエイ装置１２からみた受信用のコネクションが確立される。つづいて、ステップＳ５４で、ゲートウエイ装置１２が送信したConnect 信号が相手のゲートウエイ装置１３まで届いて送信用のコネクションの確立が行われている。
【００８３】
（Ａ−３）実施形態の効果
本実施形態によれば、送信用コネクションおよび受信用コネクションの確立に失敗したことが確定するまでの時間（前記タイムアウト時間ＭＴ１，ＭＴ２が経過するまでの時間）であっても、ユーザ（Ｕ１）が、ファクシミリ通信を開始することができるため、リアルタイム性が高まる。
【００８４】
（Ｂ）他の実施形態
上記実施形態にかかわらず、本発明はファクシミリ通信以外に適用することが可能である。
【００８５】
なお、図１に示すフローチャートを変更できる点は、以上の説明から明らかである。
【００８６】
例えば、上述したように、ゲートウエイ装置１２と１３のあいだに１本のコネクションが確立し、そのコネクションを用いて情報の送受が行えることが確認された時点で、２本目のコネクションを確立するための試みを中止するようにした場合には、フローチャートは図１とまったく異なるものとなる。
【００８７】
また、前記アドレス解決は、呼制御サーバ側で実行してもよいことは当然である。
【００８８】
さらに、本発明は、上記実施形態で用いた以外の通信プロトコルに適用できることは当然である。
【００８９】
一例として、ネットワーク層の通信プロトコルとしてＩＰプロトコルの代わりにＩＰＸプロトコルなどを用いることができる可能性がある。また、トランスポート層の通信プロトコルとしてＴＣＰプロトコル以外のコネクション型通信プロトコルを用いることができる可能性もある。さらに、呼制御プロトコルとしては、ＳＩＰやＭＧＣＰなどを用いることもできる。
【００９０】
以上の説明でハードウエア的に実現した機能の大部分はソフトウエア的に実現することができ、ソフトウエア的に実現した機能のほとんど全てはハードウエア的に実現することが可能である。
【図面の簡単な説明】
【００９１】
【図１】実施形態にかかるファクシミリ通信システムの動作例を示すフローチャートである。
【図２】実施形態で使用するゲートウエイ装置の内部構成例である。
【図３】実施形態にかかるファクシミリ通信システムの全体構成例を示す概略図である。
【図４】実施形態で使用するゲートウエイ装置に関する主としてソフトウエア的な内部構成例を示す概略図である。
【図５】実施形態の動作例を示すシーケンス図である。
【図６】実施形態の動作例を示す概念図である。
【符号の説明】
【００９２】
１０…ファクシミリ通信システム、１１…ネットワーク、１２，１３…ゲートウエイ装置、１４，１５…ファクシミリ装置、２０…ネットワークインタフェース部、２１…制御部、２２…アナログインタフェース部、２３…ソケット管理部、２４…タイムアウト判定部、２５…ゲートウエイ部、２６…記憶部、４０…ＯＳ、４１…ネットワーク管理部、４２…呼制御部、４３…電話回線管理部、４４…Ｔ．３８ＦＡＸ管理部、４５…タイマ、ＳＴ１，ＳＴ２，ＳＴ１１，ＳＴ２１、ＳＴ２２…ソケット。
【技術分野】
【０００１】
本発明は通信システム、通信方法、および通信プログラムに関し、例えば、ＩＴＵ−Ｔ勧告Ｔ．３８のファクシミリ通信を実現するためのゲートウエイ装置などに適用して好適なものである。
【背景技術】
【０００２】
コネクション型の通信に関する技術として下記の非特許文献１に記載されたものがある。
【０００３】
この非特許文献１は、ＩＰネットワーク上でＧ３ファクシミリ通信を行うための規格を定めたものである。当該非特許文献１には、ゲートウエイ装置間に２本のＴＣＰセッション（ＴＣＰコネクション）を確立した上でファクシミリ通信を行うケースについて記載されている。
【０００４】
２本のコネクションを確立した場合、１つのコネクションを送信用とし、もう１つのコネクションを受信用とすることができる。
【非特許文献１】ＩＴＵ−Ｔ勧告Ｔ．３８
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところで、上述した非特許文献１に比較的忠実な実装を行ったゲートウエイ装置では、１つのコネクションのみが確立され、もう１つのコネクションがタイムアウトによって確立に失敗したことが確定した場合、確立された１つのコネクションを用いて送信と受信を行うことができる。しかしながら、例えば、確立されたものが受信用のコネクションで、確立に失敗したものが送信用のコネクションである場合、確立に失敗したことが確定する前に、収容しているＧ３ファクシミリ装置から送信すべき情報が届くと、ゲートウエイ装置はこの情報を正常に送信することができないため、Ｇ３ファクシミリ装置を使用するユーザは、確立に失敗したことが確定するまでの時間（前記タイムアウトが判定されるまでの時間）、ファクシミリ通信の開始を待たされることになり、通信のリアルタイム性が低かった。
【課題を解決するための手段】
【０００６】
かかる課題を解決するために、第１の本発明では、通信時に、１つの通信装置が送信用と受信用に１つずつ、合計２つのコネクションを確立し、当該通信装置内でトランスポート層の通信プロトコルを処理するトランスポート層エンティティとして、当該通信装置から情報を送信するときに機能する送信用ポートと受信するときに機能する受信用ポートを用いるコネクション型の通信システムにおいて、前記２つのコネクションうちの１つしか確立されない場合、所定のタイムアウト時間が経過する前であっても、その１つのコネクションに送信用ポートと受信用ポートを対応付けて、当該コネクションを送信用および受信用に割り当てるコネクション制御部を備えたことを特徴とする。
【０００７】
また、第２の本発明では、通信時に、１つの通信装置が送信用と受信用に１つずつ、合計２つのコネクションを確立し、当該通信装置内でトランスポート層の通信プロトコルを処理するトランスポート層エンティティとして、当該通信装置から情報を送信するときに機能する送信用ポートと受信するときに機能する受信用ポートを用いるコネクション型の通信方法において、前記２つのコネクションうちの１つしか確立されない場合、所定のタイムアウト時間が経過する前であっても、その１つのコネクションに送信用ポートと受信用ポートを対応付けて、当該コネクションを送信用および受信用に割り当てることを特徴とする。
【０００８】
さらに、第３の本発明では、通信時に、１つの通信装置が送信用と受信用に１つずつ、合計２つのコネクションを確立し、当該通信装置内でトランスポート層の通信プロトコルを処理するトランスポート層エンティティとして、当該通信装置から情報を送信するときに機能する送信用ポートと受信するときに機能する受信用ポートを用いるコネクション型の通信プログラムにおいて、コンピュータに、前記２つのコネクションうちの１つしか確立されない場合、所定のタイムアウト時間が経過する前であっても、その１つのコネクションに送信用ポートと受信用ポートを対応付けて、当該コネクションを送信用および受信用に割り当てるコネクション制御機能を実現させることを特徴とする。
【発明の効果】
【０００９】
本発明によれば、通信のリアルタイム性を高めることができる。
【発明を実施するための最良の形態】
【００１０】
（Ａ）実施形態
以下、本発明にかかる通信システム、通信方法、および通信プログラムをＩＰネットワークを用いるファクシミリ通信システムに適用した場合を例に、実施形態について説明する。
【００１１】
（Ａ−１）実施形態の構成
本実施形態にかかるファクシミリ通信システム１０の全体構成例を図３に示す。なお、当該ファクシミリ通信システム１０中に、図示しないサーバ類（例えば、ＤＮＳサーバやＤＨＣＰサーバなど）やネットワーク機器（ハブやルータなど）が存在していてもよいことは当然である。
【００１２】
図３において、当該ファクシミリ通信システム１０は、ネットワーク１１と、ゲートウエイ装置１２，１３と、ファクシミリ装置１４，１５とを備えている。
【００１３】
このうちネットワーク１１は、例えば、ある企業の内部で使用されるＬＡＮ（ローカルエリアネットワーク）などであってもよく、インターネットなどであってもよいが、当該ネットワーク１１はＯＳＩ参照モデルのネットワーク層でＩＰプロトコルが通用するものである。
【００１４】
ファクシミリ装置１４は通常のＧ３ファクシミリ装置である。したがって、当該ファクシミリ装置１４自体はＩＰプロトコルを処理する機能などを持たないため、直接、ネットワーク１１に接続することはできず、ゲートウエイ装置１２経由で接続されることになる。
【００１５】
この点は、ファクシミリ装置１５も同様で、ゲートウエイ装置１３経由でネットワーク１１に接続される。ゲートウエイ装置１２，１３はＶｏＩＰゲートウエイを構成する。
【００１６】
ファクシミリ装置１４はユーザＵ１によって使用され、ファクシミリ装置１５はユーザＵ２によって使用されるものとする。
【００１７】
ゲートウエイ装置１２は前記非特許文献１のＩＴＵ−Ｔ勧告Ｔ．３８に準拠した構成を備えているが、従来とは異なる特徴も有する。以下では、主として、当該ゲートウエイ装置１２側からみて、相手のゲートウエイ装置１３とのあいだの送信、受信を説明する。相手のゲートウエイ装置１３が取り得る構成については、大きく３つのタイプに分けることができる。
【００１８】
その第１は、前記ゲートウエイ装置１２と同じ構成を持つタイプ、第２は、従来と同様の２コネクション型のゲートウエイ装置であるタイプ、第３は、１コネクション型のゲートウエイ装置であるタイプである。ここで、コネクションとはＯＳＩ参照モデルのトランスポート層の通信プロトコルであるＴＣＰのコネクション（ＴＣＰセッション）を指す。コネクションは論理的な通信路であって、そのほぼ両端に、ゲートウエイ装置１２のＴＣＰポート（ソケット）とゲートウエイ装置１３のＴＣＰポート（ソケット）が位置する形になる。
【００１９】
第２のタイプに対応する２コネクション型のゲートウエイ装置１３は、［発明が解決しようとする課題］の項で説明したゲートウエイ装置にあたる。すなわち、当該ゲートウエイ装置１３で、１つのコネクションのみが確立され、もう１つのコネクションがタイムアウトによって確立に失敗したことが確定した場合、確立された１つのコネクションを用いて送信と受信を行うことができるものの、例えば、確立されたものが受信用のコネクションで、確立に失敗したものが送信用のコネクションである場合、確立に失敗したことが確定する前に、収容しているＧ３ファクシミリ装置（ここでは、１５）から送信すべき情報が届くと、ゲートウエイ装置１３はこの情報を正常に送信することができないため、Ｇ３ファクシミリ装置を使用するユーザ（ここでは、Ｕ２）は、確立に失敗したことが確定するまでの時間、ファクシミリ通信の開始を待たされることになる。
【００２０】
第１のタイプに対応する本実施形態に特徴的なゲートウエイ装置も２コネクション型のゲートウエイ装置の一種であるとみることができるが、タイムアウトの前であっても、確立された１つのコネクションを送信と受信に利用できる点が異なる。その詳細については後述する。
【００２１】
第３のタイプに対応するゲートウエイ装置は、元々、１つのコネクションを確立する機能しか持たないもので、確立された１つのコネクションを利用して送信と受信を行う。
【００２２】
前記ゲートウエイ装置１２の内部構成は例えば図２に示す通りである。前記第１のタイプの場合、相手のゲートウエイ装置１３の内部構成もこれと同じになる。
【００２３】
（Ａ−１−１）ゲートウエイ装置の内部構成例
図２において、当該ゲートウエイ装置１２は、ネットワークインタフェース部２０と、制御部２１と、アナログインタフェース部２２と、ソケット管理部２３と、タイムアウト判定部２４と、ゲートウエイ部２５と、記憶部２６とを備えている。
【００２４】
このうちネットワークインタフェース部２０は、前記ネットワーク１１に接続されるインタフェースで、ＯＳＩ参照モデルの物理層やデータリンク層などを処理する機能を有する。
【００２５】
アナログインタフェース部２２は、前記ファクシミリ装置１４を接続するためのインタフェースである。
【００２６】
制御部２１はハードウエア的には当該ゲートウエイ装置１２のＣＰＵ（中央処理装置）などに相当し得る部分であり、ソフトウエア的には当該ゲートウエイ装置１２のＯＳ（オペレーティングシステム）などに相当し得る部分である。
【００２７】
記憶部２６はハードウエア的には揮発性または不揮発性の各種記憶手段（例えば、ＲＡＭやハードディスクなど）に相当する部分であり、ソフトウエア的には各種のファイルに相当する。前記ＯＳなどを収容したプログラムファイルもこのようなファイルの１つであるから、物理的には、前記ＯＳも当該記憶部２６に位置することになる。
【００２８】
ゲートウエイ部２５は、ゲートウエイ（ＶｏＩＰゲートウエイ）の機能を提供する部分である。すなわち、ファクシミリ装置１４から１５へ送信される情報は、当該ゲートウエイ部２５で必要な各種の処理（例えば、符号化など）を経たあと、ＩＰパケットに収容されてネットワーク１１に送出されることになる。反対に、ファクシミリ装置１５から１４に届けられる情報は当該ゲートウエイ部２５でＩＰパケットから抽出されたあと、必要な各種の処理（例えば、復号化など）を経たあとで、前記アナログインタフェース部２２を介してファクシミリ装置１４に届けられることになる。
【００２９】
なお、ネットワーク１１では宛先を識別するための識別子として有効な識別子はＩＰアドレスだけであるが、その一方で、ユーザＵ１が宛先を指定するために入力するのは、通常、宛先となるファクシミリ装置１５のファクシミリ番号ＦＮ１５である。
【００３０】
したがって、ファクシミリ番号とＩＰアドレスの対応関係を調べ、入力されたファクシミリ番号ＦＮ１５から宛先のゲートウエイ装置１３のＩＰアドレスＩＡ１３を特定するためのアドレス解決の過程が必要となる。ゲートウエイ装置１２内でこのアドレス解決を分担するのも、当該ゲートウエイ部２５である。ＩＴＵ−Ｔ勧告Ｔ．３８では、呼制御プロトコルとしてＨ．３２３を用いるため、ファクシミリ番号とＩＰアドレスの対応関係を蓄積しているのは図示しないＨ．３２３ゲートキーパであり、ゲートウエイ部２５は当該ゲートキーパと通信することによってアドレス解決を行い、その結果として宛先ＩＰアドレスにＩＡ１３を持つＩＰパケットを送信することになる。
【００３１】
ソケット管理部２３は前記ソケットを管理する部分である。ソケットが前記ＴＣＰポートを備えている。ソケットは例えばＡＰＩ（アプリケーション・プログラミング・インタフェース）などの形式で実現され得るプログラムである。ＯＳＩ参照モデルやＴＣＰ／ＩＰプロトコル体系に忠実なモジュール分けを行う場合、トランスポート層に位置付けられる当該ソケット（ＴＣＰポート）は、それ自体、独立した１つのプログラムとして実現される。必要に応じて、当該ソケットはＯＳＩ参照モデルのセッション層に属する機能も有する。
【００３２】
同じトランスポート層のなかでさらにモジュール分けを行うか否かは自由であるが、ここでは、２つのソケットＳＴ１，ＳＴ２を別個のモジュールとして構成するものとする。
【００３３】
また、プログラムとしてのソケットＳＴ１，ＳＴ２に送信用の機能と受信用の機能をどのように持たせるかについてはいくつかのケースがあり、例えば、送信用の機能のみしか持たないソケットと、受信用の機能のみしか持たないソケットを用意することも考えられるが、ここでは、各ソケットＳＴ１，ＳＴ２が送信用の機能と受信用の機能を備えており、必要なときにいずれか一方または双方の機能を発揮するものとする。ただし、当初、送信用のポート（送信用ソケット）として機能するほうをＳＴ１とし、受信用のポート（受信用ソケット）として機能するほうをＳＴ２とする。
【００３４】
ソケット管理部２３は、当該ソケットＳＴ１，ＳＴ２の状態遷移（例えば、実行可能状態、実行状態、待ち状態のあいだの遷移）などを管理する。この状態遷移のタイミングの違いに本実施形態の特徴の本質がある。
【００３５】
タイムアウト判定部２４は、タイムアウトの判定を行う部分で、所定の手順を実行しタイムアウト時間ＭＴ１が経過してもそのコネクションの確立が検知できない場合にタイムアウトであると判定する。この手順には様々なものが考えられるが、相手のゲートウエイ装置１３に対して送信用コネクション（このコネクションは、ゲートウエイ装置１３からみると受信用コネクション）の確立を要求するためのコネクション確立制御信号であるConnect信号を所定時間置きに所定回数送信しても、応答信号（必ずしも応答のために予め定められた信号である必要はない）が返送されてこない場合には、タイムアウトと判定するものであってよい。これは、例えば、ネットワーク１１上でのパケット損失や相手のゲートウエイ装置１３の一時的な障害発生などが起きてもコネクションを確立するための手順である。具体的なタイムアウト時間ＭＴ１がどの程度の時間になるかは、この手順の内容によるが、その性質上、かなり長時間になることが避けられない。一例としては、最初にConnect 信号を送信してから３０秒程度の時間になる可能性がある。
【００３６】
受信用コネクション（このコネクションは相手のゲートウエイ装置１３からみると送信用コネクション）の確立は相手のゲートウエイ装置１３がConnect 信号を送信してきたときに行われる受動的な処理であるが、相手のゲートウエイ装置１３も２コネクション型であり、ゲートウエイ装置１２からConnect 信号を先に送信する場合を想定すると、ゲートウエイ装置１２がConnect 信号を送信し、それに応えて相手のゲートウエイ装置１３もConnect 信号を送信し、このConnect 信号がゲートウエイ装置１２まで届いたときに当該受信用コネクションの確立が行われる。したがって、受信用コネクションの確立に関するタイムアウトは、ゲートウエイ装置１２がConnect 信号の送信を開始した時刻から所定のタイムアウト時間ＭＴ２（ＭＴ２は必要に応じて、前記ＭＴ１と同じ値としてもよい）が経過しても相手のゲートウエイ装置１３からConnect 信号が届かない場合に、受信用コネクションの確立がタイムアウトによって失敗したものと確定的に判定するものであってよい。
【００３７】
以上の説明からも明らかなように、本実施形態で特徴的な構成要素２３，２４の機能は、通常、ＯＳの一部として実装され得るものであるが、図２では、制御部２１の外部に図示している。
【００３８】
図２に示したゲートウエイ装置１２のソフトウエア的な構成は別な観点から図４に示す形にまとめることができる。
【００３９】
図４において、当該ゲートウエイ装置１２は、ＯＳ４０と、ネットワーク管理部４１と、呼制御部４２と、電話回線管理部４３と、Ｔ．３８ＦＡＸ管理部４４と、タイマ４５とを備えている。
【００４０】
このうちＯＳ４０は上述したＯＳに対応する。ネットワーク管理部４１はネットワーク機能を管理する部分で、タイマ４５は前記タイムアウトを判定するとき等に必要な時間の計測を行う部分である。ＯＳ４０の構成にも依存するが、当該ネットワーク管理部４１やタイマ４５等はＯＳ４０の一部として実装される可能性が高い。その他の構成要素４２〜４４は、ＯＳ４０上で動作する通信アプリケーションである。
【００４１】
構成要素４２〜４４のうち電話回線管理部４３は、ゲートウエイ装置１２に収容されているファクシミリ装置１４（一般電話機などでも同じ）などＶｏＩＰ機能を持たない通信装置を接続する部分である。
【００４２】
また、Ｔ．３８ＦＡＸ管理部４４は、ＩＰプロトコル上でファクシミリ通信を実現するための伝送制御プロトコルであるＴ．３８を処理する部分である。
【００４３】
呼制御部４２は、ファクシミリ通信のための呼制御を実行する部分である。
【００４４】
電話回線管理部４３は前記アナログインタフェース部２２に対応し、呼制御部４２およびＴ．３８ＦＡＸ管理部４４は、前記ゲートウエイ部２５に対応する。また、ネットワーク管理部４１の一部として、前記ソケット管理部２３が含まれ得る。
【００４５】
以下、上記のような構成を有する本実施形態の動作について図１、図５，図６を用いて説明する。
【００４６】
図１は前記ソケットＳＴ１，ＳＴ２に関連する動作を示すフローチャートで、Ｓ１０〜Ｓ２４の各ステップから構成されている。
【００４７】
図５（Ａ）〜（Ｄ）は、典型的な４つのケースごとに、ソケットＳＴ１、ＳＴ２に関連する動作を示すシーケンス図で、Ｓ３０〜Ｓ３４、Ｓ４０〜Ｓ４２，Ｓ５０〜Ｓ５４，Ｓ６０〜Ｓ６１の各ステップを備えている。
【００４８】
図６（Ａ）〜（Ｄ）は、ソケットＳＴ１、ＳＴ２に関連する動作を示す概念図である。図６（Ａ）〜（Ｄ）上で１つのソケット（例えば、ＳＴ１）を示すブロック内に「送・受」とあるのは、そのソケットが送信機能と受信機能を備えていることを示している。また、「送」および／または「受」を括弧で括って「（送）」などと記述したものは、その時点で、その機能が使用されない状態にあることを示している。逆に、括弧で括っていないものはその機能が使用される状態にあることを示している。したがって、例えば、図６（Ｂ）のソケットＳＴ１のように「送・（受）」とあれば、そのとき当該ソケットＳＴ１の送信機能は使用される状態にあるが、受信機能は使用されない状態にあることを示している。
【００４９】
（Ａ−２）実施形態の動作
所定の開始イベントが発生したとき、それに応じて、前記ゲートウエイ装置１２内のソケット管理部２３がソケットＳＴ１と、ＳＴ２に対応するプロセス（タスク）を生成する。このとき、２つのソケットＳＴ１，ＳＴ２に対応する２つのプロセスを生成するのは、当該ゲートウエイ装置１２が２コネクション型のゲートウエイ装置だからである。
【００５０】
また、開始イベントとしては様々なものがあり得るが、例えば、ユーザＵ１がファクシミリ装置１４でファクシミリ送信を行うために相手のファクシミリ装置１５のファクシミリ番号ＦＮ１５の最初の１桁を入力し、それを前記アナログインタフェース部２２や制御部２１が検知したときに生成するものであってもよいし、逆に、相手のゲートウエイ装置１３から呼設定を要求する呼設定メッセージを含むＩＰパケットが届いたことを検知したとき等に生成するものであってもよい。前者は、ユーザＵ１がユーザＵ２へファクシミリ送信を行う場合であり、後者は、ユーザＵ２がユーザＵ１へファクシミリ送信を行う場合であるものとする。以下では、主として、ユーザＵ１からユーザＵ２へファクシミリ送信を行う場合を前提に説明を進める。
【００５１】
上述したように、２つのソケットＳＴ１，ＳＴ２はともに送信機能と受信機能を持つが、最初にそのプロセスが生成された直後には、ソケットＳＴ１は受信機能のみ用いられてConnect 信号の到着を待つものの、送信機能は用いられない。これと反対に、ソケットＳＴ２のほうは、最初にそのプロセスが生成された直後には、送信機能のみ用いられてConnect 信号を送信するが、受信機能は用いられない。
【００５２】
これは図６（Ｂ）に示すゲートウエイ装置１２内の状態にあたる。
【００５３】
したがって当初は、図１のステップＳ１０に示すように、ソケットＳＴ１が相手のゲートウエイ装置１３から届くConnect 信号を待ち受け、ソケットＳＴ２は相手のゲートウエイ装置１３へConnect 信号を送信する。
【００５４】
ステップＳ１０のあと、４つのイベントのうちいずれが検知されるかに応じて４つの分岐先に分岐する。
【００５５】
第１のイベントは相手側からConnect 信号が到来してListen側の接続（受信用コネクション）が確立することであり、このイベントは前記ソケットＳＴ１がそのConnect信号を受信することによってステップＳ１１で検知される。第２のイベントはソケットＳＴ２が送信したConnect信号が相手のゲートウエイ装置１３内の該当するソケット（例えば、ＳＴ１１やＳＴ２１）に受信されたことによってConnect側の接続（送信用コネクション）が確立することである。図５（Ａ）〜（Ｄ）に示したシーケンスにしたがう限り、Connect 信号の送信元であるゲートウエイ装置１２内のソケットＳＴ２自身が直接、このイベントの発生を検知する方法はない。ただし、例えばConnect信号にソケットＳＴ２が持つポート（または、ソケットＳＴ１が持つポート）のポート番号を記述しておき、相手のゲートウエイ装置１３が当該ポート番号宛てに何らかの信号（前記応答信号に対応）を返送してきた場合には、その信号を受信したことをもって、ステップＳ１４で送信用コネクションの確立を検知することができる。
【００５６】
相手のゲートウエイ装置１３が上述した第１または第２のタイプに属する２コネクション型である場合には、ゲートウエイ装置１２からConnect 信号が届いたことによって確立された１本目のコネクション（ゲートウエイ装置１２からみると送信用コネクション）のほかに、２本目のコネクション（ゲートウエイ装置１２からみると受信用コネクション）を確立しようとしてConnect 信号を送信するが、そのConnect 信号をゲートウエイ装置１２が受信したことをもって、ゲートウエイ装置１２からみた前記送信用コネクションが確立されたことを検知するようにしてもよい。
【００５７】
第３のイベントはConnect 側の接続に失敗（送信用コネクションの確立に失敗）したことが確定したことである。このイベントの発生は、前記タイムアウト判定部２４が上述した方法によって判定を行うことで、前記ステップＳ１７で検知することができる。
【００５８】
第４のイベントはListen側の接続に失敗したことが確定したことである。このイベントの発生は、前記タイプアウト判定部が上述した方法によって判定を行うことで、ステップＳ２０で検知することができる。
【００５９】
前記ステップＳ１１につづくステップＳ１２では、すでに送信用コネクションが確立されているか否かを検査する。確立されていない場合、ステップＳ１２はＮｏ側に分岐して処理はステップＳ１３に進む。ステップＳ１３では、ソケットＳＴ１を送信用および受信用として用いるための設定を行う。
【００６０】
ステップＳ１２がＮｏ側に分岐したということは相手のゲートウエイ装置１３には、ゲートウエイ装置１２内のソケットＳＴ２の存在が認められていない可能性が高いが、前記ステップＳ１１が処理されたことにより、相手側のゲートウエイ装置１３にゲートウエイ装置１２内のソケットＳＴ１の存在が認められていることは明らかであるためである。このとき、前記タイムアウト時間ＭＴ１またはＭＴ２を経過することによるタイムアウトが発生している必要はないため、ゲートウエイ装置１２はタイムアウト時間ＭＴ１，ＭＴ２の経過より早いタイミングで、ユーザＵ１の望むファクシミリ送信を開始することが可能となる。
【００６１】
相手のゲートウエイ装置１３が上述した第２のタイプである場合には、ゲートウエイ装置１２がファクシミリ送信を行っても、相手のゲートウエイ装置１３内でタイムアウト時間（ＭＴ１，ＭＴ２に相当）が経過するまでは、図６（Ｃ）に示すようにソケットＳＴ２１内の受信機能のみが用いられて送信機能は用いられないため、正常な通信が行えない可能性があるが、信頼性の高いＴＣＰプロトコルを用いているから、ＴＣＰプロトコルの機能により、最終的には、ユーザＵ１が望む情報が相手のゲートウエイ装置１３およびファクシミリ装置１５まで送達される。ソケットＳＴ２１やＳＴ２２自体の機能は、前記ソケットＳＴ２などと同じである。なお、図６（Ｃ）上、実線で示したコネクションＣＮ１１はすでに確立されたコネクションであり、一点鎖線で示したコネクションＣＮ１２はまだ確立されていないコネクションである。この点は、図６（Ｄ）も同様である。
【００６２】
相手ゲートウエイ装置１３が第２のタイプであっても、ゲートウエイ装置１３内でタイムアウト時間ＭＴ１が経過しタイムアウト判定が行われれば、図６（Ｄ）に示すように、それまで用いられていなかったソケットＳＴ２１内の送信機能が用いられるようになるため、正常な通信を行うことが可能となる。
【００６３】
これに対し相手のゲートウエイ装置１３が上述した第１または第３のタイプである場合には、すでに相手のゲートウエイ装置１３内でソケットの受信機能および送信機能が有効になっていて、タイムアウト時間ＭＴ１，ＭＴ２の経過より早いタイミングで、ユーザＵ１の望む情報を、相手のゲートウエイ装置１３およびファクシミリ装置１５まで送達できる可能性が高い。
【００６４】
相手のゲートウエイ装置１３が前記第３のタイプに対応する１コネクション型である場合、図６（Ａ）に示すように、ゲートウエイ装置１２内の前記ソケットＳＴ２と、ゲートウエイ装置１３内のソケットＳＴ１１のあいだに確立された１つのコネクションＣＮ１を用いて情報が双方向にやり取りされ得る。
【００６５】
ソケットＳＴ１１は基本的にソケットＳＴ２と同じものであるが、ゲートウエイ装置１３が１コネクション型なので、ゲートウエイ装置１３内にソケットは１つしか存在しない。
【００６６】
相手のゲートウエイ装置１３のタイプやネットワーク１１の状態などにも依存するが、ゲートウエイ装置１２側からファクシミリ送信を行おうとする場合、相手ゲートウエイ装置１３は、ゲートウエイ装置１２が送信したConnect信号を受信したからこそConnect信号を返送したものである可能性が高いから、ゲートウエイ装置１２からみた送信用のコネクションが確立されず、受信用のコネクションのみが確立されるという現象（これは、ステップＳ１２がＮｏ側に分岐することに対応）は、確率的に起こりにくいものと考えられる。
【００６７】
ゲートウエイ装置１２と１３のあいだに１本のコネクションが確立し、そのコネクションを用いて情報の送受が行えることが確認された時点で、２本目のコネクションを確立するための試みを中止するようにしてもかまわないが、図１の例では、前記ステップＳ１０が実行され、前記ソケットＳＴ１がConnect 信号を送ることによって、２本目のコネクションの確立のための試みを繰り返している。
【００６８】
この試みは、図５（Ａ）のステップＳ３１〜Ｓ３３に対応する。この試みが繰り返されている間、図１上では、ステップＳ１０，Ｓ１１，Ｓ１２、Ｓ１３によって構成されるループが繰り返し処理される。なお、図５（Ｄ）の例では、Connect 信号の送信が繰り返されることなく、ゲートウエイ装置１２が送信したConnect 信号も、ゲートウエイ装置１３が送信したConnect 信号も１度で宛先に届いている（Ｓ６０、Ｓ６１）。これは、例えば、ステップＳ６０でConnect 信号を受信した相手のゲートウエイ装置１３が、その応答として送信したConnect 信号がゲートウエイ装置１２に受信されたものであってよい。
【００６９】
一方、図１に示す前記ステップＳ１２がＹｅｓ側に分岐する場合、前記ステップＳ１０の内部ですでに、ゲートウエイ装置１２からみた送信用コネクションの確立は完了しており、ステップＳ１１で受信用コネクションが確立されたことによって、２本のコネクションが確立されたことになるため、今回、ステップＳ２３でソケットＳＴ１を受信用に設定して接続処理を終了する（Ｓ２４）。
【００７０】
送信用コネクションはすでに確立済みなので、相手のゲートウエイ装置１３において、当該ソケットＳＴ２はゲートウエイ装置１２における送信用ソケットであるものとしてすでに認められている可能性が高いが、今回、ステップＳ１１が処理されたことにより、ソケットＳＴ１がゲートウエイ装置１２における受信用ソケットとして認められることになる。したがって、ステップＳ１２のＹｅｓ側の分岐につづくステップＳ２３では、ソケットＳＴ１を受信用として設定している。
【００７１】
この場合、ゲートウエイ装置１３がゲートウエイ装置１２側に届けたい情報があるなら、ソケットＳＴ１のポートを示すポート番号宛てに送信する可能性が高いと考えられるが、ソケットＳＴ２のポート番号宛てに送信してくる可能性に備えて、ソケットＳＴ２の受信機能も有効にしておいてもよい。
【００７２】
このように、ゲートウエイ装置１２と１３のあいだに２本のコネクションＣＮ１１，ＣＮ１２が確立された状態は、図６（Ｂ）の形に示すことができる。ただし、図６（Ｂ）の例では、ソケットＳＴ２の受信機能は用いないものとし、受信はソケットＳＴ１で行い、送信はソケットＳＴ２で行うものとしている。図６（Ｂ）の状態となり得るのは、相手のゲートウエイ装置１３が前記第１または第２のタイプに属する場合である。
【００７３】
ステップＳ１４〜Ｓ１７は、このステップＳ１１〜Ｓ１３およびＳ２３の部分と対応する処理となっている。
【００７４】
すなわち、ステップＳ１４は前記ステップＳ１１に対応し、ステップＳ１５は前記ステップＳ１２に対応し、ステップＳ１６は前記ステップＳ１３に対応し、ステップＳ１７は前記ステップＳ２３に対応するので、その詳しい説明は省略する。
【００７５】
ただし、ステップＳ１４は、ゲートウエイ装置１２からみたConnect 側の接続（送信用コネクション）の確立を検知するものであり、ステップＳ１５は、受信用コネクションがすでに確立済みであるか否かを検査するものであり、ステップＳ１６は１本だけ確立されているコネクションを用いて送信と受信を行うため、ソケットＳＴ２を送信用および受信用として設定するものであり、ステップＳ１７はソケットＳＴ２が２本目のコネクションを確立できたときソケットＳＴ１を送信用として設定するものである。
【００７６】
なお、相手のゲートウエイ装置１３のタイプやネットワーク１１の状態などにも依存するが、ゲートウエイ装置１２側からファクシミリ送信を行おうとする場合、ステップＳ１５がＮｏ側に分岐する可能性は、前記ステップＳ１２がＮｏ側に分岐する可能性よりも、はるかに高いものと考えられる。
【００７７】
例えば、相手のゲートウエイ装置１３が前記第３のタイプに属する１コネクション型である場合には、１本目のコネクションが確立されたとき、（もし送信すべき情報があれば）そのコネクションを用いて情報を送信してくるため、ゲートウエイ装置１３によって２本目のコネクションの確立が試みられることもない。
【００７８】
前記ステップＳ１７で送信用コネクションの確立のための試みに関してタイムアウトが判定された場合には、その事実を示す情報を保存したうえで（Ｓ１８）、受信用コネクションを確立するための試みに関してもタイムアウトが判定されているか否かを検査し（Ｓ１９）、判定されている場合には、送信用コネクションも受信用コネクションも確立できないことが確定して接続処理が終了する（Ｓ２４）。例えば、ネットワーク１１に障害や輻輳状態が発生している場合や、相手のゲートウエイ装置１３に障害が発生している場合などに、送信用コネクションも受信用コネクションも確立できないことが確定する。この場合には、ファクシミリ装置１４を介して前記ユーザＵ１にその旨のメッセージを伝え、ファクシミリ送信ができないことを知らせるようにするとよい。
【００７９】
ただし、受信用コネクションの確立のための試みに関してタイムアウトが判定されていない場合には、ステップＳ１９がＮｏ側に分岐して、前記ステップＳ１０，Ｓ１７，Ｓ１８、Ｓ１９によって構成されるループが繰り返し処理される。これは例えば図５（Ｂ）に対応する処理である。図５（Ｂ）の例では、受信用コネクションの確立のための試みに関してタイムアウトが判定されている（Listen TimeOut）が、実際には、タイムアウトが判定される前に相手のゲートウエイ装置１３からConnect 信号が到来して受信用コネクションが確立できる可能性もある。
【００８０】
ステップＳ２０〜Ｓ２２は、このステップＳ１７〜Ｓ１９と対応する処理となっている。すなわち、ステップＳ２０は前記ステップＳ１７に対応し、ステップＳ２１は前記ステップＳ１８と対応し、ステップＳ２２は前記ステップＳ１９と対応するので、その詳しい説明は省略する。
【００８１】
ただし、ステップＳ２１は受信用コネクションを確立するための試みに関してタイムアウトの判定がなされたときに処理され、ステップＳ２２は、送信用コネクションを確立するための試みに関してもすでにタイムアウトが判定されているか否かが検査される。
【００８２】
このステップＳ２０〜Ｓ２２およびＳ１０によって構成されるループが繰り返し処理されるとき、図５（Ｃ）のステップＳ５０〜Ｓ５２に示すように、ゲートウエイ装置１２のソケットＳＴ２からConnect 信号が繰り返し送信される。図５（Ｃ）の例では、ゲートウエイ装置１２送信するConnect 信号が届くより先に、相手のゲートウエイ装置１３が送信したConnect 信号がゲートウエイ装置１２へ届いている（Ｓ５３）。このステップＳ５３により、ゲートウエイ装置１２からみた受信用のコネクションが確立される。つづいて、ステップＳ５４で、ゲートウエイ装置１２が送信したConnect 信号が相手のゲートウエイ装置１３まで届いて送信用のコネクションの確立が行われている。
【００８３】
（Ａ−３）実施形態の効果
本実施形態によれば、送信用コネクションおよび受信用コネクションの確立に失敗したことが確定するまでの時間（前記タイムアウト時間ＭＴ１，ＭＴ２が経過するまでの時間）であっても、ユーザ（Ｕ１）が、ファクシミリ通信を開始することができるため、リアルタイム性が高まる。
【００８４】
（Ｂ）他の実施形態
上記実施形態にかかわらず、本発明はファクシミリ通信以外に適用することが可能である。
【００８５】
なお、図１に示すフローチャートを変更できる点は、以上の説明から明らかである。
【００８６】
例えば、上述したように、ゲートウエイ装置１２と１３のあいだに１本のコネクションが確立し、そのコネクションを用いて情報の送受が行えることが確認された時点で、２本目のコネクションを確立するための試みを中止するようにした場合には、フローチャートは図１とまったく異なるものとなる。
【００８７】
また、前記アドレス解決は、呼制御サーバ側で実行してもよいことは当然である。
【００８８】
さらに、本発明は、上記実施形態で用いた以外の通信プロトコルに適用できることは当然である。
【００８９】
一例として、ネットワーク層の通信プロトコルとしてＩＰプロトコルの代わりにＩＰＸプロトコルなどを用いることができる可能性がある。また、トランスポート層の通信プロトコルとしてＴＣＰプロトコル以外のコネクション型通信プロトコルを用いることができる可能性もある。さらに、呼制御プロトコルとしては、ＳＩＰやＭＧＣＰなどを用いることもできる。
【００９０】
以上の説明でハードウエア的に実現した機能の大部分はソフトウエア的に実現することができ、ソフトウエア的に実現した機能のほとんど全てはハードウエア的に実現することが可能である。
【図面の簡単な説明】
【００９１】
【図１】実施形態にかかるファクシミリ通信システムの動作例を示すフローチャートである。
【図２】実施形態で使用するゲートウエイ装置の内部構成例である。
【図３】実施形態にかかるファクシミリ通信システムの全体構成例を示す概略図である。
【図４】実施形態で使用するゲートウエイ装置に関する主としてソフトウエア的な内部構成例を示す概略図である。
【図５】実施形態の動作例を示すシーケンス図である。
【図６】実施形態の動作例を示す概念図である。
【符号の説明】
【００９２】
１０…ファクシミリ通信システム、１１…ネットワーク、１２，１３…ゲートウエイ装置、１４，１５…ファクシミリ装置、２０…ネットワークインタフェース部、２１…制御部、２２…アナログインタフェース部、２３…ソケット管理部、２４…タイムアウト判定部、２５…ゲートウエイ部、２６…記憶部、４０…ＯＳ、４１…ネットワーク管理部、４２…呼制御部、４３…電話回線管理部、４４…Ｔ．３８ＦＡＸ管理部、４５…タイマ、ＳＴ１，ＳＴ２，ＳＴ１１，ＳＴ２１、ＳＴ２２…ソケット。
【特許請求の範囲】
【請求項１】
通信時に、１つの通信装置が送信用と受信用に１つずつ、合計２つのコネクションを確立し、当該通信装置内でトランスポート層の通信プロトコルを処理するトランスポート層エンティティとして、当該通信装置から情報を送信するときに機能する送信用ポートと受信するときに機能する受信用ポートを用いるコネクション型の通信システムにおいて、
前記２つのコネクションうちの１つしか確立されない場合、所定のタイムアウト時間が経過する前であっても、その１つのコネクションに送信用ポートと受信用ポートを対応付けて、当該コネクションを送信用および受信用に割り当てるコネクション制御部を備えたことを特徴とする通信システム。
【請求項２】
通信時に、１つの通信装置が送信用と受信用に１つずつ、合計２つのコネクションを確立し、当該通信装置内でトランスポート層の通信プロトコルを処理するトランスポート層エンティティとして、当該通信装置から情報を送信するときに機能する送信用ポートと受信するときに機能する受信用ポートを用いるコネクション型の通信方法において、
前記２つのコネクションうちの１つしか確立されない場合、所定のタイムアウト時間が経過する前であっても、その１つのコネクションに送信用ポートと受信用ポートを対応付けて、当該コネクションを送信用および受信用に割り当てることを特徴とする通信方法。
【請求項３】
通信時に、１つの通信装置が送信用と受信用に１つずつ、合計２つのコネクションを確立し、当該通信装置内でトランスポート層の通信プロトコルを処理するトランスポート層エンティティとして、当該通信装置から情報を送信するときに機能する送信用ポートと受信するときに機能する受信用ポートを用いるコネクション型の通信プログラムにおいて、コンピュータに、
前記２つのコネクションうちの１つしか確立されない場合、所定のタイムアウト時間が経過する前であっても、その１つのコネクションに送信用ポートと受信用ポートを対応付けて、当該コネクションを送信用および受信用に割り当てるコネクション制御機能を実現させることを特徴とする通信プログラム。
【請求項１】
通信時に、１つの通信装置が送信用と受信用に１つずつ、合計２つのコネクションを確立し、当該通信装置内でトランスポート層の通信プロトコルを処理するトランスポート層エンティティとして、当該通信装置から情報を送信するときに機能する送信用ポートと受信するときに機能する受信用ポートを用いるコネクション型の通信システムにおいて、
前記２つのコネクションうちの１つしか確立されない場合、所定のタイムアウト時間が経過する前であっても、その１つのコネクションに送信用ポートと受信用ポートを対応付けて、当該コネクションを送信用および受信用に割り当てるコネクション制御部を備えたことを特徴とする通信システム。
【請求項２】
通信時に、１つの通信装置が送信用と受信用に１つずつ、合計２つのコネクションを確立し、当該通信装置内でトランスポート層の通信プロトコルを処理するトランスポート層エンティティとして、当該通信装置から情報を送信するときに機能する送信用ポートと受信するときに機能する受信用ポートを用いるコネクション型の通信方法において、
前記２つのコネクションうちの１つしか確立されない場合、所定のタイムアウト時間が経過する前であっても、その１つのコネクションに送信用ポートと受信用ポートを対応付けて、当該コネクションを送信用および受信用に割り当てることを特徴とする通信方法。
【請求項３】
通信時に、１つの通信装置が送信用と受信用に１つずつ、合計２つのコネクションを確立し、当該通信装置内でトランスポート層の通信プロトコルを処理するトランスポート層エンティティとして、当該通信装置から情報を送信するときに機能する送信用ポートと受信するときに機能する受信用ポートを用いるコネクション型の通信プログラムにおいて、コンピュータに、
前記２つのコネクションうちの１つしか確立されない場合、所定のタイムアウト時間が経過する前であっても、その１つのコネクションに送信用ポートと受信用ポートを対応付けて、当該コネクションを送信用および受信用に割り当てるコネクション制御機能を実現させることを特徴とする通信プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２００６−２６１９５８（Ｐ２００６−２６１９５８Ａ）
【公開日】平成１８年９月２８日（２００６．９．２８）
【国際特許分類】
【出願番号】特願２００５−７５４５８（Ｐ２００５−７５４５８）
【出願日】平成１７年３月１６日（２００５．３．１６）
【出願人】（５０３３３４１５０）株式会社沖テクノクリエーション (52)
【Ｆターム（参考）】
【公開日】平成１８年９月２８日（２００６．９．２８）
【国際特許分類】
【出願日】平成１７年３月１６日（２００５．３．１６）
【出願人】（５０３３３４１５０）株式会社沖テクノクリエーション (52)
【Ｆターム（参考）】
[ Back to top ]