none
ハードディスクにアクセスせずに、LANの受信があったことを確認する方法は RRS feed

  • 質問

  • 複数台のパソコン(想定は5台)間でLAN経由でファイルを送っています。
    送信は随意の時間とします。
    さて、受信側ではプログラムの中でタイマーを使い、一定時間毎に送信ファイルが
    ないかを確認し、存在すれば読み込みを行います。
    ファイルの存在は zai_sw = _access(failename,00);で確認していますが
    ハードディスクにアクセスしているのでディスクに負担が掛かります。
    できればこの関数を使わず、LANの受信があったことを確認する方法は
    ないでしょうか。

    通常のサーバーとクライアント方式でのLANの使い方とします。

    LANは接続されているものとします。SDKで行っています。

     

     

    2011年7月14日 1:48

すべての返信

  • タイマーはどれぐらいの頻度ですか? ある程度頻度が高い場合、ファイルの存在・ファイルサイズ程度の情報はメモリー上にキャッシュされていて、いちいちハードディスクにアクセスせずに済みますが。

    質問そのものに直接答えるとすると、パフォーマンスカウンターで対象のプロセスがどの程度ネットワークアクセスがあったかを測定することはできますが…以前の質問を読む限り、この処理を実装するのは敷居が高いです。それとこの機能はWindows XPでは使用できますがWindows 95では使用できません。

    質問の際は、対象となるOSを明記した方がいいと思います。

    2011年7月14日 2:45
  • 目的の確認です

    複数台のパソコン(想定は5台)間でLAN経由でファイルを送っています。
    送信は随意の時間とします。
    さて、受信側ではプログラムの中でタイマーを使い、一定時間毎に送信ファイルが
    ないかを確認し、存在すれば読み込みを行います。

    このあたりから、「受け取り用の共有フォルダに、ファイルが存在するかどうか?(読み書きなどが行われたかどう)」が、
    分かればいいのでは、と思うのですが、それでいいでしょうか?

    それとも「LANの受信」というのにこだわる必要があるでしょうか?

    前者であれば、ReadDirectoryChangesWをつかえば、
    監視したいフォルダをきめて、そのフォルダ内に対してファイルの読み書きなどがあれば、その内容の通知をうけることが可能です。
    #動作環境などの情報がないので、合致しないかもしれません。

    2011年7月14日 4:36
  • 間隔は5分~30分を想定していますが、間に自身の作業内容をディスクに読書きしていますので

    恐らく、ディスクキャシュは使えないと思います。

    頭の中では、RS232Cでの通信では受信データを監視して、着いたら自身のメモリーに一旦取り込んだ上で、処理、結果をディスクに書き込んでいました。

    この場合は受信データが無ければ、ディスクを書き込む作業はなくて済む訳です。そう言うイメージです。それに最近は使っていない時はハードディスクを

    止めているでしょう。使わないけれど、この場合は結局常にハードディスクは回転し続けることになります。出来たら消耗を防ぎたいという思いからです。

    予定OSはXPです。出来れば、IOポートの監視のような仕組みを狙っています。

    2011年7月14日 6:15
  • 外池と申します。

    RS232Cの話題が出て、かえって判らなくなってしまいました。RS232Cの例(needsuedaさんのお考え)では、通信自体、作成しようとしているプログラムの制御の下にあるわけですよね? ファイル転送ではなく、PC間のデータの転送を作成しようとしているプログラムで直接受信するというやり方でも良いのでしょうか? 送り出し側のパソコンのプログラムにも手を加えて良いのでしょうか?

    あと、そもそも論ですが、ハードディスクの負担という話が最初に出ていますが、これって、本当に気にしないといけないようなものでしょうか? ファイルをチェックしに行く間隔が5分から30分、その間別の作業でハードディスクにはアクセスしているとも書かれていて、いつもハードディスクは動いている状況と拝察します。

    シンプルな方法で十分なような・・・。


    (ホームページを再開しました)
    2011年7月14日 8:13
  • >IOポートの監視のような仕組みを狙っています。
    ClientとServer間でSocketによるConnectionを張るようなイメージですか?

    [Beginning Winsock Programming - Simple TCP server]
      http://www.codeproject.com/KB/IP/winsockintro01.aspx

    [Server Client Sockets] 
      http://www.codeproject.com/KB/IP/server_client_sockets.aspx?display=Print

    私も話が良く分からないのですが、ReadDirectoryChangesWで十分なような気はします。

    [CDirectoryChangeWatcher - ReadDirectoryChangesW all wrapped up]
      http://www.codeproject.com/KB/files/directorychangewatcher.aspx

    >複数台のパソコン(想定は5台)間でLAN経由でファイルを送っています。
    具体的にどのようなApplicationでどのように送り先を決定し、どのように送っているのでしょうか?
    またFileとはどのような特徴や性質をもつFileなのでしょうか?

    2011年7月14日 10:29
  • 色々指摘が上がっていますが、他にもまだあります。

    「ディスクキャシュは使えない」と言われますが、ファイルの中身をキャッシュする必要はありません。ファイル名やサイズ・更新日時といった情報(ディレクトリエントリ)がメモリ上にキャッシュされていれば十分です。これらの情報はメモリサイズに対して小さいので十分に小さいのでキャッシュに残っている可能性が高いです。というかこういった情報がメモリに残せないほどひっ迫している状況ではメモリは常時スワップアウトしページファイルへアクセスされているため、ディスクアクセスを意識するような状況ではありません。

    「使っていない時はハードディスクを止めている」とも言われていますが、ハードディスクは停止状態からスピンアップ・ヘッドシークなどを行うと、書き込みを開始してから実際に書き込まれるまで10秒近く待たされることになるかもしれません。needsuedaさんの作られているプログラムは、ファイルへの書き込みが10秒近く待たされたとして問題なく動作できますか? その間プログラムが「応答なし」等になったりしますが。もし問題があるようなら、ハードディスクを止めるよりもむしろ止めさせないよう常時何らかのアクセスを行うよう考慮した方がいいのかもしれません。

    「常にハードディスクは回転し続け~出来たら消耗を防ぎたい」と言われていますが、ハードディスクは常に回転し続けることも考慮して設計されています。needsuedaさんの作られたプログラムが10年20年といった単位で無停止・連続稼働されるのであれば、ハードディスクへの負荷も考慮する意味も出てきますが、そうではなく長くて数年使用する程度であればあまり意味がないかもしれません。少なくとも小刻みな回転の停止→スピンアップはハードディスクに負担になることもあります。

    2011年7月14日 12:05
  • FindFirstChangeNotification()も、検討してみる価値があるかもしれません。
    2011年7月15日 5:01
  • 理由としては
    1.運用時間が長く、しかも入力は集中することもあり、閑散とした時間帯もあることです。
      運用ケースにもよりますが、短い場合で10時間、長い場合で16時間位になります。
      つまり全く仕事をしていない時もあれば間断なく仕事をしている時もあると状況です。
    2.パソコンで最も故障の発生の高いのは、ハードディスクです。
      使い方にもよりますが、これまでは短いもので6ヶ月、長くて4年位で故障になりました。
      故障時の対応を考えるとせめて5年は交換せずに済ませたいのが人情です。
    3.同一LAN外とのデータ交換ですので、相手側をコントロールできません。

    現行は止む無く、ディスクにアクセスで済ませていますが。

    2011年7月15日 6:59
  • 5台の中4台は当方のプログラムが共通で動いていると想定して下さい。
    中1台がマスタとなり、ここで全てのデータを管理、サブとして同じデータを
    別の1台に保存しています。
    この場合は送り手も受け取り手もタイミングは判っているので管理は簡単ですが、
    外部とのやり取りをマスタが行います。外部はこちらからのコントロールは
    できません。この場合共有フォルダは外部かマスタかどちらかに持つことに
    なりますが、取りあえず外部とします。共有フォルダはフルアクセスです。
    共有フォルダへは接続確認済です。
    2011年7月15日 7:01
  • 外池さんに書いた理由と同じですが、
    パソコンで最も故障率が高いのはハードディスクです。
    この故障経験から、ハードディスクへの配慮が最も大切だと考えています。
    最短6ヶ月と書いたのはオーバーではありません。このケースでは取り扱いに
    問題であったことは事実ですが、3台同じ条件の場所で故障したのは2台で
    中1台は半年後再びハードディスクを壊しました。残る1台は4年後に壊れました。
    せめて5年間は動いてよと思うのは人情です。(リース期間は5年でしょう。
    5年後なら相手に説明できると思うので)
    注.故障したのは高名なノートパソコンで、当時最も信頼性の高い商品で
    あると報道されていました。
    2011年7月15日 7:02
  • 外池です。ハードディスクが壊れやすいということについて、私も同意します。しかし、壊れやすさを軽減する目的で、あるひとつのアプリケーションソフトについてのみハードディスクへのアクセスを少なくするという工夫は、私は殆ど効果がないと想像します。

    ひとつの理由は、製作されているアプリケーション以外にも、OSや他のアプリがハードディスクにアクセスするからです。どうしても、というのであれば、事前に、ハードディスクへのアクセス数について、パフォーマンスカウンターで下調べしておくことが良いのではないでしょうか? 総アクセス数に対して、製作されているアプリケーションによるアクセス数が大半を占めるようであれば、検討の余地ありかもしれませんが・・・、うーん、ほとんど意味ないと思いますね。

    もうひとつの理由は、ハードディスクの壊れやすさを左右する要因が、アクセス数のみではない、ということです。外部から与えられる振動、稼動環境の温度、ハードディスクの機種による差、同一機種における個体差などなど。このような要因の方がはるかに大きく効くと、私は思っています。佐祐理さんも書いておられるように、停止やスピンアップも相当な負担になると思います。

    そして・・・、これは、根本的なところでの検討を要することですが、ハードディスクが壊れることで、何が最も深刻な問題になりますか? 新しいハードディスクに取り替えるコスト増? システム停止に伴う業務停滞による損害? ハードディスクに保管されている情報の喪失?

    最初に書きましたように、私もハードディスクは壊れるものと思っています。ほとんど「運・不運」の問題だと思ってます。その上で、壊れやすさを低減するよりも、壊れたときに、何の損害を最小にするか方針を定めて、対策を施す方が重要と思います。

    「運・不運」と言ってられないほどにシビアな信頼性が要求されているなら、ハードディスクそのものに高い信頼性を求めるべきでしょう。振動を検知して動作を止めるような安全装置を備えたものもありますし、もし故障しても運用を続けられるようなRAIDという仕組みもあります。また、ソリッドステートドライブは非常に堅牢と思います。


    (ホームページを再開しました)
    2011年7月15日 7:44
  • 済みません。運用形態を説明していませんでした。

    運用は全て単一のソフトだけです。即ち、当方で作成したプログラムソフトのみです。

    事例はMSDOSの場合でしたが、Windowsでも単にOSとして使っているだけです。

    専用ソフトでのみ運用されています。で、少しでも負担を掛けたくないので色々と工夫

    している訳です。事務用なら修理に時間的余裕はあるのですが、レジスタの場合は

    そうは行きません。止まった瞬間から、精算ができなくなりお客が長蛇の列を成すことに

    なります。ハードディスクの交換になるので、ソフトやデータの移し、止まった間の

    手計算の処理など、相手側から対応を迫られます。

    先の事例のメーカーは明かせませんが、当時米国防省推薦の商品と報道されたことを

    付言させて頂きます。それだけ信頼性が高いと言う商品だったと言うことです。

    2011年7月15日 16:58
  • 揚げ足気味ですが。

    運用は全て単一のソフトだけです。即ち、当方で作成したプログラムソフトのみです。

    サービスが動いていたり、Windows Kernel が動いていたりしますよね。
    それらが HDD へのアクセスがないことを保障できないと思いますが…。 

    MS-DOS 時代がどうだったか知りませんが、Windows ではアプリが 1 個だけでも複数のプロセス・サービスが存在します。
    そして、それらが制御可能だとは限りません。

    ハードディスクの交換になるので、ソフトやデータの移し、止まった間の手計算の処理など、相手側から対応を迫られます。

    冗長なハードウェア構成にすればよいのでは?
    1 台壊れてもデータがロストせず、電源を落とさずに壊れた HDD だけ交換できる構成とか。

    正直なところ、ソフトウェアがいくらがんばったところで、壊れるときは壊れるのですから、壊れたときにいかに復旧時間が少なくなるか、ハードウェア面の対策を講じた方が費用対効果が高いように感じられます。


    質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。
    2011年7月15日 22:11
    モデレータ
  • 外池です。レジスタなのですね。止まれば、システムの顧客としての「お店」も困るし、その「お店」の「お客さん」も困るし。ということで、「止まらないようにしたい」ということであれば、私なら、まずは、ハードディスクをSSDにすることを検討しますね。

    私も含めて繰り返し指摘が出ていますが、Windowsの場合、ハードディスクへのアクセスの量を減らす努力というものは、実効性がないと思います。Windows自身もハードディスクにアクセスしますからね。

    needsuedaさんも、実態としてすでに気付いておられると思うのですが。ハードディスクは壊れるものだ、と。「信頼性が高いと言う商品」であってもです。米国防省がどのような評価をしたかは存じませんが、裏を返せば、プログラマーがどれだけ頑張っても、アプリの良し悪しでハードディスクの信頼性を上げることは難しいと私は思います。

    私から申し上げることは以上にしますが、最後にひとつだけアイデアとしては、「レジスタ」ということですので、「組み込みOS系」の人達だともっと良い助言が得られるかもしれません。EmbededバージョンのWindowsのフォーラムやコミュニティーで相談されてはいかがでしょうか?

    ご健闘をお祈りします。


    (ホームページを再開しました)
    2011年7月15日 22:47
  • OSはXP Embeddedですか?
    一般PC向けのXPを前提に考えていたので、もしそうなら前提が異なります。

    XP Embeddedだと私から詳しい案内は出来ないのですが、
    FTPdのようなServiceを自分で作って、通信すればFileのやり取りは自分で制御できるでしょう。

    共有フォルダへのaccessをpacket 監視で感知し、
    File処理を自分のprogramで横取りするのは、難しいと思いますよ。

    あと、HDDへのaccessを気にしてmemory上で処理すると、
    瞬停などfileやdataが失われてしまうことも考えられますので、
    この辺は均衡をとりながら考える必要がありますね。

    2011年7月16日 3:37
  • 解決策の実例をひとつ。
    ある顧客から、絶対にシステムが止まらないようにしたいと依頼がありました。
    ハードは遅かれ早かれ壊れる。この顧客からの提案で本来は1台で済む業務だが
    2台構成とし、1台が壊れても残る1台で対応できるようにして欲しい。
    そこで、2台を別々に置き、正常な場合はそれぞれ専用業務に専念するが
    一旦故障で1台が止まった場合、残った方で両方の業務を受け持ち、
    修理の時間を稼ぐことにしました。2台共同時に故障することは確率的にかなり
    少ないのでこれで行くことにしました。但しデータのリアルタイムな共有が必要
    ですので、両方に同じ内容のデータを保存することにしました。
    所謂ダブルマスタ制です。こうすれば、残った方は連続的に記録を保存して
    行く事が可能となります。修理後は残った方から修理完了した方にデータを
    転送すればそれでOKとなります。ただ、10秒程度は交換作業のため全体の
    登録作業はできなくなりますが、これは止むを得ないので了承してもらいました。
    3年位経ってから実際に故障が起こりました。故障時手順書通りにしてもらいましたが
    うまく行きました。
    2011年7月16日 7:40
  • 出来るだけコストを安く作り上げることが前提です。
    従って、専用機器(プリンタなど)は必要最低限にして、パソコンは
    予算があれば別ですが、汎用機で済ませればそれだけ安くつきます。
    万一、瞬間停電があっても大部分のデータは壊されないようにシステムを
    作っています。これまで何度も停電がありましたが、キャシュに残っていた
    データは無しても、その他のデータは保存されており、停電後問題なく
    操作が出来ています。それも困る客先にはノートパソコンを勧めています。
    バックアップバッテリーが内蔵されているからです。当初の顧客には
    全てノートパソコンを勧めていました。
    2011年7月16日 7:43
  • おっしゃる通り、ハードディスクではなく消えないメモリー上に保存する
    ことは大変有効です。同じプログラムを1台はハードディスク、1台は
    消えないRAMカードに記録することにしました。
    RAMカードを採用した方は一度もそれに関係した故障は起こしませんでした。
    ところが、ハードディスクを搭載した方はやはり4年程度が限界かと思いました。
    SSDは高いので顧客がOKすればよいですが、コスト的に
    安いUSBメモリーを研究して見たいと考えています。但しUSBメモリーは
    書き込み回数に限界がある(500回程度と思うが)ので、その辺りをどうするか
    が研究課題です。レジスタでは毎回同じ所にアクセスしますので、直ぐ限界回数に
    到達する恐れがあるからです
    2011年7月16日 7:50
  • できればこの関数を使わず、LANの受信があったことを確認する方法はないでしょうか。

     例えば、WinPcap 等のパケット キャプチャー ソフトを使えば、LAN を経由してデータのやりとりがあったことを知ることは出来ます。しかし、それがどの様な種類のデータなのか、ふるいにかける必要が有ります。この方法であれば、いくつかの条件をクリアすると、他の PC に対する変更であっても取り出すことが出来ます。

     例えば、その共有ディレクトリが、自身が他に公開しているフォルダーならば(1個の共有フォルダーを LAN で監視しようというものでないならば)、FindFirstChangeNotification 関数が使えるかもしれません。ただし、この関数は、変更の最初に通知されます。変更の最後を通知する方法は、ありません。
     ところで、RS-232C にしても、「データの到着」を知ることは出来ますが、「データの終端」を知ることは出来ません。「一定時間毎に送信ファイルがないかを確認し、存在すれば読み込みを行います。」ということは、「データの到着」ではなく、「データの終端」、書込が完了したことを検出しなければならないと思います。すると、「この場合は受信データが無ければ、ディスクを書き込む作業はなくて済む訳です。」とはならないと思います。
     と言うことは、こういうことも考えられます。そのアプリケーションは、何処かにあるファイルを読まなければならないのでしょうか。送り手が、アプリケーションに、データを直接送ってはいけないのでしょうか。RS-232C の例は、どちらかというと、この「データを直接送り込む」イメージになります。


     私が使用している範囲では、ディスクが壊れたことは1度もありま・・・あ、パソコン起動中に娘がバシバシ叩いたときに壊れただけ、ですね。その他のディスクは、10年以上前のディスクも(USB に変換して、時々使うだけですが)動いています。業務で使用したもの、お客様に納入したものも含めても……20年間で5~6例くらい。うち一例は、埃によって装置の排熱ファンが止まったためなので、手入れをしれいれば壊れていないはず。兵庫県南部地震で、机の上から落ちたディスクも壊れていなかったし。結構壊れにくいイメージがあるけどなぁ。
     レジ システムですか。そういえばつい最近、妻がそういう状況に遭遇しましたね。ネットワークがダウンし、カードが一切使えない状態。その店舗のレジが Windows XP の起動画面を出していましたが、embedded ではない Windows XP なら、Process Monitor というツールで、ファイルにアクセスしているプロセスの一覧が見れますから、一度見ておくと良いかもしれません。私が見ている限り、何かのプロセスが絶え間なくファイルにアクセスしています。それと、Windows Embedded POSReady 7 というのがあるようです。

     このケースでは、こういう言い方をすると怒られるかもしれませんが、許容できる損害を考えなければなければならないと思います。あるいは、保険のようなものです。ハードディスクの増設、あるいは SSD は、確かに初期費用が嵩みます。しかし、障害発生時の費用は少なくて済みます。ソフトウェアでごりごりやるのは、初期費用も障害発生時の費用も嵩みます。人件費は、部品の費用より高いと思います。
     なお、 USB メモリの書き換え回数は100万回以上ではないでしょうか。これは「書き込み回数」ではありません。1素子あたりの「書き換え回数」です。最近のものなら、書き換え回数が均一になるように(特定の素子のみ頻繁に書き換えないように)制御しています。もし、書き込み回数が500回程度なら、Ready Boost に使っている私の USB メモリは、とっくに逝ってます。


    Jitta@わんくま同盟
    2011年7月20日 13:10