lengthのながさ
Hideo Sir MaNMOS Morishita
＃あぁあ変なSubject
森下 お代官様 ＭａＮＭＯＳです。
設計の話です。
データや、通信のプロトコルなどで、レーコド数やオクテット数をそのデータ
内に含めることは少なくないわけですが、その数値自体を含めたヘッダ長など
も、それに含めるかどうかは別れてくると思うのです。
私としては、lengthにヘッダ長等を含めた形にするプロトコル(やファイル形
式) を定義することが多いのですが、皆さんどうなんでしょう？
最近、外からもらう仕様は、それらのデータが含まれていない。というか、
「仕様書に、どういう数値か書いてないんですけど、headerとtrailerを含め
ますか？」って聞いたら「普通、入れないでしょう。」見たいなことをいわれ
るんです。
私が最近使う(実装する)プロトコルでは、
ip、udp、radius、eapol、eap、ppp、tls(ssl)、asn1(snmp他)
ファイル形式では
snoop、X509(ってASN1 DERやん)
とlengthにヘッダ長を含みます。世の中、これが普通なんだと信じてたんです
が…
＃＃で、ちょっとぶっ飛んだのがMobile IP。
＃＃まず、全体長はどこにもない。で各extentionにあるlengthが…普通の
＃＃extentionとnormal vendor specificは良いとしよう。critical vendor
＃＃specificは…気になる方はrfc3320をどーぞ。
--
___ わしは、山吹色のかすてーらが大好きでのぅ
[[o o]] ふぉっふぉっふぉ
'J' 森下 お代官様 ＭａＮＭＯＳ 英夫＠ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D 02 74 87 52 7C B7 39 37
Shinji KONO
In article <squbquy...@stellar.co.jp>, man...@stellar.co.jp (Hideo "Sir MaNMOS" Morishita) writes
> データや、通信のプロトコルなどで、レーコド数やオクテット数をそのデータ
> 内に含めることは少なくないわけですが、その数値自体を含めたヘッダ長など
> も、それに含めるかどうかは別れてくると思うのです。
最初は「ヘッダーも含める」派だったんですが、最近、ちょっと
態度が変わりました。
ヘッダは大体固定長ですよね。可変になるのはデータ部分。これを
可変長文字列で受けるとすると、
read header size
で、ヘッダから length を取得
length 分の可変長文字列を用意
read body
ってことになると思います。
ま、計算すれば良いだけなんで別に良いんですけどね。前は、
header の最初に全体のパケット長を入れて、
とりあえず、4byte 読んで長さを見る
全体を読み込んで、データ部分をコピーまたは
データ部分へのポインタと長さを渡す
ってやってたんだけど、それだと、パケットのfreeが面倒。
あと、Java だと部分文字列へのポインタみたいなのを真似しようと
すると面倒だし。
なので、
> 最近、外からもらう仕様は、それらのデータが含まれていない。というか、
> 「仕様書に、どういう数値か書いてないんですけど、headerとtrailerを含め
> ますか？」って聞いたら「普通、入れないでしょう。」見たいなことをいわれ
> るんです。
と言うことになっているんじゃないでしょうか。
---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科
to...@lbm.go.jp
>＃あぁあ変なSubject
「lengthの測り方」とか「lengthの数え方」くらいにしとけば良かったかも
>データや、通信のプロトコルなどで、レーコド数やオクテット数をそのデータ
>内に含めることは少なくないわけですが、その数値自体を含めたヘッダ長など
>も、それに含めるかどうかは別れてくると思うのです。
>最近、外からもらう仕様は、それらのデータが含まれていない。というか、
>「仕様書に、どういう数値か書いてないんですけど、headerとtrailerを含め
>ますか？」って聞いたら「普通、入れないでしょう。」見たいなことをいわれ
>るんです。
それはヒドいですね。
「入れるか入れないか」書いてないなんて、明白な欠陥仕様だと思います。
>私が最近使う(実装する)プロトコルでは、
>
>ip、udp、radius、eapol、eap、ppp、tls(ssl)、asn1(snmp他)
>
>ファイル形式では
>snoop、X509(ってASN1 DERやん)
>
>とlengthにヘッダ長を含みます。世の中、これが普通なんだと信じてたんです
>が…
ファイル形式として「AppleDouble/AppleSingle」「MacBinary」「BinHex」を
見てみたんですが、参考にならなかった^_^;
何故かというと、
いずれも「長さフィールド」が「実体」と隣接していないんです。
こういう場合には、当然「ヘッダは含まない」に決まってます。
詳しく言うと、
いずれも全体のヘッダが“固定長”または“固定長パターンの反復”になっていて、
「全体長」を直接記述するフィールドは存在せず、
各データバートの長さは、全体のヘッダの中で集中管理されているわけです。
ちなみに、「BinHex」では、各データバート実体の直後にCRCが来るんですが、
ヘッダに記述されるデータ長は、このCRCを含みません。
この部分は、お代官様の「普通」には属さないかも。
別のファイル形式として、
FACOMの大型汎用計算機（懐かしい名前だ^_^;）における
可変長ファイル（ということは、HITACやIBMも多分同じ）では、
ファイルオープン時に指定する「レコード長（＝許容最大値）」には、
各レコードに付加されるヘッダの長さが含まれます。
ですが、ヘッダ自身に記載される実レコード長がどうだったかは、
手元に資料が無く、判りません。
MacintoshのHFSにおけるResourceForkに含まれる各ResourceDataは、
長さヘッダに続いて実体が来ますが、
この「長さ」にはヘッダは含まれません。
仕様書には「Length of following resource data」とあります。
この「following」という言葉で「含まない」ことを明示しているつもりかな？
戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp
Eiji KATSURA
man...@stellar.co.jpさんは書きました。
> データや、通信のプロトコルなどで、レーコド数やオクテット数をそのデータ
> 内に含めることは少なくないわけですが、その数値自体を含めたヘッダ長など
> も、それに含めるかどうかは別れてくると思うのです。
>
> 私としては、lengthにヘッダ長等を含めた形にするプロトコル(やファイル形
> 式) を定義することが多いのですが、皆さんどうなんでしょう？
たまに、長さのフィールドが可変長のことってないですか？
128以下なら 1バイト それ以上なら 2バイトみたいな。
そんなときに、ヘッダの長さまで length に含めると、
同じデータに対して、二通りの表現ができてしまうという、ちょっと
気持ち悪い現象が起きたりして、ちょっといやかな、ということは
あります。
> 最近、外からもらう仕様は、それらのデータが含まれていない。というか、
> 「仕様書に、どういう数値か書いてないんですけど、headerとtrailerを含め
> ますか？」って聞いたら「普通、入れないでしょう。」見たいなことをいわれ
> るんです。
なので、私も「普通、入れないでしょう。」派かな。
桂 英治＠(株)横浜インテリジェンス ( kat...@hamaint.co.jp )
Hideo Sir MaNMOS Morishita
In article <3992789...@rananim.ie.u-ryukyu.ac.jp>,
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> 河野真治 @ 琉球大学情報工学です。
>
> In article <squbquy...@stellar.co.jp>, man...@stellar.co.jp (Hideo "Sir MaNMOS" Morishita) writes
> > データや、通信のプロトコルなどで、レーコド数やオクテット数をそのデータ
> > 内に含めることは少なくないわけですが、その数値自体を含めたヘッダ長など
> > も、それに含めるかどうかは別れてくると思うのです。
>
> 最初は「ヘッダーも含める」派だったんですが、最近、ちょっと
> 態度が変わりました。
>
> ヘッダは大体固定長ですよね。可変になるのはデータ部分。これを
> 可変長文字列で受けるとすると、
> read header size
> で、ヘッダから length を取得
> length 分の可変長文字列を用意
> read body
> ってことになると思います。
例えばIPv4はヘッダが可変長ですよね。v6はヘッダがチェーンになってるけど。
こういう場合は明らかにヘッダ長を含めた方が楽なんですよね。とくにIPだと
streamみたいに、「切れ目」がわからないのでヘッダを読んでから、ボディを
読むっていう行為は必要がないのも大きい。
どうも、私はUDP(または生ipとかether packet)/SCTP系のプロトコルを扱うこ
とが少なくないので、データ全体を確保して、ポインタをずらすだけ、って話
が多いから「ヘッダ長はlength に含む」が楽なのかも知れないと、元ネタを
ポストしてから思いました。
＃ただ、SCTPはLinuxとSolaris/MacOS-Xでプログラミングスタイルがまだ一定
＃してないんで書きにくい。
>
> ま、計算すれば良いだけなんで別に良いんですけどね。前は、
>
> header の最初に全体のパケット長を入れて、
> とりあえず、4byte 読んで長さを見る
> 全体を読み込んで、データ部分をコピーまたは
> データ部分へのポインタと長さを渡す
>
> ってやってたんだけど、それだと、パケットのfreeが面倒。
>
ああ、そういう場面の場合はmallocじゃなくてallocaを使うことが多いです。
私はjavaやらないからなぁ。
> あと、Java だと部分文字列へのポインタみたいなのを真似しようと
> すると面倒だし。
assembler/c出身者からポインタを取り上げたら、何も残りません。きっと。
ちなみにbasicでプログラムを書いている時も、文字列のアドレスを直にとっ
てきて文字列を変更したり、文字列に機械語を仕込んで、そこにcallをかけた
り。
> なので、
>
> > 最近、外からもらう仕様は、それらのデータが含まれていない。というか、
> > 「仕様書に、どういう数値か書いてないんですけど、headerとtrailerを含め
> > ますか？」って聞いたら「普通、入れないでしょう。」見たいなことをいわれ
> > るんです。
>
> と言うことになっているんじゃないでしょうか。
まあ、この仕様書の場合は、そんなことは全然関係なかったんですけどね。
Hideo Sir MaNMOS Morishita
In article <e252op$ct6$1...@bluegill.lbm.go.jp>,
to...@lbm.go.jp writes:
> In article <squbquy...@stellar.co.jp> man...@stellar.co.jp writes:
> >＃あぁあ変なSubject
> 「lengthの測り方」とか「lengthの数え方」くらいにしとけば良かったかも
Inclede itself!とかかっこ良かったかなぁ。
> >データや、通信のプロトコルなどで、レーコド数やオクテット数をそのデータ
> >内に含めることは少なくないわけですが、その数値自体を含めたヘッダ長など
> >も、それに含めるかどうかは別れてくると思うのです。
>
> >最近、外からもらう仕様は、それらのデータが含まれていない。というか、
> >「仕様書に、どういう数値か書いてないんですけど、headerとtrailerを含め
> >ますか？」って聞いたら「普通、入れないでしょう。」見たいなことをいわれ
> >るんです。
> それはヒドいですね。
> 「入れるか入れないか」書いてないなんて、明白な欠陥仕様だと思います。
「普通、入れない」ので…
そんなのに慣れてないと、受注プログラムはかけません。シクシク。
＃ヘタをすると、「headerとtrailerを含めますか？」って聞いても、その意
＃味すら理解してくれない人は少なくないんです。それが「SE」さんの現状。
> ファイル形式として「AppleDouble/AppleSingle」「MacBinary」「BinHex」を
> 見てみたんですが、参考にならなかった^_^;
> 何故かというと、
> いずれも「長さフィールド」が「実体」と隣接していないんです。
> こういう場合には、当然「ヘッダは含まない」に決まってます。
これは当然ですよね。
> 詳しく言うと、
> いずれも全体のヘッダが“固定長”または“固定長パターンの反復”になっていて、
> 「全体長」を直接記述するフィールドは存在せず、
> 各データバートの長さは、全体のヘッダの中で集中管理されているわけです。
昔、(fjでも流したような気がするけど)ある(今はなき)ワープロ屋さんのベク
トルフォントをghostscriptで利用するっていうドライバを書いた時、前の方
に、データのオフセットが書かれてて(長さもだったかなぁ)そこから拾ってき
たのを覚えています。(データ自体も少し変わってたなぁ。10bitで読み出す場
合と12bitで読み出す場合が混在してたり、座標がなんか変だったり。)
ランダムアクセスがメインだって場合はこの方が扱いやすいんですよね。当然。
でも、ストリームとして扱う場合はレコード数のチェックをしたり、なかなか、
やりたくないです。
> ちなみに、「BinHex」では、各データバート実体の直後にCRCが来るんですが、
> ヘッダに記述されるデータ長は、このCRCを含みません。
> この部分は、お代官様の「普通」には属さないかも。
ヘッダを含めてtrailerを含めないのは、プログラムを作る上では、「有り」
かも知れません。別々のデータとtrailerは領域に読んでおきたいしなぁ。と
か。
> MacintoshのHFSにおけるResourceForkに含まれる各ResourceDataは、
> 長さヘッダに続いて実体が来ますが、
> この「長さ」にはヘッダは含まれません。
> 仕様書には「Length of following resource data」とあります。
> この「following」という言葉で「含まない」ことを明示しているつもりかな？
rfcでも、そのような書き方を見ることは少なくないです。すぐに、どれ、っ
てのは出てきませんが。
Hideo Sir MaNMOS Morishita
In article <0604192007...@mail.hamaint.co.jp>,
Eiji KATSURA <blackhole(I_dont_read_mails)@hamaint.co.jp> writes:
> <squbquy...@stellar.co.jp>の記事において
> man...@stellar.co.jpさんは書きました。
>
> > データや、通信のプロトコルなどで、レーコド数やオクテット数をそのデータ
> > 内に含めることは少なくないわけですが、その数値自体を含めたヘッダ長など
> > も、それに含めるかどうかは別れてくると思うのです。
> >
> > 私としては、lengthにヘッダ長等を含めた形にするプロトコル(やファイル形
> > 式) を定義することが多いのですが、皆さんどうなんでしょう？
>
> たまに、長さのフィールドが可変長のことってないですか？
> 128以下なら 1バイト それ以上なら 2バイトみたいな。
> そんなときに、ヘッダの長さまで length に含めると、
> 同じデータに対して、二通りの表現ができてしまうという、ちょっと
> 気持ち悪い現象が起きたりして、ちょっといやかな、ということは
> あります。
asn1はそうですね。って書いて、あ、asn1は「含まない」タイプでした。
＃さすがに、補正に次ぐ補正なんて苦労をした覚えはない…
まあ、asn1はtype-length-valueだけなので、「ヘッダ」と呼べるものもあま
りないのですが。
typeとlegnthの間にlengthのlength(あ、この記事のSubjectみたい)が入った
りもしますが。
> > 最近、外からもらう仕様は、それらのデータが含まれていない。というか、
> > 「仕様書に、どういう数値か書いてないんですけど、headerとtrailerを含め
> > ますか？」って聞いたら「普通、入れないでしょう。」見たいなことをいわれ
> > るんです。
>
> なので、私も「普通、入れないでしょう。」派かな。
うう。「入れる派」あやうし。