(57)【要約】【課題】ＦＴＰでファイルを送信した送信元装置が送信先装置に届いたファイルに欠損があるか否かを認識できるようにする。【解決手段】送信元装置（１０）が、ＦＴＰ（File Transfer Protocol）に従ってファイルを送信する送信手段（３５）と、該ファイルの送信先装置（５０）に届いたファイルのファイル情報を前記送信先装置に問い合わせる問い合わせ手段（３４）と、送信手段によりファイルを送信させ、その後に、該ファイルのファイル情報の問合せを問合せ手段に行わせ、該問い合わせに対して送信先装置から返答されたファイル情報中のファイルサイズと、送信されたファイルのファイルサイズとに基づいて、送信先装置に届いたファイルに欠損があるか否かを判断する判断手段（３３）とを備える。【選択図】図１
2007272490.tif 000002
【特許請求の範囲】
【請求項１】
ＦＴＰ（File Transfer Protocol）に従ってファイルを送信する送信手段と、
該ファイルの送信先装置に届いたファイルのファイル情報を前記送信先装置に問い合わせる問い合わせ手段と、
前記送信手段によりファイルを送信させ、その後に、該ファイルのファイル情報の問合せを前記問合せ手段に行わせ、該問い合わせに対して前記送信先装置から返答されたファイル情報中のファイルサイズと、前記送信されたファイルのファイルサイズとに基づいて、前記送信先装置に届いたファイルに欠損があるか否かを判断する判断手段と
を備える送信元装置。
【請求項２】
送信されるファイルに含まれている特殊コードの数をカウントする特殊コードカウント手段と、
ＯＳ（Operating System）種類毎の第一のファイルサイズ変更規則を記憶した第一の記憶手段と
を更に備え、
前記特殊コードとは、アスキーモードでのファイル送信において、前記送信先装置でのコードサイズが、前記送信元装置でのコードサイズに比して増加或いは減少され得るコード、及び／又は、前記送信先装置において除去或いは付加され得るコードであり、
前記判断手段は、ファイルがアスキーモードで送信された場合、該ファイルのファイルサイズと、特殊コードのカウント値と、前記送信先装置から返答されたファイル情報中のファイルサイズと、前記送信先装置に搭載されているＯＳ種類と、該ＯＳ種類に対応する第一のファイルサイズ変更規則とに基づいて、前記送信先装置に届いたファイルに欠損があるか否かを判断する、
請求項１記載の送信元装置。
【請求項３】
ＯＳ種類毎の第二のファイルサイズ変更規則を記憶した第二の記憶手段と、
前記送信先装置のＯＳ種類を特定するＯＳ特定手段と
を更に備え、
前記ＯＳ特定手段は、前記送信手段によりファイルをアスキーモードで送信し、該ファイルのファイル情報を前記問い合わせ手段により前記送信先装置に問い合わせ、該問い合わせにより返答されたファイル情報中のファイルサイズと各第二のファイルサイズ変更規則とを基に、該当するＯＳ種類を、前記記憶手段から特定し、
前記判断手段により基にされるＯＳ種類は、前記ＯＳ特定手段により特定されたＯＳ種類である、
請求項２記載の送信元装置。
【請求項４】
ファイルがバイナリモードで送信される場合、及び、ファイルがアスキーモードで送信されるのであっても前記送信先装置のＯＳ種類が特定済みである場合には、前記ＯＳ特定手段を実行せず、ファイルがアスキーモードで送信され且つ前記送信先装置のＯＳ種類が未特定の場合に、前記ＯＳ特定手段を実行する、
請求項３記載の送信元装置。
【請求項５】
前記第一又は第二のファイルサイズ変更規則は、前記特殊コードの種類に応じたサイズ増減値から構成されている、
請求項２又は３記載の送信元装置。
【請求項６】
ＯＳ種類の特定のために送信されるファイルは、ＯＳ種類の特定のために用意された検査用ファイルであり、該検査用ファイルは、少なくとも前記特殊コードを含んでいる、
請求項３記載の送信元装置。
【請求項７】
前記ＯＳ特定手段が、ファイルの送信とファイル情報の問い合わせとをＭ回（Ｍ≧２の整数）繰返し、同じファイルサイズがＮ回（Ｎ≦Ｍ、且つ、Ｎ≧２の整数）得られた場合に、該同じファイルサイズを基に、該当するＯＳ種類を前記第二の記憶手段から特定する、
請求項３記載の送信元装置。
【請求項８】
前記送信先装置との間のセッションを接続したり切断したりするセッション接続／切断手段を更に備え、ファイルを送信した後に、前記セッション接続／切断手段により、該ファイルの送信の際のセッションを切断し、その後、前記送信先装置と新たにセッションを接続して、該ファイルのファイル情報を問い合わせる、
請求項１乃至７のうちのいずれか１項に記載の送信元装置。
【請求項９】
ＦＴＰに従ってファイルを送信する送信手段にファイルを送信先装置に送信させるステップと、
該ファイルの送信後に、ファイル情報を前記送信先装置に問合せる問合せ手段に、前記送信させたファイルのファイル情報の問合せを行わせるステップと、
前記問い合わせに対して前記送信先装置から返答されたファイル情報中のファイルサイズと、前記送信されたファイルのファイルサイズとに基づいて、前記送信先装置に届いたファイルに欠損があるか否かを判断するステップと
をコンピュータに実行させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＦＴＰ（File Transfer Protocol）でファイルを送信する送信元装置に関する。
【背景技術】
【０００２】
従来、ファイルを送信する送信元装置（送信側サーバ）と、送信元装置からファイルを受信しその受信したファイルのエラーチェック（例えば、データファイルの抜けが存在するか否かの確認）を行う機能を有する送信先装置（受信側サーバ）とを備えたファイル転送システムが知られている（例えば、特許文献１参照）。
【０００３】
このファイル転送システムでは、送信元装置が、所定のデータを格納したデータファイル、そのデータファイルのバイト数を示すバイトファイルなどを送信先装置に送信し、送信先装置が、それらのファイルを受信し、受信したデータファイルのバイト数と、バイトファイルが示すデータファイルのバイト数とを比較することで、受信したファイルのエラーチェックを行う。
【０００４】
【特許文献１】特開２００５−２７６１２９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
通信ネットワークが不安定な状態になっている等の原因により、送信したファイルの一部しか送信先装置に届かない、つまり、送信先装置に届いたファイル（具体的には、例えば、指定のディレクトリに格納されたファイル）に欠損がある場合がある。上述した特許文献１に開示の技術によれば、送信先装置が、受信したデータファイルとバイトファイルから、届いたデータファイルに欠損があるか否かを判断することができる。
【０００６】
それを、送信元装置で認識させたいというニーズが有り得る。しかし、特にＦＴＰ（File Transfer Protocol）に従うファイル送信では、ＦＴＰの制約上、送信元装置で、送信先装置に届いたファイルに欠損があるか否かを認識することはできない。それはおろか、送信先装置にファイルが届いたか否かすらも、送信元装置で認識できるようにはなっていない。具体的には、ＦＴＰでファイルを送信する場合、送信元装置において、アプリケーションプログラムが、ＦＴＰでファイルを送信するファイル送信プログラムを実行させることで、所望のファイルをＦＴＰで送信させられるが、その後にそのファイル送信プログラムからアプリケーションプログラムに返ってくる応答には、ファイルを送信したことの報告はあるが、ファイルが送信先装置に届いたか否かの報告はない。
【０００７】
従って、本発明の目的は、ＦＴＰでファイルを送信した送信元装置が送信先装置に届いたファイルに欠損があるか否かを認識できるようにすることにある。
【０００８】
本発明の他の目的は、後の説明から明らかになるであろう。
【課題を解決するための手段】
【０００９】
本発明に従う送信元装置は、ＦＴＰに従ってファイルを送信する送信手段と、該ファイルの送信先装置に届いたファイルのファイル情報を前記送信先装置に問い合わせる問い合わせ手段と、判断手段とを備える。判断手段は、前記送信手段によりファイルを送信させ、その後に、該ファイルのファイル情報の問合せを前記問合せ手段に行わせ、該問い合わせに対して前記送信先装置から返答されたファイル情報中のファイルサイズと、前記送信されたファイルのファイルサイズとに基づいて、前記送信先装置に届いたファイルに欠損があるか否かを判断する。
【００１０】
本発明によれば、ＦＴＰでファイルを送信した送信元装置が送信先装置に届いたファイルに欠損があるか否かを認識できるようにすることができる。
【００１１】
なお、ファイル情報の問合せを前記問合せ手段に行わせることは、前記送信手段によりファイルを送信させたことを契機として、自動的に行うことができる。或いは、前記送信手段が、ファイルを送信した場合に、ファイルを送信したことを前記判断手段に報告するようになっているならば、ファイル情報の問合せを前記問合せ手段に行わせることは、その報告を受けたことを契機として、自動的に行うことができる。これにより、送信先装置に届いたファイルに欠損があるか否かを迅速に認識することができる。
【００１２】
ＦＴＰでの転送モードには、バイナリモードとアスキーモードとがあるが、バイナリモードでのファイル送信に本発明を適用した場合、例えば、送信したファイルのファイルサイズと、返答されたファイル情報中のファイルサイズとを比較し、一致しているか否かにより、送信先装置に届いたファイルに欠損があるか否かを判断することができる。バイナリモードでは、改行コードなどの特殊コードが変更されることなくファイルが送信され、故に、ファイルが欠損無く送信先装置に届けば、送信元装置と送信先装置でファイルサイズに変更が生じないためである。
【００１３】
ただし、アスキーモードでのファイル送信では、単にこの方法を適用したのでは、送信先装置に届いたファイルに欠損があるか否かを正確に判断することはできない。アスキーモードでは、バイナリモードと違って、改行コードなどの特殊コードが変更されて送信されるため、ファイルが欠損無く送信先装置に届いても、送信するファイルのファイルサイズと、送信先装置に届いたファイルのファイルサイズが異なるためである。これは、通常、送信元装置と送信先装置のＯＳ種類が同じでない限り生じる。具体的には、アスキーモードでは、送信手段によりファイルが送信される場合、送信先装置のＯＳ（Operating System）種類に応じて、特殊コードのコードサイズが、送信元装置でのコードサイズに比して増加或いは減少したり、特殊コードそれ自体が除去或いは付加されたりされ得る。このため、判断手段が認識できる、送信されるファイルのファイルサイズと、送信先装置に届いたファイルのファイルサイズとには、違いが生じる。
【００１４】
そこで、本発明の第一の実施態様では、送信されるファイルに含まれている特殊コードの数をカウントする特殊コードカウント手段と、ＯＳ種類毎の第一のファイルサイズ変更規則を記憶した第一の記憶手段とが更に備えられる。前記判断手段は、ファイルがアスキーモードで送信された場合、該ファイルのファイルサイズと、特殊コードのカウント値と、前記送信先装置から返答されたファイル情報中のファイルサイズと、前記送信先装置に搭載されているＯＳ種類と、該ＯＳ種類に対応する第一のファイルサイズ変更規則とに基づいて、前記送信先装置に届いたファイルに欠損があるか否かを判断する。
【００１５】
これにより、アスキーモードでファイル送信された場合であっても、送信先装置に届いたファイルに欠損があるか否かを正確に判断することができる。
【００１６】
第二の実施態様では、ＯＳ種類毎の第二のファイルサイズ変更規則を記憶した第二の記憶手段と、前記送信先装置のＯＳ種類を特定するＯＳ特定手段とが更に備えられる。前記ＯＳ特定手段は、前記送信手段によりファイルをＦＴＰに従うアスキーモードで送信し、該ファイルのファイル情報を前記問い合わせ手段により前記送信先装置に問い合わせ、該問い合わせにより返答されたファイル情報中のファイルサイズと各第二のファイルサイズ変更規則とを基に、該当するＯＳ種類を、前記第二の記憶手段から特定する。前記前記判断手段により基にされるＯＳ種類は、前記ＯＳ特定手段により特定されたＯＳ種類である。
【００１７】
この実施態様によれば、送信先装置に搭載されているＯＳの種類をユーザが知らなくても、送信元装置によってそれを特定することができる。なお、第二のファイルサイズ変更規則は、第一のファイルサイズ変更規則であっても良く、故に、第二の記憶手段は、第一の記憶手段であっても良い。別の言い方をすれば、前記判断手段での判断で基にされるファイルサイズ変更規則と同じファイルサイズ変更規則を基に、ＯＳ種類が特定されても良い。これにより、送信元装置での記憶資源の消費量を節約することができる。
【００１８】
第三の実施態様では、前記第二の実施態様において、ファイルがバイナリモードで送信される場合、及び、ファイルがアスキーモードで送信されるのであっても前記送信先装置のＯＳ種類が特定済みである場合には、前記ＯＳ特定手段を実行せず、ファイルがアスキーモードで送信され且つ前記送信先装置のＯＳ種類が未特定の場合に、前記ＯＳ特定手段を実行する。
【００１９】
この実施態様によれば、無用にＯＳ特定手段を実行してしまうことを防止し、以って、送信先装置に届いたファイルに欠損があるか否かを認識することが遅くなってしまわないようにすることができる。
【００２０】
第四の実施態様では、前記第一又は第二の実施態様において、ファイルサイズ変更規則は、前記特殊コードの種類に応じたサイズ増減値から構成されたものとすることができる。特殊コードとは、例えば、改行コード及び終了コードのうちの少なくとも改行コードである。
【００２１】
第五の実施態様では、前記第二の実施態様において、ＯＳ種類の特定のために送信されるファイルは、ＯＳ種類の特定のために用意された検査用ファイルであり、該検査用ファイルは、少なくとも前記特殊コードを含んだものとすることができる。
【００２２】
この実施形態によれば、送信元装置と送信先装置とでＯＳ種類が異なることによりファイルサイズに違いが生じることの原因となる特殊コードが含まれた検査用ファイルが用意され、該検査用ファイルが、ＯＳ種類の特定のために送信されるので、送信先装置のＯＳ種類を確実に特定することが期待できる。
【００２３】
第六の実施態様では、前記第二の実施態様において、前記ＯＳ特定手段が、ファイルの送信とファイルサイズの問い合わせとをＭ回（Ｍ≧２の整数）繰返し、同じファイルサイズがＮ回（Ｎ≦Ｍ、且つ、Ｎ≧２の整数）得られた場合に、該同じファイルサイズを基に、該当するＯＳ種類を前記第二の記憶手段から特定する。
【００２４】
通信ネットワークが不安定である等の原因により、送信されたファイルが、必ずしも送信先装置に欠損無く届くとは限らないし、欠損無く届いたとしても、正しいファイル情報が返答されるとは限らない。このため、一回のファイル送信と一回の問合せによるＯＳ種類特定では、誤ったＯＳ種類が特定されてしまう可能性がある。この第七の実施態様によれば、ファイル送信や問い合わせがＭ回繰り返され、Ｎ回同じファイルサイズが得られた場合に、そのファイルサイズを基にＯＳ種類が特定される。このため、ＯＳ種類の特定の精度を向上することができる。
【００２５】
第七の実施態様では、前記送信先装置との間のセッションを接続したり切断したりするセッション接続／切断手段が更に備えられる。送信元装置は、ファイルを送信した後に、前記セッション接続／切断手段により、該ファイルの送信の際のセッションを切断し、その後、前記送信先装置と新たにセッションを接続して、該ファイルのファイル情報を問い合わせる。
【００２６】
ファイルの送信の際に使用されたセッションと同じセッションでファイル情報を取得した場合、そのセッションが、送信先装置に届いたファイルに欠損が生じた場合のセッションであれば、不具合のあるセッションでファイル情報が取得されたので、その取得されたファイル情報に誤りが生じている場合があり得る。誤ったファイル情報中のファイルサイズを用いても、ファイルに欠損があるか否かを正しく判断することはできない。この第八の実施態様では、ファイル送信の際に使用されるセッションと、ファイル情報問合せの際に使用されるセッションとが独立している。これにより、誤ったファイル情報が取得されてしまう可能性を低減することが期待できる。
【００２７】
上述した各手段は、ハードウェア（例えば回路）、コンピュータプログラム、或いはそれらの組み合わせ（例えば、コンピュータプログラムを読み込んで実行する一又は複数のＣＰＵ）によって実現することもできる。各コンピュータプログラムは、コンピュータマシンに備えられる記憶資源（例えばメモリ）から読み込むことができる。その記憶資源には、ＣＤ−ＲＯＭやＤＶＤ（Digital Versatile Disk）等の記録媒体を介してインストールすることもできるし、インターネットやＬＡＮ等の通信ネットワークを介してダウンロードすることもできる。
【発明を実施するための最良の形態】
【００２８】
以下、本発明の一実施形態に係るファイル転送システムについて図面を参照しながら説明する。
【００２９】
図１は、本発明の一実施形態に係るファイル転送システムの構成を示す。
【００３０】
通信ネットワーク１００に、転送元マシン１０及び転送先マシン５０が、相互通信可能に接続されている。転送元マシン１０も転送先マシン５０も、一種の計算機である。
【００３１】
さて、まず、転送元マシン１０について具体的に説明する。
【００３２】
転送元マシン１０は、ＣＰＵ１１と、Ｉ／Ｏインタフェース部１２と、記憶資源２０とを備えている。ＣＰＵ１１は、記憶資源２０から、コンピュータプログラムを読み込んで実行することができる。Ｉ／Ｏインタフェース部１２は、通信ネットワーク１００に対するＣＰＵ１１のインタフェースとして機能する。
【００３３】
記憶資源２０は、転送元マシン１０に備えられているメモリやハードディスクドライブなどで構成することができる。記憶資源２０は、ＯＳ特定テーブル４０、Windows（登録商標）或いはUNIX（登録商標）などのＯＳ４２、ファイル送信部３５、ファイル情報問合せ部３４、セッション接続／切断部２２及び欠損有無チェック処理部３０を記憶している。
【００３４】
ＯＳ特定テーブル４０には、ＯＳ種類毎のファイルサイズ変更規則が記録されている。ファイルサイズ変更規則とは、例えば、アスキーモードで送信されるファイルのファイルサイズの変更方法或いは変更結果を表す情報であり、少なくとも返答されたファイルサイズからＯＳ種類を特定することができるようになっていれば種々の情報を採用できる。例えば、転送先マシン５０のＯＳ種類によりサイズが増減することになる一特殊コード単位でのファイルサイズの増減値であっても良いし、送信したファイルのファイルサイズに対応した変更後のファイルサイズそれ自体であっても良い。本実施形態では、ファイルサイズ変更規則は、図２Ａに例示するように、一改行コード毎（つまり一行毎）のサイズ増減値と、終了コードの有無に関わるサイズ増減値とから構成される情報である。終了コードの有無に関わるサイズ増減値とは、例えば、終了コードが不要な場合には「０」であり、終了コードが必要な場合には「１」とされる。各種サイズ増減値の単位は、バイトとすることができる。このＯＳ特定テーブル４０に記録される各ファイルサイズ変更規則は、転送元マシン１０のＯＳ４２を基準にした他種のＯＳに対する規則である。
【００３５】
ファイル送信部３５は、ＦＴＰに従ってファイルを送信する。具体的には、ファイル送信部３５は、アスキーモード或いはバイナリモードのうちのいずれかの転送モードでファイルを転送する。アスキーモードとは、転送先マシン５０においてファイルの見え方を保証するための転送モード、具体的には、転送先マシン５０のＯＳ種類に応じて、改行コードなどの特殊コードが変更される転送モードである。このため、アスキーモードは、テキストファイルの送信に利用されることが多い。一方、バイナリモードとは、送信対象のファイルがそのまま転送先マシン５０に送信される転送モード、具体的には、コードの種別に関わらずそのままのコードサイズで送信される転送モードであり、アスキーモードと違って、転送先マシン５０においてファイルの見え方を保証するものではない。
【００３６】
ファイル情報問合せ部３４は、ファイル送信部３５により送信されて転送先マシン５０に届いたファイルのファイル情報を、転送先マシン５０のＦＴＰサービス７０に問い合わせ、そのＦＴＰサービス７０からの返答を受け付ける。ファイル情報とは、ファイルに関する種々の情報要素を含んだ情報であり、情報要素の種類としては、例えば、ファイルサイズ以外に、ファイル名、ファイル更新日時（タイムスタンプ）、アクセス権に関する情報などがある。
【００３７】
セッション接続／切断部２２は、転送先マシン５０とのセッションを接続したり、そのセッションを切断したりする。
【００３８】
上述したファイル送信部３５、ファイル情報問合せ部３４及びセッション接続／切断部２２は、ＦＴＰでサポートされている所定のコマンドを実行するコンピュータプログラムであり、例えば、既存のプログラムであっても良い。
【００３９】
一方、欠損有無チェック処理部３０は、例えば、アプリケーションプログラムの一種であり、本実施形態の特徴の一つである。欠損有無チェック処理部３０は、ファイル送信部３５、ファイル情報問合せ部３４及びセッション接続／切断部２２を制御することにより、バイナリモード及びアスキーモードのどちらの転送モードでファイルが送信された場合であっても、そのファイルが欠損無く転送先マシン５０に届いたか否かを正確に判断することができる。例えば、欠損有無チェック処理部３０は、送信対象のファイルのファイル情報からファイル名及びファイルサイズを抽出し、抽出したファイル名及びファイルサイズを一時的に記憶資源２０に保存させてから、送信対象のファイルの送信を、ファイル送信部３５に実行させることができる。また、欠損有無チェック処理部３０は、送信されたファイルのファイル情報の問合せをファイル情報問合せ部３５に実行させたり、それにより転送先マシン５０から返答されたファイル情報からファイル名及びファイルサイズを抽出し、抽出したファイル名及びファイルサイズを一時的に記憶資源２０に保存させたりすることもできる。さらに、欠損有無チェック処理部３０は、任意のタイミングで、転送先マシン５０とのセッションの接続をセッション接続／切断部２２に実行させたり、そのセッションの切断をセッション接続／切断部２２に実行させたりすることもできる。
【００４０】
この欠損有無チェック処理部３０は、ＯＳ特定部３１、予測ファイルサイズ算出部２２及び欠損有無判断部３３を備える。
【００４１】
ＯＳ特定部３１は、転送先マシン５０のＯＳ７２の種類を特定する。具体的には、ＯＳ特定部３１は、ファイル送信部３５により後述の検査用ファイルを転送先マシン５０に送信し、ファイル情報問合せ部３４によりその検査用ファイルのファイルサイズをＦＴＰサービス７０に問合せ、送信されたファイルのファイルサイズと、返答されたファイル情報中のファイルサイズと、ＯＳ特定テーブル４０とに基づいて、転送先マシン５０のＯＳの種類を特定する。
【００４２】
予測ファイルサイズ算出部３２は、アスキーモードで送信されたファイルが欠損無く転送先マシン５０に届いた場合のファイルサイズの予測値（以下、予測ファイルサイズ）を算出する。具体的には、予測ファイルサイズ算出部３２は、ＯＳ特定部３１により特定されたＯＳ種類に対応するファイル変更規則をＯＳ特定テーブル４０から特定し、特定されたファイルサイズ変更規則と、送信対象のファイルにおける改行コードの数（つまり行数）と、送信対象のファイルのファイルサイズとから、予測ファイルサイズを算出する。
【００４３】
欠損有無判断部３３は、送信されたファイルに関するファイルサイズ（具体的には、該ファイルのファイルサイズ、或いは上述した予測ファイルサイズ）と、転送先マシン５０から返答されたファイルサイズとの比較により、転送先マシン５０に届いたファイルに欠損があるか否かを判断する。
【００４４】
次に、転送先マシン５０について説明する。
【００４５】
転送先マシン５０も、転送元マシン１０と同様に、ＣＰＵ５１と、Ｉ／Ｏインタフェース部５２と、記憶資源６０とを備えている。記憶資源６０には、ＯＳ７２や、ＦＴＰサービス７０や、ファイル記憶部８０がある。ＦＴＰサービス７０に届いたファイルが、そのＦＴＰサービス７０により、ファイル記憶部８０に記憶される。
【００４６】
以上が、本実施形態に係るファイル転送システムの構成についての説明である。本実施形態に係るファイル転送システムでは、バイナリモードとアスキーモードのそれぞれの特性に応じて、実行される処理の流れが異なる。具体的には、図２Ｂに示すように、実行される転送モードがバイナリモードである場合には（Ｓ１００でＮＯ）、図３の処理が実行され、アスキーモードである場合には（Ｓ１００でＹＥＳ）、図４及び図５の処理が実行される。以下、各転送モードでファイルが送信される場合に行われる処理の流れを説明する。その際、図３には、セッションの接続と切断を詳細に示し、図４及び図５では、それを詳細に示すことに代えて、ファイル情報中のファイル名及びファイルサイズを一時保存する処理を詳細に示す。
【００４７】
図３は、バイナリモードでファイルを送信する場合に行われる処理の流れを示す。
【００４８】
欠損有無チェック処理部３０は、記憶資源２０における送信対象ファイル（以下、ファイルＦ）のファイル情報を取得する（ステップＳ１）。
【００４９】
次に、欠損有無チェック処理部３０は、取得したファイル情報からファイル名（他種のファイルＩＤであっても良い）とファイルサイズＳ１を取得し、それらを記憶資源２０に一時的に保存する（Ｓ２）。具体的には、例えば、欠損有無チェック処理部３０は、それらの情報を一時保存することをＯＳ４２に指示する。それにより、ＯＳ４２により、テンポラリファイルが準備され、そのテンポラリファイルに、ファイルＦのファイル名及びファイルサイズＳ１が格納される。
【００５０】
次に、欠損有無チェック処理部３０は、セッション接続／切断部２２に、セッション接続要求を出す（Ｓ３）。これにより、セッション接続／切断部２２によって、転送先マシン５０のＦＴＰサービス７０とのセッションが接続される（Ｓ４）。
【００５１】
その後、欠損有無チェック処理部３０は、ファイルＦをバイナリモードで送信することをファイル送信部３５に要求する（Ｓ５）。これにより、ファイル送信部３５によって、ファイルＦが格納先ディレクトリに対しバイナリモードで送信される（Ｓ６）。ファイルＦは、ＦＴＰサービス７０で受信され、ファイル記憶部８０における格納先ディレクトリ（具体的には、例えば、転送元マシン１０のユーザに指定されたディレクトリ、或いは所定のディレクトリ）に保存される（Ｓ７）。
【００５２】
ファイルＦの送信後、欠損有無チェック処理部３０は、セッション接続／切断部２２に、セッション切断要求を出す（Ｓ７）。これにより、セッション接続／切断部２２によって、Ｓ４で接続されたセッションが切断される（Ｓ８）。
【００５３】
その後（例えば、Ｓ７の直後に）、欠損有無チェック処理部３０は、セッション接続／切断部２２に、セッション接続要求を出す（Ｓ９）。これにより、セッション接続／切断部２２によって、転送先マシン５０のＦＴＰサービス７０との新たなセッションが接続される（Ｓ１０）。
【００５４】
次に、欠損有無チェック処理部３０は、Ｓ２で一時的に保存されたファイル名を指定してファイル情報を取得することをファイル情報問合せ部３４に要求する（Ｓ１１）。これにより、ファイル情報問合せ部３４により、ＦＴＰサービス７０に対し、格納先ディレクトリ名及びそのファイル名を指定してファイル情報の問合せが行われる（Ｓ１２）。その結果、ＦＴＰサービス７０で、その格納先ディレクトリ名の格納先ディレクトリ内に存在する、そのファイル名を有するファイルＦのファイル情報が取得され、その取得されたファイル情報が、ＦＴＰサービス７０から返答される（Ｓ１３）。
【００５５】
ファイル情報が返答されたならば、欠損有無チェック処理部３０は、セッション接続／切断部２２に、セッション切断要求を出す（Ｓ１４）。これにより、セッション接続／切断部２２によって、Ｓ１０で接続された新たなセッションが切断される（Ｓ１５）。
【００５６】
欠損有無チェック処理部３０は、返答されたファイル情報からファイルサイズＳ２を取得し、取得したファイルサイズＳ２を、一時的に記憶資源２０に保存する（Ｓ１６）。
【００５７】
そして、欠損有無チェック処理部３０は、Ｓ２で一時保存したファイルサイズＳ１と、Ｓ１６で一時保存したファイルサイズＳ２同士を比較する（Ｓ１７）。その結果、一致が得られた場合には、それは、ファイルＦが欠損無くＦＴＰサービス７０に届いたことを意味するが、一致が得られなかった場合には、ＦＴＰサービス７０に届いたファイルＦに欠損が生じている可能性があることを意味する。このため、欠損有無チェック処理部３０は、一致が得られなかった場合、所定のエラー処理、例えば、ファイルＦの再送をユーザから指示を受けることなく自動的に行っても良いし、エラーをユーザに報告しても良い。
【００５８】
以上が、バイナリモードで行われる処理流れの説明である。次に、アスキーモードで行われる処理の流れを説明する。
【００５９】
アスキーモードでのファイル送信では、前述したように、改行コードなどの特殊コードが変更されるが、その変更は、転送先マシン５０のＯＳ７２の種類に応じて異なる。このため、転送先マシン５０のＯＳ７２の種類が事前にわからないと、転送先マシン５０にファイルが欠損無く届いたかどうかを正確に判断することができない。問合せにより返答されたファイル情報中のファイルサイズが、欠損有無チェック処理部３０が認識できる、送信対象のファイルのファイルサイズと異なるためである。
【００６０】
そこで、本実施形態では、必要に応じて、目的のファイル（実際に送信したいファイル）を送信するまえに、所定の検査用ファイルを利用してＯＳ事前特定処理が行われ、その後で、目的のファイルが欠損無く転送先マシン５０に届いたか否かを判断する欠損有無チェック処理が行われる。以下、それぞれの処理について説明する。
【００６１】
図４は、アスキーモードでファイルが送信される場合に行われるＯＳ事前特定処理の流れを示す。
【００６２】
検査用ファイルＣが記憶資源２０に事前に準備されている。この検査用ファイルＣは、ＯＳ種類の違いによってサイズが増減する特殊コード、具体的には、少なくとも改行コードが含まれている。
【００６３】
欠損有無チェック処理部３０は、転送先マシン５０内のＯＳ種類が特定済みか否かを判断する（Ｓ５０）。この判断は、例えば、各コンピュータのＩＤ（例えば、ＩＰアドレス、或いはＷＷＮ（World Wide Name）など）と、ＯＳ種類との対応付けを表すテーブルを、転送先マシン５０のＩＤを検索キーに参照することにより、行うことができる。或いは、ユーザからＯＳ種類の入力があったか否かにより、行うこともできる。欠損有無チェック処理部３０は、特定済みであると判断した場合には（Ｓ５０でＹＥＳ）、図５のＳ７１以降を実行し、特定済みで無いと判断した場合に、以下のＳ５１以降の処理を実行する。
【００６４】
欠損有無チェック処理部３０は、Ｓ５０でＮＯの場合、検査用ファイルＣのファイル情報を取得し、そのファイル情報からファイル名及びファイルサイズＸ１を取得し、且つ、検査用ファイルＣにおける行数（改行コードの数）をカウントし、取得したファイル名及びファイルサイズＸ１とカウントされた行数とを一時保存することをＯＳ４２に指示する（Ｓ５１）。これにより、ＯＳ４２により、テンポラリファイルＴ１が準備され、そのテンポラリファイルＴ１に、検査用ファイルＣのファイル名、ファイルサイズＸ１及び行数が格納される（Ｓ５２）。
【００６５】
次に、欠損有無チェック処理部３０は、ＦＴＰサービス７０とのセッションを接続させた後、検査用ファイルＣをアスキーモードでＦＴＰサービス７０に送信することをファイル送信部３５に要求する（Ｓ５３）。これにより、ファイル送信部３５によって、検査用ファイルＣが格納先ディレクトリに対しアスキーモードで送信される（Ｓ５４）。検査用ファイルＣは、ＦＴＰサービス７０で受信され、ファイル記憶部８０における格納先ディレクトリに保存される（Ｓ５５）。
【００６６】
次に、欠損有無チェック処理部３０は、ＦＴＰサービス７０とのセッションを切断させ、且つ、新たなセッションを接続させた後、Ｓ５１で一時的に保存されたファイル名（テンポラリファイルＴ１内のファイル名）を指定してファイル情報を取得することをファイル情報問合せ部３４に要求する（Ｓ５６）。これにより、ファイル情報問合せ部３４により、ＦＴＰサービス７０に対し、格納先ディレクトリ名及びそのファイル名を指定してファイル情報の問合せが行われる（Ｓ５７）。その結果、ＦＴＰサービス７０で、その格納先ディレクトリ名の格納先ディレクトリ内に存在する、そのファイル名を有する検査用ファイルＣのファイル情報が取得され、その取得されたファイル情報が、ＦＴＰサービス７０から返答される（Ｓ５８）。
【００６７】
ファイル情報が返答された場合、欠損有無チェック処理部３０は、上記新たなセッションを切断させ、その後で、返答されたファイル情報からファイルサイズＸ２を取得し、取得したファイルサイズＸ２を、一時保存することをＯＳ４２に指示する（Ｓ５９）。これにより、ＯＳ４２により、テンポラリファイルＴ２が準備され、そのテンポラリファイルＴ２に、ファイルサイズＸ２が格納される（Ｓ５９）。
【００６８】
欠損有無チェック処理部３０は、テンポラリファイルＴ１内のファイルサイズＸ１と、テンポラリファイルＴ２内のファイルサイズＸ２との差分を算出する（Ｓ６１）。
【００６９】
Ｓ５１〜Ｓ６１の処理が、同じ差分がＮ（Ｎは２以上の整数）回得られるまで、繰り返される（Ｓ６２でＮＯ）。後述のＳ６３で特定されるＯＳ種類の正確性を高めるためである。すなわち、通信ネットワーク１００が不安定である等の原因により、送信された検査用ファイルＣが、必ずしも転送先マシン５０に欠損無く届くとは限らないし、欠損無く届いたとしても、正しいファイル情報が返答されるとは限らず、故に、一回のファイル送信と一回の問合せによるＯＳ種類特定では、誤ったＯＳ種類が特定されてしまう可能性がある。上記のように、同じ差分がＮ（Ｎは２以上の整数）回得られるまで、Ｓ５１〜Ｓ６１の処理を繰り返すことで、Ｓ６３で特定されるＯＳ種類の正確性を高めることができる。
【００７０】
同じ差分がＮ回得られた場合（Ｓ６２でＹＥＳ）、欠損有無チェック処理部３０は、その差分（Ｘ１−Ｘ２）と、テンポラリファイルＴ１内の行数（検査用ファイルＣの行数）と、ＯＳ特定テーブル４０とに基づいて、転送先マシン５０のＯＳ７２の種類を特定する（Ｓ６３）。具体的には、例えば、図２Ａの例において、差分（Ｘ１−Ｘ２）が−３８であり、行数が１９の場合、−３８を１９で除算することにより−２が得られ、故に、ＯＳ種類は"ＣＣ"であると特定することができる。なお、その除算により余りが生じる場合には、終了コードに対応したサイズ増減値を参照することにより、ＯＳ種類を特定することができる。
【００７１】
以上のようにしてＯＳ種類が特定された後、欠損有無チェック処理を行うことができる。なお、特定されたＯＳ種類は、転送先マシン５０のＩＤに対応付けて記憶資源２０に記憶させておき、以後、目的とするファイルを送信する場合には、Ｓ５１以降の処理を行うことなく、欠損有無チェック処理を行うことができる。これにより、無用にＯＳ事前特定処理を行う必要が無いので、ファイルが欠損無くＦＴＰサービス７０に届いたか否かを迅速に認識することができる。
【００７２】
図５は、アスキーモードでファイルが送信される場合に行われる欠損有無チェック処理の流れを示す。
【００７３】
欠損有無チェック処理部３０は、記憶資源２０における、目的とするファイル（以下、ファイルＫ）のファイル情報を取得する（Ｓ７１）。
【００７４】
次に、欠損有無チェック処理部３０は、ファイルＫの行数をカウントし、その行数と、Ｓ７１で取得したファイル情報中のファイルサイズｓ１と、特定済みのＯＳ種類に対応するファイルサイズ変更規則（ＯＳ特定テーブル４０から特定できるファイルサイズ変更規則）とに基づき、ファイルＫが欠損無くＦＴＰサービス７０に届いた場合のファイルサイズである予測ファイルサイズｓ１´を算出する（Ｓ７２）。具体的には、例えば、ファイルサイズｓ１が２００であり、行数が１０であり、ＯＳ種類がＣＣである場合（図２Ａ参照）、予測ファイルサイズｓ１´は、２００＋（１０×−２）＋１＝１８１となる。
【００７５】
欠損有無チェック処理部３０は、ファイルＫのファイル名及び予測ファイルサイズｓ１´を一時保存することをＯＳ４２に指示する（Ｓ７３）。これにより、ＯＳ４２により、テンポラリファイルｔ１が準備され、そのテンポラリファイルｔ１に、ファイルＫのファイル名及び予測ファイルサイズｓ１´が格納される（Ｓ７４）。
【００７６】
次に、欠損有無チェック処理部３０は、ＦＴＰサービス７０とのセッションを接続させた後、ファイルＫをアスキーモードでＦＴＰサービス７０に送信することをファイル送信部３５に要求する（Ｓ７５）。これにより、ファイル送信部３５によって、ファイルＫが格納先ディレクトリに対しアスキーモードで送信される（Ｓ７６）。ファイルＫは、ＦＴＰサービス７０で受信され、ファイル記憶部８０における格納先ディレクトリに保存される（Ｓ７７）。
【００７７】
次に、欠損有無チェック処理部３０は、ＦＴＰサービス７０とのセッションを切断させ、且つ、新たなセッションを接続させた後、テンポラリファイルｔ１内のファイル名を指定してファイル情報を取得することをファイル情報問合せ部３４に要求する（Ｓ７８）。これにより、ファイル情報問合せ部３４により、ＦＴＰサービス７０に対し、格納先ディレクトリ名及びそのファイル名を指定してファイル情報の問合せが行われる（Ｓ７９）。その結果、ＦＴＰサービス７０で、その格納先ディレクトリ名の格納先ディレクトリ内に存在する、そのファイル名を有するファイルＫのファイル情報が取得され、その取得されたファイル情報が、ＦＴＰサービス７０から返答される（Ｓ８０）。
【００７８】
ファイル情報が返答された場合、欠損有無チェック処理部３０は、上記新たなセッションを切断させ、その後で、返答されたファイル情報からファイルサイズｓ２を取得し、取得したファイルサイズｓ２を、一時保存することをＯＳ４２に指示する（Ｓ８１）。これにより、ＯＳ４２により、テンポラリファイルｔ２が準備され、そのテンポラリファイルｔ２に、ファイルサイズｓ２が格納される（Ｓ８２）。
【００７９】
そして、欠損有無チェック処理部３０は、テンポラリファイルｔ１内の予測ファイルサイズｓ１´と、テンポラリファイルｔ２内のファイルサイズｓ２同士を比較する（Ｓ８３）。その結果、一致が得られた場合には、それは、ファイルＫが欠損無くＦＴＰサービス７０に届いたことを意味し、一致が得られなかった場合には、ＦＴＰサービス７０に届いたファイルＫに欠損が生じている可能性があることを意味する。このため、欠損有無チェック処理部３０は、一致が得られなかった場合、所定のエラー処理、例えば、ファイルＦの再送をユーザから指示を受けることなく自動的に行っても良いし、エラーをユーザに報告しても良い。
【００８０】
以上、上述した実施形態によれば、転送モードがバイナリモードであるかアスキーモードであるかに関わらず、ＦＴＰでファイルを送信する転送元マシン１０が、転送先マシン５０に届いたファイルに欠損があるか否かを認識できるようにすることができる。
【００８１】
特に、アスキーモードでのファイル送信では、改行コードなどの特殊コードが変更され、故に、問合せにより返答されたファイル情報中のファイルサイズが、欠損有無チェック処理部３０が認識できる、送信対象のファイルのファイルサイズと異なるため、バイナリモードでの欠損有無チェック方法と同じ方法では、ファイルが欠損無く届いたかどうかを正確に判断することができないが、本実施形態では、それが以下のようにして解決されている。すなわち、図５を参照して詳述したように、転送先マシン５０のＯＳ種類、該ＯＳ種類に対応したファイル変更規則、ファイルＫのファイルサイズｓ１及びファイルＫの行数に基づいて、予測ファイルサイズｓ１´が算出されて一時的に保存され、その予測ファイルサイズｓ１´と、返答されたファイル情報中のファイルサイズｓ２とが一致するか否かにより、ファイルの欠損の有無を判断することができる。
【００８２】
また、上述した実施形態によれば、ファイル送信の際に使用されるセッションと、ファイル情報問合せの際に使用されるセッションとが独立している。これにより、誤ったファイル情報が取得されてしまう可能性を低減することが期待できる。すなわち、ファイルの送信の際に使用されたセッションと同じセッションでファイル情報を取得した場合、そのセッションが、転送先マシン５０に届いたファイルに欠損が生じた場合のセッションであれば、不具合のあるセッションでファイル情報が取得されたので、その取得されたファイル情報に誤りが生じている場合があり得るが、本実施形態によれば、そのような事態が生じる可能性を低減することが期待できる。
【００８３】
以上、本発明の一実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。
【００８４】
例えば、テンポラリファイルには、ファイル名に加えて、ディレクトリ名が保存されてもよい。また、送信するファイルのファイルサイズや、返答されたファイル情報中のファイルサイズを一時的に保存するための方法として、テンポラリファイルを準備してそれに格納する方法に代えて、メモリの所定領域に記憶させる方法など、他の種々の方法を採用することができる。
【００８５】
また、例えば、セッションの切断要求は、ファイルをファイル送信部３５に送信させたことを契機として、自動的に行うことができる。或いは、ファイル送信部３５が、ファイルを送信した場合に、ファイルを送信したことを欠損有無チェック処理部３０に報告するようになっているならば、セッションの切断要求は、その報告を受けたことを契機として、自動的に行うことができる。
【００８６】
また、例えば、セッションの接続要求は、セッション接続／切断部２２にセッションを切断させたことを契機として、自動的に行うことができる。或いは、セッション接続／切断部２２が、セッションを切断した場合に、セッション切断を欠損有無チェック処理部３０に報告するようになっているならば、セッションの接続要求は、その報告を受けたことを契機として、自動的に行うことができる。
【００８７】
さらに、例えば、ファイル情報の取得要求は、セッション接続／切断部２２にセッションを接続させたことを契機として、自動的に行うことができる。或いは、セッション接続／切断部２２が、セッションを接続した場合に、セッション接続を欠損有無チェック処理部３０に報告するようになっているならば、ファイル情報の取得要求は、その報告を受けたことを契機として、自動的に行うことができる。
【００８８】
また、例えば、ＯＳ管理テーブル４０とは別に、ＯＳ種類特定のための専用テーブル、具体的には、例えば、ＯＳ種類毎に、検査用ファイルＣの変換後のファイルサイズが対応付けられたテーブルが用意されても良い。この場合、各ＯＳ種類毎のファイルサイズと、返答されたファイル情報中のファイルサイズとを比較し、一致が得られたファイルサイズに対応したＯＳ種類を、転送先マシン５０のＯＳ種類と判断することができる。
【００８９】
また、例えば、図５の欠損有無チェック処理では、予測ファイルサイズｓ１´を算出する方法に代えて、以下の方法が採用されても良い。すなわち、ファイルサイズｓ２とファイルサイズｓ１との差分と、行数と、ＯＳ種類に対応したファイル変更規則とを基に、欠損有無の判断が行われても良い。具体的には、例えば、前述した例と同様に、ファイルサイズｓ１が２００で、ファイルサイズｓ２が１８１で、行数が１０で、ＯＳ種類がＣＣの場合（図２参照）、終了コードによる増加分の１を１８１から減じ、（１８０−２００）を行数１０で除算することにより得られた値−２と、ＯＳ種類ＣＣの改行増減値とが一致するか否かにより、欠損有無の判断が行われても良い。
【００９０】
また、例えば、ファイル情報が返答された後に、必ずしも、セッションが切断されなくても良い。
【図面の簡単な説明】
【００９１】
【図１】本発明の一実施形態に係るファイル転送システムの構成を示す。
【図２】図２Ａは、ＯＳ特定テーブルの構成例を示す。図２Ｂは、転送モードに応じた処理が選択される流れを示す。
【図３】バイナリモードでファイルが送信される場合に行われる処理の流れを示す。
【図４】アスキーモードでファイルが送信される場合に行われるＯＳ事前特定処理の流れを示す。
【図５】アスキーモードでファイルが送信される場合に行われる欠損有無チェック処理の流れを示す。
【符号の説明】
【００９２】
１０…転送元マシン、１１…ＣＰＵ、１２…Ｉ／Ｏインタフェース部、２０…記憶資源、２２…セッション接続／切断部、３０…欠損有無チェック処理部、３１…ＯＳ特定部、３２…予測ファイルサイズ算出部、３３…欠損有無判断部、３４…ファイル情報問合せ部、３５…ファイル送信部、４０…ＯＳ特定テーブル、４２…ＯＳ、５０…転送先マシン、５１…ＣＰＵ、５２…Ｉ／Ｏインタフェース部、６０…記憶資源、７０…ＦＴＰサービス、７２…ＯＳ、８０…ファイル記憶部、１００…通信ネットワーク
【図１】
2007272490.tif 000003
【図２】
2007272490.tif 000004
【図３】
2007272490.tif 000005
【図４】
2007272490.tif 000006
【図５】
2007272490.tif 000007