日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
DMM inside
日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
なぜ「DNSの浸透」は問題視されるのか:Geekなぺーじ
「DNSの浸透」という表現が結構よく使われています。 DNSに設定された情報を更新したけれど、その結果がなかなか反映されずに誰かに相談すると「DNSの浸透には時間がかかります」と説明されて納得してしまうという事例が多いようです。 しかし、うまく準備を行えば、実際の切り替え処理は、いつ完了するのかが不明な「DNSの浸透」を待つのではなく、事前に計画した時間通りに完了させることが可能です。 さらに、本来であればDNS情報の設定者(ゾーン情報の設定者)は、いつまでに世界中のキャッシュが更新されるかを知ることができる環境にあり、それ以降も更新がされていなければ「何かがおかしい」とわかるはずです。 DNSにおける設定内容(DNSのリソースレコード)には、その情報をキャッシュとして保持し続けても良い期間であるTTL(Time To Live)という要素がありますが、TTLはDNS情報設定者が自分で設定
UT-VPN Web サイト - 筑波大学 VPN オープンソースプロジェクト
UT-VPN は SoftEther VPN プロジェクトにしました NEW! 2013 年 7 月 25 日、「SoftEther VPN プロジェクト 日本語版」が以下の Web サイトで公開されました。 http://ja.softether.org/ また、同日 SoftEther VPN 1.0 (フリーウェア) 日本語版が上記 Web サイトで公開されました。これにより、「UT-VPN プロジェクト」は「SoftEther VPN プロジェクト」に移行しました。 今後は UT-VPN のバージョンアップの予定はありません。UT-VPN に加えて L2TP/IPsec や OpenVPN などのプロトコルに対応した最新の SoftEther VPN 1.0 をご利用ください。SoftEther VPN 1.0 は 2013 年中頃にオープンソース化する予定です。今後の開発は So
はやいTCPサーバの書き方 - nyaxtのPC作業ログ
cagra高速化にあたってのノウハウを一部公開してみます。また明日校正/更新します。つっこみ待ちです。 select(2)の代わりにepoll_wait(2), kqueue, /dev/epoll等を使う 他に山ほど解説ページがあるので略 大量のディスクリプタを処理するようなサーバの場合、多少効果があるかもしれません。しかし、クライアント数が少ない場合、劇的な性能の向上は見込めないとおもいます。クライアント数が多い場合は、１セッション１スレッドなモデルではOS側のタスクスイッチングのオーバーヘッドが効いてくることも多いです。クライアント数を増やすには複数のセッションを１スレッドで処理できるようにすると良いです。実装にあたっては、non-blocking ioを活用すると効果的です。 TCP_NODELAYを設定する Nagleアルゴリズムをオフにします。多少応答性が良くなります。 これっ
TheC10kProblem - 「C10K問題」（クライアント1万台問題）とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと
TheC10kProblem - 「C10K問題」（クライアント1万台問題）とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと 目次 この文書について C10K 問題 関連サイト まず読むべき本 I/O フレームワーク I/O 戦略 1. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と レベル・トリガ型の完了通知を利用する. 伝統的な select() 伝統的な poll() /dev/poll kqueue() 2. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と 変更型の完了通知(readiness change notification)を利用する. kqueue() epoll リアルタイム・シグナル fd 単位のシグナル (Signal-per-fd)
ミニマルなHTTPサーバ - かそくそうち
http://0xcc.net/blog/archives/000178.html このコードには長時間動作させる上で明らかにマズい点が二つあります。 (22:58追記: 問題のコードは既に修正されています。高林さん、すばやい対応ありがとうございます。) 「UNIXネットワークプログラミング」の別の節に解説はありますが、コードだけコピペした人が困らないよう指摘しておきます。 一つ目はSIGPIPEシグナルの発生に備えていない点です。 サーバーがレスポンスを返す前にクライアントがソケットを閉じてしまうと、write()がSIGPIPEシグナルを生成することがあります。 SIGPIPEの既定の動作はプロセスの終了なので、この状況が発生しただけでサーバーは勝手に(coreを残さず)終了してしまいます。 通常は次のような関数でSIGPIPEを無視します。 #include <cstring> #i
404 Blog Not Found:IPアドレスはいつ枯渇してもおかしくない
2007年06月10日04:30 カテゴリiTech IPアドレスはいつ枯渇してもおかしくない かつてクラスC(/24)を一人で持っていたオレがきましたよ。その頃は128kbpsの接続に月30万はらってたけど(爆)。 池田信夫 blog IPアドレスは枯渇していない コメントで教えてもらったが、総務省はIPアドレスの「枯渇対策会議」を今月中に立ち上げるそうだ。アドレスの配分を検討するのはいいが、それが枯渇するという事実認識は間違いである。IPv4のアドレスは約43億個、全世界のユーザー（約11億人）ひとり当たり4個もある。これに対して、現在のホスト数は約4億3000万なので、アドレスはまだ1割しか使われていないのだ。 池田先生、ちょっとこれはひどすぎ。 ホスト数 < 必要なIPアドレス数 まず、なぜ「たった一割」しかIPアドレスが使われていないのに、ネットワーク屋さんたちがそわそわしている
Openmya Hiki - ネットワークアドレスとサブネットマスク
「192.168.168.123/19」のネットワークアドレスを求める例 まず、サブネットマスク長を8で割る。 19 / 8 = 2 余り 3 この計算結果は、先頭2byteと次の上位3bit目までが ネットワークアドレスになる事を意味する。 bitで表現すると直感的で分かりやすいかな。 11111111 11111111 11100000 00000000 ここからは、ネットワークアドレスの境界がある3byte目だけに 注目して計算していく。 なぜなら、1byte目と2byte目はネットワークアドレス、4byte目は ホストアドレスとして確定しているのでもう計算する必要は無いため。 次にサブネットワークの大きさ、つまり各サブネットワークが どの単位で切り分けられるのかを求める。 上位3bitまでがネットワークアドレスなので、ホストアドレスには 残りの5bitが使用される。5bitで表せる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ARPスプーフィングで通信傍受！ | The Weekly Herald