ネットワーク通信
お世話になります、海苔通と申します。
ネットワーク通信で困っていることがあります。どなたか、御教授頂ければ幸いです。
２装置間でudpパケットの通信を行っているのですが、
まれにudpパケットが過去に送ったudpパケットとなるときがあります。
mirrorポートを仕込んで現象発生時のパケットをLANアナライザ（イーサリアル）で見たのですが、そのパケットにトレイラーとFCSなるものが付加されていることがわかりました。
質問１
そこで質問なのですが、これらの付加情報を取得することは可能なのでしょうか？（もし、これらの付加情報を取得できるのであれば、エラー処理が可能ですので。。。）
質問２
また、これらの付加情報が付く原因は何が考えられるでしょうか？
以上、宜しくお願いします。
ＵＤＰの仕様
http://www.picfun.com/lan08a.html
http://www.atmarkit.co.jp/fwin2k/network/baswinlan013/baswinlan013_02.html
で、トレイラー・ＦＣＳと言うものはありません。
その装置のプロトコロルとしてデータ部に独自に設定されている
仕様ではないでしょうか？
また、何を以って過去のパケットと判断しているのでしょう？
ＴＣＰでは無いので、再送があった場合は装置が何らかの送達確
認を行い、未受信と判断して再送要求を出しているか・・・
もしくはタイムアウト？
何はともあれ、その装置メーカーにプロトコルの仕様確認をされ
た方がよいように思われますが・・・
※ 装置って何？
メーカー・型式から類推できるかもしれませんが、多分、こ
のような掲示板の無理だと思いますが・・・
以上。
※ 見落とし・・・
＜抜粋＞
3.1.1 IP のチェックサム
受信側は着信したデータを解析し、まず着信フレームのCRC/FCSをチェックすることにより、Ethernet MACフレームのデータの完全性を確認します。さらに、CRCにパスした正常なEthernetフレームについて、MACフレームの「長さ/タイプ」フィールドの値がチェックされます。この値が「0x0800」であれば、カプセル化されたペイロードはIPv4データグラムであり、「0x86DD」であれば、このペイロードはIPv6データグラムです。次に、IPヘッダのバージョン・フィールドがチェックされ、その値と「タイプ」フィールドの値との整合性が確認されます。すなわち、バージョン・フィールドの値は、IPv4の場合は「0x4」に、IPv6の場合は「0x6」に設定されている必要があります
フレームが有効なIPv4フレームだということが確認された場合、前述のアルゴリズムに従って、チェックサム・フィールドを含むヘッダフィールド領域のチェックサムが計算されます。この値が0xffffであれば、正しいチェックサムが着信しています。それ以外の値はエラーを意味し、その場合は該当するパケットをコアの内部で取り除くことができます。さらにEthernetフレームの「タイプ」フィールドと、その中にカプセル化されたIPフレームのバージョン・フィールドとの不整合もエラーと見なされ、レポートされます。IPv6ヘッダには、ヘッダ・チェックサム・フィールドはありません。
ソフトウェアをさらに支援するため、GMACユニバーサルIPはIPデータグラムのペイロード(TCPデータグラムまたはUDPデータグラム)のチェックサムを計算します。使用されるチェックサム計算アルゴリズムは前述のものと同じです。最終バイトの境界が不適切であれば、パディング・バイトが必要に応じて追加されます。このようにして計算された2バイトのチェックサム値が、MACフレームのFCSフィールドの後ろに追加され、アプリケーションに渡されます。
● このFCSのことを言っておられる？
で、同一のものがあったから過去のパケットと言っているのでしょう
か？
以上。
>まれにudpパケットが過去に送ったudpパケットとなるときがあります。
パケットの送信順に届かないことがあるという意味なら正常だと思います。
UDPでは、一般論として
１．データは届かないこともある。これは正常です。
２．送信した順序と異なる順序で受信されることもありえる。
これも正常です。
ので、「それでも動作し続ける」アプリケーションに
作っておかなければなりません。TCP/IPなら話は別。
質問１ 知りません。あしからず
質問２ トレーラにFCSがあるのは別に異常じゃないと思いますが。
どうなんでしょう。
トレイラ？
トレーラの間違い・・・
http://www6.plala.or.jp/mting32/aboutpc/tpf/tcpip_01.html
このパケット説明の末尾のトレーラを指示しているのであれば
アプリでこの情報を取得できるか？ということであれば、可能
かもしれませんが残念ながら知りません。
調べてみて解ればまたカキコします・・・
あしからず。
以上。
アプリでトレーラ等付加情報を取得したい・・・
簡単に思いつくのは、WinPCAP等を使って、パケットモニタ機能を
インプリするとか・・・
● 装置側に何らかの再送仕様があるのでは？
で、過去と称されている点ですが、タイムアウト等の再送
であれば、ネットワークを疑うしかないでしょう。
一般的にはスイッチハブの劣化やノイズ等・・・
それで同じものが流れたりする。
ご検討下さい。
以上。
オショウさん、仲澤さん、回答ありがとうございます。
＞● このFCSのことを言っておられる？
で、同一のものがあったから過去のパケットと言っているのでしょう
か？
はい、このことをいってます。
過去のパケットといっているのは、
たとえば、１〜１０００００までのデータをUDPで送信しているのに、受信側で「１受信OK、２受信OK、・・・、98受信OK、99受信OK、100受信OK、98受信NG！！」とNGとなるときがあることから、過去のパケットを受信していると言っています。また、そのときのパケットをミラーポートでイーサリアル（パケットキャプチャツール）でチェックすると、「FCSが正常でない」と出ています。
受信データが重複しているように見えるので、仲澤さんの回答内容の１、２に当てはまりません。
もしかしたら、オショウさんの言うように、装置側に何らかの再送仕様があるのかもしれませんので、調べてみます。
ただ、仲澤さんのいうとおり、受信データが重複したとしても正常動作する仕組みにしないといけないですね＾＾
ご助言ありがとうございます。進展ありました、連絡します。
ネットワークの構成はどうなっているんでしょうか？
経由するハブ数やケーブル長
環境的にノイズが多いかもしれないとか・・・
あとＵＤＰの性質上、受信側に届かないかもしれない
と言うことをどうやって判断しているか・・・
受信側はただ単にポートを開けて受信待ちしているだ
けなので、パケットの順番を管理しているか、仕様的
に数パケットに及ぶ場合、その中間のパケットの送達
確認はタイムアウトしかない・・・
あと長いパケット長の場合・・・
ハブによっては分割・遅延しますが、それが悪影響し
ている場合もあります。
ハブの電源切って入れなおしたらしばらくは問題なく
動作するが、しばらくしたら再発する。とか・・・
そういう場合もあります。
原因は多種多様・・・
以上。
経由するハブはＬ３ＳＷハブ１つです。
ノイズはおそらく発生しやすい環境であると思います（いろいろな装置があり、またその中にかなり高電圧の装置も一色タンにあるので）。
ハブ電源落としてどうなのかは確かにやってみる価値ありそうですね、試してみます！！
この調査と並行にですが、パケットが重複しても問題なく動作するための対策も考案中です。
今考えているのは、過去に受信したパケットを一定期間保持しておき、パケット受信毎に過去のパケットかどうかをチェックするように考えています。
他に何か良い案があれば教えてください。
以上、宜しくお願いします。
98受信OK、99受信OK、100受信OK、98受信NG
となっている部分で・・・
100個目以降（例えば101とか）は送信済で、受信OK待ちとは
なっていないのでしょうか？
また以前の98受信OK返信と98受信NGのどちらを信用するか？
と言う問題もあります。
なぜかと言いますとノイズが多いと言うことはパケットが壊
れていて相手側機器が正常なパケットを受信していない可能
性が高いからです。
要はパケット番号が壊れたとか、データ部のサムチェックが
不一致になったとか・・・
そうなればただ単に無視するのは難しいです。
相手側機器の方でもパケットモニタして、パケット破損の可
能性チェックも必要かと。
● ＦＡ環境でノイズによるパケット異常が発生した場合、
ネットワークケーブルの敷設ミスや、ケーブルのカテゴ
リが仕様を満たしていない場合があります。
100Mなら調査機器も安価で大抵の工事屋は持ってます。
が、私の場合ギガだったので、300万円程度するギガ対応
帯域測定装置を持っている業者探して、ノイズ調査をし
てもらいました。(100Mなら帯域測定は100万を下回る)
確かにノイスはありましたが、ケーブルのカテゴリが要
求を下回っておりましたので、業者負担で再敷設となり
ました。
カテゴリ４ケーブルを最長70mほど数本とりまわしてあり
それをギガで使用していたので・・・もうビックリ！
UDPではなくTCPだったので再送の嵐でネットワークダウン
してました。
高圧電線の取りまわしがあるなら、誘導があるのでケーブ
ルに電位差が発生します。ハブ側とLANカード側で下手した
ら数十ボルト以上電荷がかかるとどちらか、もしくは両方
のポートが壊れる・・・まして落雷があったりすると一気
に焼き切れます。２０台ほどＰＣがつながってましたが、
電位差＋落雷で、６台一気にＬＡＮカードが壊れたことも
ありました。
ギガ使っていないならサージプロテクタ入れたり・・・
ネットワークの工事に対し『お金』かけないと、どうにも
ならないですヨ！
安易にプログラムで対処しても、結果ゼロにはなりません。
そういう問題ではありませんので！
参考まで
根本原因がんばって突き止めます。
ところで最初に書きました質問１に戻りますが、
イーサリアルではFCSやトレーラが見れるということは、見れる方法があるってことですよね。イーサリアルのソースが公開されていれば参考にできるのですが＾＾
イーサリアルもWinPcap使っている（はず）なので
WinPcap使ったキャプチャソフトをお探しになれば？
多分見つかるかと・・・
と書きながら検索・・・
http://codezine.jp/article/detail/126?p=1
VC++ですがありました。
参考まで・・・
追伸・・・RPCAPですが
C#版も発見・・・
http://codezine.jp/article/detail/219?p=1
参考まで。
| ツイート |  |