Geekなぺーじ : 拙著「Linuxネットワークプログラミング」の紹介
拙著「Linuxネットワークプログラミング」に関する情報ページです。 サンプルプログラムダウンロード、はじめに/目次/Chapter 1～3までのサンプルPDF、書籍中の間違いに関する情報を扱っています。 参考：拙著に関して発売時に書いたブログ記事。拙著中のコラムを書く過程で書いたブログ記事「いいから殺せ。後はこっちでなんとかするから」。 サンプルプログラム (間違い箇所の修正対応済み) まとめてダウンロード(tar.gz) 2-2 IPv4＋TCPによるソケット実装例 2-4 ファイルディスクリプタが0となる場合 2-5 単純なTCPサーバの実装 2-6 単純なTCPクライアントの実装 2-9 socket()システムコールを失敗させる 2-10 注意すべきエラー処理 2-11 printfをperrorの前に実行したケース 2-12 bind()を行わない場合 2-19 単純な名前解決
モダンネットワークプログラミング入門 WEB+DB PRESS vol.55 - Blog by Sadayuki Furuhashi
先日も少し書きましたが、WEB+DB PRESS vol.55 で特集記事を執筆させていただきました。本日発売です。 タイトルは、モダンネットワークプログラミング入門です。 マルチコアCPUから最高の性能を引き出す 本特集では，マルチコアCPUの性能を存分に引き出し，大量のクライアントからの莫大な数のアクセスにさらされても，常に爆発的な性能を発揮する先進的なネットワークプログラムの書き方を，実践的な実装パターンとしてやさしく解説します。 WEB+DB PRESS vol.55 特集3 弾さんの連載最終回は、えとらぼの皆さんです^^; 目次 第1章：ネットワークプログラミングの基礎知識 なぜいま「ネットワークプログラミング」なのか 第2章：ソケットAPI ネットワークプログラミングの基本を押さえる 第3章：ネットワークプログラムのI/O戦略 非同期，並列，イベント駆動，マルチスレッド 第4章
Linux / UNIX & ネットワーク 参考サイト
Linux / UNIX & ネットワーク 関連の参考サイトと書籍 最終更新 : 2006/3/18 Linux / UNIX & ネットワーク 関連で、 主にソフトウェア開発者向けの参考サイトや書籍等の紹介とリンクです。 0. 目次 書籍 プログラミング Linux 情報・解説 用語等の検索（日本語） 用語等の検索（英語） 用語集 RFC ネットワーク 情報・解説 GNU GPL などのオープンソース Apache などのWebサーバ関連 団体 1. 書籍 詳解 UNIXプログラミング ... 「Advanced Programming in the UNIX Environment(1st ed.)」 の邦訳。名著です。UNIX系のプログラミングをする際には必ず机の上に置いておきたい一冊。 UNIX ネットワークプログラミング 第２版 Vol.1
poll/epoll/kqueueを任意に切り替えられるコード - Blog by Sadayuki Furuhashi
ネットワークで通信するプログラムを書いていると、ファイルディスクリプタ（ネットワークならソケット）をselectやpollで監視して、パケットが届いたら何かする、ということが良くあります。 しかしselectやpollは、*BSD で kqueue・kevent を使ってみようで書かれているように、どうも遅いらしい。C10K問題が取りざたされている昨今、Linuxにはepoll、BSDにはkqueue、Solarisには/dev/pollというより高速な仕組みが用意されているのですが、epollを使ってしまうとLinuxでしか動かないし、kqueueで書くとBSDでしか動かない。 というわけで、epollもkqueueも同じインターフェースで使えて、#defineで簡単に中身を切り替えられると嬉しい、とは誰しも一度は思うはず。そうに違いない。 もちろん先人も同じことを考えており、libev
RPC サーバの遅延リターン - steps to phantasien(2009-07-04)
最近は過労気味でウェブにものを書くこともできない, という話で上司の同情を誘うべく 日本人の労働時間やストレスの実態をまとめた エンドレス・ワーカーズ を読んだら, 自分の労働時間は日本人労働者の上位 2 割から漏れていることを知り愕然とした. あんなに働いたってのに...残業エリートへの道は険しい. 道を進みたいわけじゃないけれど. (平均は越えてたぜ!) いずれにせよ流行からはすっかり脱落しているので, 時流を無視して仕事の話でもしよう. 以前, 会社の blog で RPC の結果をノンブロッキングスタイルで受け取るプリミティブ "弱関数" を提案した. でも試行錯誤の結果, いまは使っていない. C++ での弱参照は意図しないリークを作りやすい. 使いわすれることも多く, 忘れた頃にクラッシュする. 要求は明示的にキャンセルした方がいいことがわかった. (世間はみんなそうやってます
ネットワークプログラムのI/O戦略 - sdyuki-devel
図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド･イベント駆動 コネクションN：スレッド１。epoll/kqueue/select を１つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える： サーバーにメッセージを送信 イベントハンドラを登録；このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す １コネクション１スレッ
はてなブログ | 無料ブログを作成しよう
【献血デビュー】体重が少し足りず400ml献血はできなくとも、献血ルームでの成分献血ならできたぞ、という話 いきさつ 2025年の抱負として「400ml献血をできるようになる」を掲げてから、冬を越し春が過ぎ夏が終わ………なかなか終わらないな……8月も終わろうとしている。記事を書いた頃の体重からは1kgぐらい増えたところだ。 夏バテなんてどこ吹く風とばかりに、ここ数週間は私の…
ネットワークプログラミングの基礎知識
ネットワークプログラミングの基礎知識 ここでは IP アドレスやポート番号、クライアントとサーバの役割などを説明し、 perl・C言語・Java などでソケット (Socket) を使った HTTP クライアントや POP3 クライアント、簡単なサーバを作成してみます。 要はネットワークプログラミングをやってみよう、ということです。 このページのサンプルプログラムは、RFC などの規格に準拠した「正しい」プログラムではありません。 また、全体的にエラー処理が不十分です (今後改善する予定です)。 あくまでも概要を理解するためのサンプルととらえてください。 もし本気でしっかりとしたクライアントやサーバを書きたいなら、このページを読んだ上で、 さらに RFC を熟読し、そして wget・Apache・ftp コマンドなどのソースを参考にしてください。 このページに間違いを見付けたら、掲示板 で
TCP/IP エラー処理 connect 編
connect(2) のエラー TCP において connect(2) 呼出し時に発生する可能性のあるエラーは以下の通りです。 タイムアウト RST 受信 EHOSTUNREACH また ENETUNREACH シグナル受信 その他 まず、connect(2) 時の正常な流れをしっかり覚えておいてください。 (connect(2) を呼んで) SYN を送る SYN+ACK が返ってくる (ここで connect(2) から戻る) ACK を送る タイムアウト もし仮に、SYN を送ったものの、相手側から SYN+ACK が返ってこない場合は、 (ローカルの TCP スタックが) しつこく SYN を再送します。何度 SYN を送っても SYN+ACK が返ってこない場合はあきらめてタイムアウトします。 「SYN+ACK が返ってこない」というのは、例えば以下のようなケースが考えられます。
はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ で id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、 接続のタイムアウト処理 ログの出力 メモリの確保や解放をやらない あたりにも気を配る必要がある、と思います。 接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件 に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。 ログの出力について、複数行を１回のシステムコールにまとめてもいいかど
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
はやいTCPサーバの書き方 - nyaxtのPC作業ログ
cagra高速化にあたってのノウハウを一部公開してみます。また明日校正/更新します。つっこみ待ちです。 select(2)の代わりにepoll_wait(2), kqueue, /dev/epoll等を使う 他に山ほど解説ページがあるので略 大量のディスクリプタを処理するようなサーバの場合、多少効果があるかもしれません。しかし、クライアント数が少ない場合、劇的な性能の向上は見込めないとおもいます。クライアント数が多い場合は、１セッション１スレッドなモデルではOS側のタスクスイッチングのオーバーヘッドが効いてくることも多いです。クライアント数を増やすには複数のセッションを１スレッドで処理できるようにすると良いです。実装にあたっては、non-blocking ioを活用すると効果的です。 TCP_NODELAYを設定する Nagleアルゴリズムをオフにします。多少応答性が良くなります。 これっ
システムプログラム (2008年)
このページは、 筑波大学／ 情報学類開設の 講義、「システムプログラム」の授業のためのページです。 この科目は、 新城 と 追川の２人で 担当します。 ■シラバス ■レポート ■授業内容メモ 前半5回分（4月16,23,30日, 5月7,14日） 5月20日 ネットワーク・プログラミング／クライアント側 5月28日 ネットワーク・プログラミング／サーバ側 6月 4日 ネットワーク・プログラミング／UDP/IP 6月11日 ＷＷＷプログラミング 6月18日 スクリプト言語 ■関連ページ 主専攻実験：システムプログラム(2008年) 去年のシステムプログラムのページ(2007年) 筑波大学 情報学類 情報学類／情報科学類授業科目一覧（シラバス） システム情報工学研究科 コンピュータサイエンス専攻 追川のホーム・ページ 新城のホーム・ページ Last updated: 2008/04/02 17
マルチコア時代の高速サーバーの実装 - Blog by Sadayuki Furuhashi
特にサーバー用途では、CPUがシングルコアに戻ってくることは考えにくい。 マルチコアCPUの性能を活かすにはマルチスレッドに対応したサーバーの実装が必要になるわけですが、マルチスレッドなプログラミングは往々にして「高負荷になると固まる」とか「たまに落ちる」といった悩ましいバグと戦わなければならず、イヤです。 かといってシングルスレッドでは、近い将来 32コアCPU! などが出てきたとき、たぶん性能を発揮できません。 そこで、そこそこデバッグしやすく、それでいて多コアCPUでもスケールするという落としどころを模索しているのですが、ボトルネックはネットワークIO周りにあるだろう*1という前提の元で、ネットワークIO部分だけをマルチスレッドで動かし、それ以外の部分をシングルスレッドで動かすというアーキテクチャを考えています。 ロジックの部分はマルチスレッドで書いても共有リソースにアクセスする度に
- Backnumbers: Steps to Phantasien
2008-12-20 近況 WEB+DB PRESS Vol.48 に記事を書かせてもらいました. デバッグをねたに, という話だったのだけれど, デバッグのような辛い記憶はすぐに忘れてしまうので無理です...とごねて その手前, エラー処理の話を書いてみました. 他の方はちゃんとデバッグの話を書いていてえらい... おまえはいつから Web とか DB をやるようになったんだという指摘は甘受いたします. なぜ RPC はいまいちか (今更編) WEB+DB Press には REST の連載があり, 今号は RPC の話だった. その記事を読んでいるうちに, 以前書いた 少し関係のある話 が途中だったのを思いだした. 元の記事は REST vs. RPC の議論だったけれど, REST はさておき RPC はどんな場合にいまいちか, すこし書いてみたい. 多くの RPC は, だいたい次
ミニマルなHTTPサーバ - かそくそうち
http://0xcc.net/blog/archives/000178.html このコードには長時間動作させる上で明らかにマズい点が二つあります。 (22:58追記: 問題のコードは既に修正されています。高林さん、すばやい対応ありがとうございます。) 「UNIXネットワークプログラミング」の別の節に解説はありますが、コードだけコピペした人が困らないよう指摘しておきます。 一つ目はSIGPIPEシグナルの発生に備えていない点です。 サーバーがレスポンスを返す前にクライアントがソケットを閉じてしまうと、write()がSIGPIPEシグナルを生成することがあります。 SIGPIPEの既定の動作はプロセスの終了なので、この状況が発生しただけでサーバーは勝手に(coreを残さず)終了してしまいます。 通常は次のような関数でSIGPIPEを無視します。 #include <cstring> #i
Erlang で memcached を作ってみました。 : DSAS開発者の部屋
先日、こちらの Erlang の世界ではmemcachedとか要らない を興味深く読ませて頂きました。 たしかにクライアント側も Erlang で書かれている場合、例えばキャッシュサー バーにアクセスを行う WEB アプリケーションも Erlang で書かれていれば Erlang のプロセス間通信を使用することで簡単にキャッシュサーバを実装する ことが出来そうです。しかし、WEB アプリケーションなど、全てのシステムを Erlang で書くにはまだ私にとって勇気が要る事なので TCP/IP で memcache プ ロトコルを喋る Erlang 版 memcached を作ってみました。 その名も ememcached です。 % ememcached.erl -module(ememcached). -export([start/0, ememcached/1, process_comm
ithreads でスレッドプール - naoyaのはてなダイアリー
マルチスレッドなサーバー実装を色々模索していて、Perl の ithreads で遊ぶ。ithreads は Linux の pthread にリンクさせた perl なら一応 NPTL で動いてくれるので、pthread アプリケーションの設計を試すのにも良い。 試しににやってみたのは、たとえば mod_perl とかで重い SQL でブロックするのが嫌なときとかにそれを別プロセスに丸投げしてやる、その丸投げされる側のサーバー実装。(やりたいことだけに関して言うと、TheSchwartz に似てる) クライアントとサーバーの IPC は UNIX ドメインソケット メッセージングのプロトコルは JSON サーバーはクライアントからのリクエストをバッファリングしたら、SQL を実行する前にクライアントとの接続を切断 この時点でクライアントは制御が戻る サーバーは内部ではフロントエンド /
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
https://labs.cybozu.co.jp/blog/kazuho/archives/2007/09/cache_and_thundering_herd.php