4

ソケットを操作するときは、C標準のI / O関数（ fprintf()、など）を使用すべきではないとよく言われます。fscanf()

理由がわかりません。理由がバッファリングされた性質にあるとしたら、出力するたびに出力バッファをフラッシュすることができると思いますよね？

なぜ誰もが代わりにUNIXI/ O機能を使用するのですか？標準のC関数の使用が適切で正しい状況はありますか？

4

4 に答える 4

8

あなたは確かstdioにソケットで使うことができます。stdinとだけを使用するプログラムを作成し、（とにソケットを提供する）から実行することもできます。このプログラムは、ソケットstdoutコードがまったく含まれていなくても機能します。inetdSTDIN_FILENOSTDOUT_FILENO

できないのは、バッファ付きI / Oをと混合することです。これは、がないselectか、作業中であるためです。また、入力バッファが空かどうかを確認するためのクエリを実行する標準的な方法がないため、自分で実装することもできません。pollfselectfpollFILE *FILE *

複数の接続を処理する必要があるとすぐに、stdio十分ではありません。

于 2012-08-19T20:35:50.803 に答える
3

1つのソケットがブロッキングモードである単純なシナリオがあり、アプリケーションプロトコルがテキストベースである場合は、まったく問題ありません。

1つ以上のソケットまたは非ブロッキングソケット、あらゆる種類のバイナリエンコーディング、および実際のパフォーマンス要件では、すぐに大きな問題になります。

于 2012-08-19T20:57:08.480 に答える
2

直接の異議を知らない。ほとんどの場合、これは正常に機能します。

同時に、独自のバッファがあり、ファイル記述子層の上にとどまってfprintf()いるプラ​​ットフォームを想像することができます。fscanf()これらのバッファをフラッシュできない場合があります。

考えられるすべてのプラットフォームについて話すのは難しいです。これは、ソケットではこれを回避する方がよいことを意味します。

一日の終わりに、アプリプログラムはアプリの問題を解決する必要があります。コンパイラ/ライブラリのテストではありません。

于 2012-08-19T20:35:01.210 に答える
0

これは、ソケット（TCPソケットなど）がファイルやパイプであるかのように読み取りと書き込みができるためですが、これは単なる抽象概念です。ネットワーク接続の内部動作は、ローカルファイルやパイプよりもはるかに複雑です。

まず、ファイルの読み取りは常に「高速」であり、データを取得するか、ファイルの終わりをバンプします。一方、TCP接続から500バイトを期待し、それが499を送信する場合（および接続が閉じられていない場合）、永遠に待機している可能性があります。書き込みも同じです。TCP出力バッファの後でブロックされます。

最も基本的なプログラムでさえ、タイムアウト、切断を処理する必要があり、これらすべてがFILE自体のバッファリングされたI / Oと相互作用し、教科書の例でさえうまく機能することは期待できません。

于 2013-12-13T13:43:05.397 に答える