(57)【要約】【課題】  非リアルタイム通信とリアルタイム通信の両方を行うことが可能な環境下で、リアルタイム通信によるデータ通信に遅れが生じないようにするリアルタイム通信装置を提供する。【解決手段】  第１データ処理部２、バッファ部１、第２データ処理部３を備えており、バッファ部１は、実時間データを受け入れる第１バッファ１１と、非実時間データを受け入れる第２バッファ１２とを備え、第１データ処理部２及び第２データ処理部３は、データが実時間データであるか非実時間データであるかを検出する手段と、検出されたデータのタイプに応じて、データを第１バッファ又は第２バッファに振り分け処理を行う手段と、バッファ部から受け入れたデータを送出するに際し、実時間データを非実時間データよりも優先して送出する処理を行う手段とを備えている。【選択図】    図１
2005198023.tif 000002
【特許請求の範囲】
【請求項１】
第１データ処理部と、バッファ部と、第２データ処理部とを有し、データ受信時は、第１データ処理部、バッファ部、第２データ処理部の順番にデータが流れ、データ送信時は、第２データ処理部、バッファ部、第１データ処理部の順番にデータが流れるように構成されたリアルタイム通信装置であって、
バッファ部は、
リアルタイム通信用の実時間データを受け入れる第１バッファと、
非リアルタイム通信用の非実時間データを受け入れる第２バッファとを備え、
第１データ処理部及び第２データ処理部は、
データが実時間データであるか非実時間データであるかを検出する手段と、
検出されたデータのタイプに応じて、データを第１バッファ又は第２バッファのいずれかに振り分け処理を行う手段と、
バッファ部から受け入れたデータを送出するに際して、実時間データを非実時間データよりも優先して送出する処理を行う手段と、を備えていることを特徴とするリアルタイム通信装置。
【請求項２】
リアルタイム通信用データのフレームに、前記データのタイプを表わすフィールドが設けられていることを特徴とする請求項１に記載のリアルタイム通信装置。
【請求項３】
請求項１又は２に記載のリアルタイム通信装置を用いて行われるデータ送受信処理プログラムであって、
アプリケーションが送信システムコールでカーネルを呼び出す処理と、
呼び出されたカーネルが割込ハンドラを呼び出す処理と、
この割込ハンドラがバッファ部からフレームを取り出す処理と、
この処理後、カーネルが送信ルーチンを呼び出す処理とをコンピュータに実行させることを特徴とするデータ送受信処理プログラム。
【請求項４】
請求項１又は２に記載のリアルタイム通信装置を用いて行われるデータ送受信処理プログラムであって、
アプリケーションが受信システムコールでカーネルでカーネルを呼び出す処理と、
呼び出されたカーネルが割込ハンドラを呼び出す処理と、
この割込ハンドラがバッファ部からフレームを取り出す処理と、
この処理後、カーネルが受信ルーチンを呼び出す処理とをコンピュータに実行させることを特徴とするデータ送受信処理プログラム。
【請求項５】
データ送信時において、
アプリケーションが送信システムコールでカーネルを呼び出す処理と、
呼び出されたカーネルが割込ハンドラを呼び出す処理と、
この割込ハンドラがバッファ部からフレームを取り出す処理と、
この処理後、カーネルが送信ルーチンを呼び出す処理と、
データ受信時において、
アプリケーションが受信システムコールでカーネルでカーネルを呼び出す処理と、
呼び出されたカーネルが割込ハンドラを呼び出す処理と、
この割込ハンドラがバッファ部からフレームを取り出す処理と、
この処理後、カーネルが受信ルーチンを呼び出す処理とをコンピュータに実行させることを特徴とするデータ送受信処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、第１データ処理部と、バッファ部と、第２データ処理部とを有し、データ受信時は、第１データ処理部、バッファ部、第２データ処理部の順番にデータが流れ、データ送信時は、第１データ処理部、バッファ部、第２データ処理部の順番にデータが流れるように構成されたリアルタイム通信装置及びこの通信装置において好適に用いられるデータ送受信処理プログラムに関するものである。
【背景技術】
【０００２】
インターネットにおいて行われている通信方式は、コネクション型と呼ばれるものであり、通信を行う際に通信セッションを確立してからデータのやり取りを行うようにしている。このようなコネクション型の通信は、通信相手の応答を待ってから通信を行う同期型であり、非リアルタイム通信と称する。非リアルタイム通信は、通信時間の予測を行うことが難しい。
【０００３】
一方、リアルタイム通信と呼ばれるものがあり、この通信方式では、即時に通信処理を行い、要求された制限時間内にデータ通信を完了する。
【０００４】
このように、リアルタイム通信と非リアルタイム通信とがあり、既存のネットワーク環境であるインターネットで用いられているイーサネットTMを使用してリアルタイム通信を行おうとした場合、次のような問題がある。
【０００５】
図６は、従来技術に係る通信装置の構成を示す概念図である。バッファ部１００は、ＦＩＦＯバッファ（先入れ先出しバッファ）により構成される。バッファ部１００にデータが滞留していなければ、実時間データ（リアルタイム通信で処理されるデータ）は遅延なく処理されるので、要求された制限時間内にデータ通信を完了することができる。しかしながら、リアルタイム通信と非リアルタイム通信とを同じタイミングで行っている場合には、次のような問題が生じる。
【０００６】
まず、データ受信時における動作を図６（ａ）により説明する。第１データ処理部１０１は、実時間データ（リアルタイム通信で処理されるデータ）と非実時間データ（非リアルタイム通信で処理されるデータ）とが混在した状態で受け取っている。実時間データは「ａ」「ｂ」で示され、非実時間データは「１」「２」で示されている。これらのデータは、一旦バッファ部１００に入れられた後、第２データ処理部１０２により上位にデータが出力される。この場合、実時間データは、これよりも先行している非実時間データが存在するために、実時間データの処理が遅れてしまうことになる。
【０００７】
次に、データ受信時における動作を図６（ｂ）により説明する。実時間データは「ｃ」「ｄ」で示され、非実時間データは「３」「４」で示される。データの流れは、図６（ａ）の場合とは逆になるが、実時間データは先行する非実時間データのために、通信ラインに遅れて出力されることはデータ送信時の場合と同じである。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明は上記実情に鑑みてなされたものであり、その課題は、非リアルタイム通信とリアルタイム通信の両方を行うことが可能な環境下で、リアルタイム通信によるデータ通信に遅れが生じないようにすることができるリアルタイム通信装置およびこの通信装置に好適に用いられるデータ送受信処理プログラムを提供することである。 
【課題を解決するための手段】
【０００９】
＜リアルタイム通信装置＞
上記課題を解決するため本発明に係るリアルタイム通信装置は、
第１データ処理部と、バッファ部と、第２データ処理部とを有し、データ受信時は、第１データ処理部、バッファ部、第２データ処理部の順番にデータが流れ、データ送信時は、第２データ処理部、バッファ部、第１データ処理部の順番にデータが流れるように構成されたリアルタイム通信装置であって、
バッファ部は、
リアルタイム通信用の実時間データを受け入れる第１バッファと、
非リアルタイム通信用の非実時間データを受け入れる第２バッファとを備え、
第１データ処理部及び第２データ処理部は、
データが実時間データであるか非実時間データであるかを検出する手段と、
検出されたデータのタイプに応じて、データを第１バッファ又は第２バッファのいずれかに振り分け処理を行う手段と、
バッファ部から受け入れたデータを送出するに際して、実時間データを非実時間データよりも優先して送出する処理を行う手段と、を備えていることを特徴とするものである。
【００１０】
この構成によるリアルタイム通信装置の作用・効果は、以下の通りである。この通信装置は、バッファ部として第１バッファと第２バッファとを備えており、第１バッファはリアルタイム通信用の実時間データを受け入れることができ、第２バッファは非リアルタイム通信用の非実時間データを受け入れることができる。そして、第１データ処理部と第２データ処理部は、データのタイプに応じて次のような処理を行う。
【００１１】
まず、データ受信時は、第１データ処理部は、受信しようとするデータが実時間データか非実時間データかを検出する。実時間データである場合は、これを第１バッファに入れ、非実時間データである場合には、これを第２バッファに入れる。第２データ処理部は、実時間データを非実時間データに対して優先的に送出する処理を行う。これにより、実時間データの方が先に送り出される。データ送信時は、上記と逆であり、第２データ処理部は、受け入れたデータが実時間データか非実時間データかを検出し、この検出結果に基づいて、データを第１バッファ又は第２バッファに入れる。そして、第１データ処理部は、実時間データを非実時間データに対して優先的に送出する処理を行う。これにより、実時間データの方が先に送り出される。すなわち、 先行する非実時間データにより実時間データの処理が遅れることがないように、実時間データの処理を行うことができる。その結果、非リアルタイム通信とリアルタイム通信の両方を行うことが可能な環境下で、リアルタイム通信によるデータ通信に遅れが生じないようにすることができるリアルタイム通信装置を提供することができる。
【００１２】
本発明に係るリアルタイム通信用データのフレームに、前記データのタイプを表わすフィールドが設けられていることが好ましい。
【００１３】
第１データ処理部と第２データ処理部は、このデータのタイプに基づいて、実時間データか非実時間データかを検出することができる。
【００１４】
＜データ送受信処理プログラム＞
本発明に係るデータ送受信処理プログラムは、本発明に係るリアルタイム通信装置に好適であって、
アプリケーションが送信システムコールでカーネルを呼び出す処理と、
呼び出されたカーネルが割込ハンドラを呼び出す処理と、
この割込ハンドラがバッファ部からフレームを取り出す処理と、
この処理後、カーネルが送信ルーチンを呼び出す処理とをコンピュータに実行させることを特徴とするものである。
【００１５】
従来技術に係るデータ送受信処理は、データ送信時において、アプリケーションが送信システムコールでカーネルを呼出し、カーネルがデバイスドライバの送信ルーチンを呼び出すようにしていた。そして、データをバッファに入れようとするときに、バッファがフルの状態であれば、割込ハンドラを呼び出し、バッファからデータフレームを取り出すように処理を行っていた。しかしながら、このような処理手順では、アプリケーションによる送信システムコールの呼び出しが、割込ハンドラの実行周期よりも短かった場合、アプリケーションプログラムの実行周期が長くなってしまうという問題がある。
【００１６】
すなわち、 割込ハンドラが呼び出された場合は、割込ハンドラの実行が行われるまで、バッファにデータを入れることができない。従って、その分データの送信が遅らされることになるという問題がある。
【００１７】
これに対して、本発明に係るデータ送受信処理は、送信システムコールでカーネルを呼び出し、カーネルが割込ハンドラを呼び出す。そして、この割込ハンドラがバッファ部からフレームを取り出すようにしている。このフレームを取り出した後、カーネルが送信ルーチンを呼び出す。このとき、バッファ部からは既にフレームが取り出されているので、バッファ部がフルになっていることがない。従って、送信ルーチンによりデータを確実にバッファ部に入れることができる。その結果、データの送信が遅らされることはない。
【００１８】
本発明に係るデータ送受信処理プログラムは、本発明に係るリアルタイム通信装置に好適であって、
アプリケーションが受信システムコールでカーネルでカーネルを呼び出す処理と、
呼び出されたカーネルが割込ハンドラを呼び出す処理と、
この割込ハンドラがバッファ部から受信済みのフレームを取り出す処理と、
この処理後、カーネルが受信ルーチンを呼び出す処理とをコンピュータに実行させることを特徴とするものである。
【００１９】
従来技術に係るデータ送受信処理は、データ受信時において、アプリケーションが受信システムコールでカーネルを呼出し、カーネルがデバイスドライバの受信ルーチンを呼び出すようにしている。そして、フレームをバッファから受信済みの状態でなければ、割込ハンドラを呼び出し、バッファからデータフレームを取り出すように処理を行っていた。しかしながら、このような処理手順では、先ほどのデータ送信時と同様に、アプリケーションプログラムの実行周期が長くなってしまうという問題がある。
【００２０】
これに対して、本発明に係るデータ送受信処理は、送信システムコールでカーネルを呼び出し、カーネルが割込ハンドラを呼び出す。そして、この割込ハンドラがバッファ部からフレームを取り出すようにしている。このフレームを取り出した後、カーネルが受信ルーチンを呼び出す。このとき、バッファ部からは既に最上位のフレームが取り出されているので、バッファ部がフルになっていることがない。従って、受信ルーチンによりデータを確実にバッファ部に入れることができる。その結果、データの受信が遅らされることはない。
【００２１】
本発明に係るデータ送受信処理プログラムは、リアルタイム通信に好適であるが、非リアルタイム通信の場合にも適用できるものである。
【発明を実施するための最良の形態】
【００２２】
本発明に係るリアルタイム通信装置の好適な実施形態を図面を用いて説明する。 図１は、リアルタイム通信装置の構成を示す概念図である。
【００２３】
＜リアルタイム通信装置（ハードウェアの構成）＞
本発明に係るリアルタイム通信装置は、リアルタイム通信のみならず非リアルタイム通信にも用いることができる装置である。特に、インターネットで使用されているイーサネット環境を使用してリアルタイム通信を行おうとするものである。既に述べたように、インターネットはコネクション型の通信形式を採用しているため、希望する時間内に通信を完了することができない。すなわち、 インターネット環境における通信は非リアルタイム通信であり、このシステムを利用してリアルタイム通信を行おうとした場合に、通信処理時間に遅れが生じないようにする仕組みが要求される。
【００２４】
図１において、（ａ）はデータ受信時の動作を示し、（ｂ）はデータ送信時の動作を示す。バッファ部１として、第１ＦＩＦＯ（先入れ先出し）バッファ１１と第２ＦＩＦＯバッファ１２とが設けられている。第１ＦＩＦＯバッファ１１は、実時間データ（リアルタイム通信を行うときのデータ）が出し入れされるバッファであり、第２ＦＩＦＯバッファ１２は、非実時間データ（非リアルタイム通信を行うときのデータ）が出し入れされるバッファである。実時間データのフレームは「ａ」「ｂ」「ｃ」「ｄ」で示され、非実時間データのフレームは「１」「２」「３」「４」で示される。図１は、リアルタイム通信と非リアルタイム通信が同じタイミングで行われている状態を示している。もちろん、実際に行われる通信形態がこれに限定されるものではなく、リアルタイム通信のみが行われている状態、非リアルタイム通信のみが行われている状態も当然にありうるものである。
【００２５】
まず、データ受信時における動作を図１（ａ）により説明する。第１データ処理部２は、受信しようとするデータが実時間データであるか非実時間データであるかを検出する機能（手段）を有している。そのためのデータフレームの構成を図２に示す。
【００２６】
図２は、フレームにおける各フィールド構成を示している。フィールドは「プリアンブル」「スタートフレームデリミタ」「送信先アドレス」「送信元アドレス」「タイプ」「データ領域」「フレームチェック」から構成されている。なお、このフィールド構成は、一例を示すものであり、これに限定されるものではない。上記のうち「タイプ」と名づけられたフィールドに基づいて、実時間データであるか非実時間データであるかを判別することができる。第１データ処理部２は、データタイプが実時間データであれば、これを第１バッファ１１に入れる。データタイプが非実時間データであれば、これを第２バッファ１２に入れる。このように、第１データ処理部２の機能に基づいて、データをいずれかに振り分けることができる。
【００２７】
第２データ処理部３は、バッファ部１から受け入れたデータのうち、実時間データを優先的に上位（アプリケーション) に上げる機能（手段）を備えている。すなわち、 図１（ａ）の例では、実時間データと非実時間データの各フレームが混在した順番「１」「ｂ」「２」「 ａ」 で入力されてくるが、上位にデータが出力されるときは、「ｂ」「ａ」「１」「２」の順番で送出される。その結果、リアルタイム通信の通信時間が、非実時間データの処理時間に影響して遅れることがない。
【００２８】
次に、データ送信時における動作を図１（ｂ）により説明する。第２データ処理部３は、上位からデータ送信の要求がされた場合、送信しようとするデータが実時間データであるか非実時間データであるかを検出する機能（手段）を有している。
【００２９】
先ほどと同様に、第２データ処理部３は、データタイプが実時間データであれば、これを第１バッファ１１に入れる。データタイプが非実時間データであれば、これを第２バッファ１２に入れる。このように、第２データ処理部３の機能に基づいて、データをいずれかに振り分けることができる。
【００３０】
第１データ処理部２は、バッファ部１から受け入れたデータのうち、実時間データを優先的に通信ラインに出力する機能（手段）を備えている。すなわち、 図１（ｂ）の例では、実時間データと非実時間データの各フレームが混在した順番「４」「３」「ｃ」「 ｄ」 で入力されてくるが、通信線にデータが出力されるときは、「ｃ」「ｄ」「４」「３」の順番で送出される。その結果、リアルタイム通信の通信時間が、非実時間データの処理時間に影響して遅れることがない。
【００３１】
＜データ送受信処理プログラム＞
次に、データ送受信を速く行うことができるソフトウェアの処理について説明する。図４は、従来技術に係るデータ送受信処理の手順を示すフローチャートである。（ａ）はデータ送信時、（ｂ）はデータ受信時の手順を示す。
【００３２】
＜従来技術における処理手順＞
まず、送信時の処理手順を説明する。この例は、ＡＲＴ−Ｌｉｎｕｘ（リナックス）でのイーサネットによる送信手順である。データを送信しようとするとき、アプリケーション・プログラムが送信システムコールでカーネルを呼び出す（＃２１）。システムコールとは、ＯＳ（オペレーティングシステム）が備えている機能を呼び出して使用することを指し、ここではデータ送信を行うためのシステムコールを行う。カーネルとはＯＳの最も基本的な部分を指している。
【００３３】
次に、呼び出されたカーネルがイーサネット・デバイスドライバの送信ルーチンを呼び出す（＃２２）。データの送信を行うためには、ＦＩＦＯバッファに一旦データ（フレーム）を入れる必要があるので、ＦＩＦＯバッファがフルに状態にあるか否かを判断する（＃２３）。ＦＩＦＯバッファがフルでなければ、フレームを入れることができるので、ステップ＃２５に移行できるが、フルである場合には、割込ハンドラ（割り込みが起こった時に実行される小さなプログラムコードのことをいう）による割込み処理が終了するまで待つ（＃２４）。この割込ハンドラにより、一番先頭にあるフレームをＦＩＦＯバッファから取り出し、ＦＩＦＯバッファに空きを生成させる。これにより、イーサネット・デバイスドライバは、ＦＩＦＯバッファにフレームを入れることができる（＃２５）。ついで、イーサネット・コントロールデバイスに送信命令を出すと、このコントロールデバイスが、先ほどＦＩＦＯバッファから取り出したフレームを通信ラインに送出する（＃２６）。
【００３４】
次に、データ受信時の処理手順を説明する。同じようにアプリケーション・プログラムが受信システムコールでカーネルを呼び出す（＃３１）。呼び出されたカーネルが、デバイスドライバの受信ルーチンを呼び出す（＃３２）。フレームが既に受信済みの状態であれば（＃３３）、ステップ＃３５に移行するが、そうでなければ、割込ハンドラによる割込み処理が終了するのを待つ（＃３４）。すなわち、 割込ハンドラによりＦＩＦＯバッファからフレームを取り出す。これにより、ＦＩＦＯバッファに空きが生じる。このフレームは、データ処理部により、上位のアプリケーションに対して出力されることになる（＃３５）。
【００３５】
このような処理手順の場合、次のような問題が生じる。すなわち、 ＡＲＴ−Ｌｉｎｕｘでは割込ハンドラが周期的に実行されるが、アプリケーション・プログラムによる送信システムコールまたは受信システムコールの呼び出し周期が、割込ハンドラの実行周期よりも短かった場合、アプリケーション・プログラムの実行周期が長くなってしまうという問題が生じる。
【００３６】
すなわち、 データ送信時では、割込ハンドラによりＦＩＦＯバッファからのフレームの取り出しが実行されないと、ＦＩＦＯバッファにフレームが残ってしまうため、オーバーフローが生じる。従って、ＦＩＦＯバッファに新たにデータフレームを入れることができないので、ＦＩＦＯバッファに空きができる状態になるまで、アプリケーションの実行が中断される。その結果、アプリケーション・プログラムの実行周期が、割込ハンドラの実行周期まで長くなってしまうことになる。これにより、データ送信に要する処理時間も遅れてしまうことになる。
【００３７】
一方、データ受信時では、割込ハンドラによりＦＩＦＯバッファからフレームの取り出しが行われないと、上位にフレームが送出されず、ＦＩＦＯバッファにデータを入れることもできない。従って、その後の処理が遅らされてしまい、やはりデータ受信に要する処理時間が遅れてしまうことになる。
【００３８】
＜本発明における処理手順＞
次に、本発明における処理手順を図３のフローチャートにより説明する。この例も、先ほどと同様に、ＡＲＴ−Ｌｉｎｕｘ（リナックス）でのイーサネットによる送受信手順を示す。ただし、本発明は、これに限定されるものではない。（ａ）が送信時のフローチャート、（ｂ）が受信時のフローチャートを示す。
【００３９】
まず、送信時の処理手順を説明する。アプリケーション・プログラムが送信システムコールでカーネルを呼び出す（＃１）。このカーネルが割込ハンドラを呼び出す（＃２）。この割込ハンドラにより、ＦＩＦＯバッファからフレームを取り出してリターンする。これにより、ＦＩＦＯバッファに空きが生じる。次に、カーネルがイーサネット・デバイスドライバの送信ルーチンを呼び出す（＃３）。次に、デバイスドライバが新たなフレームをＦＩＦＯバッファに入れる（＃５）。
【００４０】
ちなみに、ステップ＃４においてＦＩＦＯバッファがフルか否かの判断処理があるが、ステップ＃２で割込ハンドラを既に実行済み（フレームの取り出し完了済み）であるから、ＦＩＦＯバッファがフルになっていることはない（＃８）。よって、直ちにＦＩＦＯバッファへの新たなフレームの挿入がなされることになる。これは、図１（ｂ）では、第2 データ処理部３の機能として示されている。次に、イーサネット・コントロールデバイスに送信指令を出し、シリアル通信ラインにフレームが送出される（＃６）。図１（ｂ）では、第1 データ処理部２の機能として示されている。
【００４１】
次に、受信時の処理手順を説明する。アプリケーション・プログラムが受信システムコールでカーネルを呼び出す（＃１１）。このカーネルが割込ハンドラを呼び出す（＃１２）。割込ハンドラがＦＩＦＯバッファからフレームを取り出してリターンする。これにより、ＦＩＦＯバッファに空きが生じる。次に、カーネルがイーサネット・デバイスドライバの受信ルーチンを呼び出す（＃１３）。次に、ＦＩＦＯバッファに受信した新たなフレームを入れる。これは図１（ａ）では第１データ処理部２の機能として示されている。次に、ＦＩＦＯバッファから取り出したフレームを上位に送出する（＃１５）。これは、第２データ処理部３の機能として示されている。
【００４２】
ちなみに、ステップ＃１４においてはＮｏと判断されることがないのは、先ほどと同様である。 従って、ステップ＃４やステップ＃１４についての判断処理は省略することが可能である。ただし、既存のソフトウェアの互換性を保持するために、ソースコードを変更しない方が好ましいので、本発明の構成としては、ステップ＃４やステップ＃１４についての判断処理を残しておくことが好ましい。
【００４３】
＜タイミングチャート＞
図５は、アプリケーションの実行周期と割込ハンドラの実行周期との関係を示すタイミングチャートである。図５（ａ）が従来技術を示し（ｂ）が本発明を示す。なお送信時も受信時も同じ態様になる。アプリケーションの実行をＡで示し、割込ハンドラの実行をＩで示している。
【００４４】
従来技術では、アプリケーションの実行周期は５００μｓ、割込ハンドラの実行周期が１ｍｓとなっている。すなわち、 割込ハンドラの実行周期の方が長い。この場合、割込ハンドラの実行周期に合わせて、アプリケーションの実行に無駄な待ち時間が生じていることがわかる。すなわち、 実際にはアプリケーションの実行周期５００μｓを実現することができない。従って、データ処理時間も長くなることになり、その結果、データの送受信に要する時間も長くなることになる。
【００４５】
一方、本発明による場合、割込ハンドラの実行周期もアプリケーションの実行周期も共に５００μｓとしている。従って、図５（ｂ）に示すように無駄な待ち時間が発生しない。アプリケーションの実行周期５００μｓを確実に実現することができる。
【００４６】
なお、アプリケーションによるプログラムの実行としては、例えば、システムコールによりカーネルを呼び出す処理のほかに、受信したデータの加工や、送信するデータの作成等の種々のものが含まれる。
【図面の簡単な説明】
【００４７】
【図１】本発明に係るリアルタイム通信装置の構成を示す概念図
【図２】データフレームのフィールド構成を示す図
【図３】本発明に係るデータ送受信処理の手順を示すフローチャート
【図４】従来技術に係るデータ送受信処理の手順を示すフローチャート
【図５】プログラム実行態様を示す図
【図６】従来技術に係る通信装置の構成を示す概念図
【符号の説明】
【００４８】
１      バッファ部
２      第１データ処理部
３      第２データ処理部
１１    第１バッファ
１２    第２バッファ
【図１】
2005198023.tif 000003
【図２】
2005198023.tif 000004
【図３】
2005198023.tif 000005
【図４】
2005198023.tif 000006
【図５】
2005198023.tif 000007
【図６】
2005198023.tif 000008