Geekなぺーじ : 大変革が迫りつつあるインターネット
IPv4アドレス枯渇が迫りつつあります。 現状では、再来年ぐらいに枯渇する事が予想されています。 このIPv4アドレス枯渇は、恐らくインターネットアーキテクチャに対して非常に大きな影響を与えます。 今、この瞬間にあるインターネットインフラと、3年後のインターネットインフラは結構違う形をしているのではないかと推測しています。 以下、何故IPv4アドレス枯渇がインターネットアーキテクチャの大変革をもたらすのかと、この問題の背景を説明したいと思います。 2つに分離するインターネット インターネットは戦時中の物資が少ない状況においても通信網が維持出来る事を想定して設計されています。 そのため、専用機器だけではなく、ありあわせの機器を繋ぎ合わせて通信が実現できることが重要な要素でした。 また、電話のような回線交換方式ではなく、パケット交換方式を採用して様々な種類の通信を同時に行える事も設計の柱でした
Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのか
多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか？ echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ
TechCrunch | Startup and Technology News
Unlike Light’s older phones, the Light III sports a larger OLED display and an NFC chip to make way for future payment tools, as well as a camera.
IPv6 とかよくわからない人間が IPv6 対応サイトを作る際の知っておくべき 8 つの注意点 : にぽたん研究所
先日、一般や企業向けに IPv6 対応を支援をする、EDGE Co.Lab v6 というのを始めました。 これを始めるにあたって、弊社情報環境技術研究室の伊勢さんから、「なんかウチでやってるコンテンツで、どれか IPv6 対応しようよ」と、いきなり言われました。 実は IPv6 って何年も前からよく耳にするけど、特にインフラまわりの知識が拙いし、何だかんだ身の回りのほとんどが IPv4 で、それでまぁウマくいってるからよくわからないし、別にどうでもいい…と、IPv6 に対して「現実味がない。時期尚早なのでは？」みたいな勝手な印象を抱いて、毛嫌いしてました。 伊勢さんは 2ch の IPv6 板とかを立ち上げたらしく、IPv6 でアクセスすると、トップページのひろゆきが踊って表示されるそうです。 IPv6 と IPv4 の差って、ひろゆきが踊るか踊らないかの差だけ？とか、そうじゃないのをわか
DSAS開発者の部屋:いかにして冗長構成を作るか 〜DSASの場合〜
DSASはいかにして可用性を高めているか、ちょっと紹介したいと思います。 今回は概略ということでざざざっと説明します。個別の構成についてはまた回を改めて紹介したいと思います。 │ │ ┌┴┐ ┌┴┐ │ │ │ │ISPの上位ルータ └┬┘ └┬┘ │ │ 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 責任分解点 │ │ ┌┴┐ ┌┴┐ │ ├─[ lb(active) ]─┤ │ │ ├─[ lb(backup) ]─┤ │ │ │ │ │ │L2├─[ Web ]─┤L2│ │SW├─[ Web ]─┤SW│ │ ├─[ Web ]─┤ │ │ │ │ │ │ ├─[ SMTP ]─┤ │ │ ├─[ SMTP ]─┤ │ │ │ │ │ │ ├─[ D B ]─┤ │ │ ├─[ D B ]─┤ │ │ │ │ │ │ ├─[ NFS ]─┤ │ │ ├─[ NFS ]─┤ │ │ │ │ │
C++と Pthreads でミニマルなHTTPサーバを書く - いやなブログ
C++と Pthreads でミニマルなHTTPサーバを書く 『UNIXネットワークプログラミング』を読んでいると、自分でも何かネットワーク系の小さなプログラムを書いてみたくなりました。そこで、ミニマルなHTTPサーバを C++と Pthreads で書いてみました。 同じ著者の「詳解UNIXプログラミング」もそうだったように、今回の本もほとんどすべてのページに、重要なことが書かれています（最後のほうのXTIの部分は例外かもしれませんが）。 たとえば、27章ではネットワークサーバの実装として、次の設計方針がそれぞれ検討され、実際のコード付きで解説されています。 クライアントごとに fork 事前に fork - 各プロセスで accept 事前に fork - ファイルロックで accept を保護 事前に fork - Mutex ロックで accept を保護 (PTHREAD_PRO
最速配信研究会(@yamaz)
ミスリードを誘うタイトルでお送りしております。 トラブル対応は全く無駄だと思う。もちろん「トラブルが起きてるんだからトラブル対応しなきゃに決まってるだろ」といった話ではない。 いきなり話が変わるが、私の奥さんは看護師で、結婚当初私が風邪を引くと優しくしてくれるのかな？と思ってたけど、毎回どえらく怒られていた。曰く 風邪は基本的に予防できる病気 なのに風邪を引くのは怠慢な証拠 風邪を引くと会社休まないとだし、お金も時間も浪費するので本当に意味がない いや、全くごもっともでぐうの音も出ない正論としかいいようがない。 さて翻って、みなさん自身がおもりするシステムの健康をちゃんと見てるだろうか？ 上記の言葉をシステムトラブルに置き換えてみよう。 トラブルは基本的には予防し得る なのにトラブルを起こしてしまうのは怠慢な証拠 トラブルを起こしたら対応にかかるエンジニア工数や顧客対応の工数はドブに捨てて
Cookie仕様 日本語訳
Cookieの仕様は、Netscape Communications Corporation が、 http://wp.netscape.com/newsref/std/cookie_spec.html で公開しております。このドキュメントをfutomiが日本語化したものです。みなさまのCookieの理解に役立てれば幸いです。なお、緑色で記載された文章は、futomiが注釈として加筆したものです。また、一部、直訳ではなく、意訳した部分がございます。原文と表現がことなることがございますので、ご了承ください。 注意: この日本語訳は、futomiがCookieの理解を深めるために、自分なりに日本語にしたものです。本日本語訳には、翻訳上の誤りがある可能性があります。したがって、内容について一切保証をするものではありません。正確さを求める場合には、必ず原文を参照してください。当方は、この文書によっ
ethna.jpやjp2.php.netに発生したトラブルについて - maru.cc@はてな
本日起こった、ethna.jp や、jp2.php.net のサイトに、ActiveX や Flash の脆弱性をついた攻撃をする html を読み込む iframeを差し込まれるというトラブルが発生しました。 ちょっとかかわったので、流れを記録として残しておこうと思います。 ethna.jpの第一報 10:30ごろ、%Ethna のIRCチャンネルで、mikaponさんから、mlの保存書庫に不正な iframe が差し込まれているという報告がありました。 10:31 (mikapon) おはようございます 10:32 (mikapon) ethnaのサイトなんですが 10:32 (mikapon) mlの保存書庫の所にiframe埋め込まれてませんか？ ちょうど出社中の時間で、この発言をリアルタイムでは見れなかったのですが、土曜日に tiarra を入れたおかげで、発言を見ることが出来ま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RFC 検索
http://www.nextcom.co.jp/tools/addr.htm