4

getlineと同じことをするが、FILE *ストリームの代わりに接続されたソケットで動作するlibc関数はありますか？

回避策は、ソケットでfdopenを呼び出すことです。そうするとき、世話をしなければならないことは何ですか。それをする/しない理由は何ですか。

それを行う明らかな理由の1つは、getlineとcoを呼び出すことですが、カスタムgetlineを書き直す方がよいのではないでしょうか。

4

3 に答える 3

4

ソケットで読み取りを呼び出すと、時期尚早にゼロ値を返す可能性があります。例えば。

 read(fd, buf, bufsize)

tcpソケットのカーネルバッファがいっぱいの場合、bufsize未満の値を返すことができます。このような場合、ゼロまたは負の結果を返さない限り、読み取り関数を再度呼び出す必要がある場合があります。

したがって、stdio関数は避けるのが最善です。bufsizeバイトを確実に取得するために、readへの反復呼び出しを実装するには、read関数のラッパーを作成する必要があります。ファイルがローカルディスクから読み取られているかのように、ソケットからそれ以上バイトを読み取ることができない場合にのみ、ゼロ値を返す必要があります。

ラッパーは、RandalBryant著の『Computer Systems：A Programmer's Perspective』にあります。

ソースコードはこのサイトで入手できます。rio_で始まる関数を探します。

于 2009-10-19T16:10:30.660 に答える
3

ソケットが信頼できない入力に接続されている場合は、任意の時間枠内の任意の入力に備えてください

  • \ r\nの前の\0文字
  • \rまたは\nのいずれかを永遠に待つ
  • 他の潜在的に醜いもの

任意のタイミングと任意のデータに対処する1つの方法は、たとえばselect（2）を介して読み取りにタイムアウトを提供し、実際に受信したデータをバイトごとに適切に記述されたステートマシンにフィードすることです。

于 2009-10-19T15:26:23.867 に答える
2

問題は、改行を受け取らない場合（\nまたは\r \ n、実装によって異なります）、プログラムがハングすることです。select（）を呼び出して、ソケットがまだ読み取り/書き込み可能であり、エラーがないかどうかを確認する独自のバージョンを作成します。実際には、別の「\n」または「\r \ n」が来るかどうかを判断する方法がないため、クライアント/サーバーからのデータに一貫性があることを確認してください。

getline（）を使用してヘッダーを読み取るWebサーバーをコーディングしたとします。攻撃者が単純に送信した場合

GET / HTTP/1.1\r\n
This line isn't terminated: bla

getlineの呼び出しは二度と戻らず、プログラムはハングします。おそらくリソースのコストがかかり、最終的にはDoSが可能になります。

于 2009-10-19T15:05:46.720 に答える