Programming UNIX Sockets in C - Frequently Asked Questions
Created by Vic Metcalfe, Andrew Gierth and other contributers (Transrated into Japanese by: Keisuke Mori)May 21, 1998 この文書は、UNIX 上での ソケットインターフェースを用いた TCP/IP アプリケーションプログラミングについて、頻繁に行われる質問とその 解答を集めたものです。 1. 一般的な情報と概念 1.1 更新情報 1.2 この FAQ について 1.3 この FAQ はどのような人向けでしょうか? 1.4 ソケットって何ですか? 1.5 ソケットはどのように動作するのでしょうか? 1.6 [ある本の題名] という本のソースコードはどこから取得できますか? 1.7 どこでもっと情報を得ることができますか? 2. クライアントとサーバ(TCP/SOCK_STREA
Re はやいTCPサーバの書き方 - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ について、いくつか気になった点があったので。 Nagleアルゴリズムは、相手側のACK送信をまとめてくれるものです。これは、下記の様にアプリケーション側でパケットを意識した処理を行っている場合、邪魔になることがあります。 違うと思います。自分の理解では、Nagle アルゴリズムは、ACK を受信していないデータがある場合に、次のパケットを送信しない、というものです。RFC896 から引用すると、 The solution is to inhibit the sending of new TCP segments when new outgoing data arrives from the user if any previously transmitted data on the connection remains unackn
*BSD で kqueue・kevent を使ってみよう
*BSD で kqueue・kevent を使ってみよう select() の欠点 select() は複数のディスクリプタをポーリングできる便利なシステムコールです。 しかしパフォーマンスはよくありません。理由は以下の通りです。 ユーザプロセスは、監視対象のディスクリプタ一覧をユーザ領域からカーネル領域にコピーする必要がある。 カーネルがポーリング結果をユーザ領域に返す際もコピーしなければならない。 カーネルは、ポーリング対象のディスクリプタを知るために、配列の全要素を調べなければならない。 ユーザプロセスも、入出力可能なディスクリプタを知るために、配列の全要素を調べなければならない。 上記の作業は、select() を発行するたびに毎回行わなければならない。 select() のパフォーマンスが悪いことは広く知られていたので、 各 OS でいろいろな取り組みが行われてきました。 Sol
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
Programming UNIX Sockets in C - Frequently Asked Questions: クライアントとサーバ(TCP/SOCK_STREAM)両方に関する質問
Previous Next Table of Contents 2. クライアントとサーバ(TCP/SOCK_STREAM)両方に関する質問 2.1 相手側のソケットが閉じられたことをどうやって知ることができますか? Andrew Gierth 氏 ( andrew@erlenstar.demon.co.uk) より: 私の知る限り… 相手側が (SO_LINGER を使ったややこしいことをしないで) close() するか終了したとすると、こちらの read() の呼び 出しは 0 を返すはずです。同じ場合で、write() 呼び出しで何が 起こるかは、もうちょっとわかりづらいです。直後の呼び出し時ではな く、その次の呼び出し時にEPIPE が返るでしょう。 もし相手が再起動するか l_onoff = 1, l_linger = 0 を設定して から閉じたとすると、read() からは(
はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ で id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、 接続のタイムアウト処理 ログの出力 メモリの確保や解放をやらない あたりにも気を配る必要がある、と思います。 接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件 に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。 ログの出力について、複数行を１回のシステムコールにまとめてもいいかど
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
