タグ

ProgrammingとNetworkに関するagwのブックマーク (38)

  • オンラインゲーム 10年の進化と同期方式の選び方 - きゅぶろぐ

    オンラインゲームを作ろう!と思ったことがある方は、 こちらの講演記事を1度は見たことがあるのではないでしょうか。 www.4gamer.net こちらの講演は、具体例を交えながら非常に分かりやすくオンラインゲームの主な同期方式が説明してあり、 2024年現在でもオンラインゲームの基礎を学ぶ資料として真っ先に名前を上げる最高の資料です。 しかしながら講演は2010年のものであり、オンラインゲームはこの10年余りで進化しています。 この辺りの進化の話を簡単にまとめつつ、オンラインゲームの同期方式の選び方を紹介します。 (上記講演記事の知識/用語を前提としているため、先に上記記事をお読みください。) オンラインゲームの民主化について 技術の話をする前に。 近年、「マルチプレイヤーゲーム」と聞いてオフラインの画面分割ゲームを想像する人はいないと言って良いほど オンラインゲームは民主化されてきました

    オンラインゲーム 10年の進化と同期方式の選び方 - きゅぶろぐ
  • 新人プログラマに知ってもらいたいRabbitMQ初心者の入門の入門 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 題名はここオマージュです。 背景と目的 勤めている会社では、メッセージングのミドルウェアとしてAMQPというプロトコルを利用しているRabbitMQを使用しています。 RabbitMQについては、公式サイトの説明が充実しているので、業務で使用を考えている方は 基的にこちらを読むことをお勧めいたします。 ただ、自分で調べていて 公式サイトの内容は英語語のサイトを調べようとしても情報が少なかったり散らばっている そもそもメッセージングのミドルウェアがどういったもので、どういう際に必要になるかの説明が少ない ことで結構段取り時間がかか

    新人プログラマに知ってもらいたいRabbitMQ初心者の入門の入門 - Qiita
  • プログラマが知っておくべき、メモリ/ディスク/ネットワークの速度まとめ - Qiita

    注: 無線ネットワークは干渉などによりこの数値より遅くなる状況も十分ありえます。 ポイント メモリからの読み込みとディスクからの読み込みはランダムアクセスで1000倍程度違う とは言え、最近はディスクも結構速い きちんと繋がれた有線ネットワークからの読み込みは、ディスクより速い つまり、ディスクから読むより、同じデータセンターのマシンのメモリから読んだほうが速い モバイルネットワークだと100キロバイトのデータでも1秒以上かかることがある メモリからの読込速度の遅さは、CPUのクロック数も10G/s程度なのと、来はL1/L2キャッシュなどがあることを考えると通常意識しなくて良い 何故この参考値をまとめたか プログラミングをする際、どのくらいの時間でどのくらいのサイズ感の処理が出来るのかを考えられることが、ある一定規模以上のサービスを開発するときは必須条件になってくると思います。 なにより

    プログラマが知っておくべき、メモリ/ディスク/ネットワークの速度まとめ - Qiita
  • 分散プログラミングモデルおよびデザインパターン - kuenishi's blog

    同名の某記事について。僕がタイトルから想像する期待を、なんだか意外な方向に裏切ってくれた記事であった。批判するだけではよくないので、同じタイトルで僕ならどういう話になるか…という話をしよう。絵のない長文だ覚悟して読め(ΦωΦ)フフフ…。 分散プログラミングモデル プログラミングモデルとはなんであろうか。 …CもJavaもMPIも登場していない1972年の論文を持ってこられてそれがオリジナルだみたいなこと言われてもえー…って感じで、Flynnの1972年の論文は並列計算やHPCの方面へ非常に大きな影響を与えていると思う。ただしそれはCPU内の話であって、時代が進むと共にたとえば牧野先生の日記「並列計算機のプログラミングモデル」で書かれているような議論につながるといえば繋がるには繋がるが、このレベルで計算を並列化する議論にしか応用できない。せいぜい、プログラミングモデルとひとくちにいっても様々

  • サービス終了のお知らせ

    サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。

  • tarとncを使って簡単にディレクトリごと他のサーバに転送 - うまいぼうぶろぐ

    http://d.hatena.ne.jp/hogem/20101115/1289827270 続き tarと組み合わせればファイルだけじゃなくてディレクトリごといけますね。ncの入出力にtar の"-" で標準入出力を使えば良い。 portは適当(ここでは10000) 送信サーバ tar zcvf - ./directory | nc -l 10000 受信サーバ nc 送信サーバ 10000 | tar zxvf - 補足 もちろんcronなどで動かすようにまともなことするならpassphraseなしのssh+rsyncなどをすればいいのですが、一時的にサーバ間でデータを受け渡したいだけっていう場合は鍵の設定するのめんどうですからね。なんというかここではncをtftpみたいな感じで使っています。

    tarとncを使って簡単にディレクトリごと他のサーバに転送 - うまいぼうぶろぐ
  • 「SoftEtherを危険視するのはおかしいです」――19歳の開発者に聞く

    小学2年生の頃から、NECの「PC-8001」でプログラミングを始める。私立高槻高校1年のとき、「月刊I/O」に投稿していたのが縁で、DirectX8.0の書籍を執筆。「当時は英語版の資料しかなかったので、日語の書籍を出せば売れる、と言われて書きました」(同氏)。ちなみに、2万部ほど売れたという。 その後、高校卒業までにさらに2冊のを執筆。また、高校3年の時に“FOMA向け”のメモリ編集ソフトを開発する。「現在、ソースネクストの『携快電話』の8と9に、僕の開発した通信モジュールが入っています」。 2003年、筑波大学第三学群、情報学類に入学した。 レイヤ2で2点間を接続するVPNプロトコル ITmedia まずは、開発者人から簡単にSoftEtherを説明してください。どのようなメリットがあるソフトですか。 登 従来、VPNプロトコルとしては、PPTP(Point-to-Point

    「SoftEtherを危険視するのはおかしいです」――19歳の開発者に聞く
  • TCPを使う(サーバ、SO_REUSEADDR):Geekなぺーじ

    前述したTCPサーバ例では、サーバを終了した直後にもう一度サーバを起動しようとすると、bindがエラーで終了することがあります。 ここでは、その問題を回避するためにSO_REUSEADDRを有効にする方法を説明したいと思います。 TIME_WAIT TCPサーバのプログラムを書いていて、TCPサーバを終了して直後にもう一度起動したときに、 bindが「Address already in use」というようなエラーで失敗してしまったとこは無いでしょうか? 「あれ?もうTCPのサーバプロセスは終了しているのに。何故、bind出来ないのだろう?」と思いつつ、 しばらく時間がたってからもう一度実行すると問題なくbindが成功したりします。 この問題はTCP自体の仕組み(仕様)によって引き起こされています。(winsockの問題ではなく、TCPの仕様です)。 具体的にはTIME_WAIT状態という

  • ネットワークプログラムのI/O戦略 - sdyuki-devel

    図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド・イベント駆動 コネクションN:スレッド1。epoll/kqueue/select を1つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える: サーバーにメッセージを送信 イベントハンドラを登録;このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す 1コネクション1スレッ

    ネットワークプログラムのI/O戦略 - sdyuki-devel
  • 京都観光を終えて - mala

    Shibuya.pm Technical Talk #10 (2008-11-27) mala 最初: sm5377260 (lestrrat) マイリスト: mylist/9691133http://shibuya.pm.org/blosxom/techtalks/2008011.html

    京都観光を終えて - mala
  • UNIX Socket FAQ

    About this FAQ Size: 2 KB, Last Update:5 Nov 2001 About this FAQ This FAQ is maintained by Vic Metcalfe ( vic@acm.org ), with lots o Who is this FAQ for? Size: 1 KB, Last Update:5 Nov 2001 Who is this FAQ for? This FAQ is for C programmers in the Unix environment. It is What are Sockets? Size: 1 KB, Last Update:5 Nov 2001 What are Sockets? Sockets are just like "worm holes" in science fiction. Whe

  • ネットワークプログラミングの基礎知識

    ネットワークプログラミングの基礎知識 ここでは IP アドレスやポート番号、クライアントとサーバの役割などを説明し、 perl・C言語・Java などでソケット (Socket) を使った HTTP クライアントや POP3 クライアント、簡単なサーバを作成してみます。 要はネットワークプログラミングをやってみよう、ということです。 このページのサンプルプログラムは、RFC などの規格に準拠した「正しい」プログラムではありません。 また、全体的にエラー処理が不十分です (今後改善する予定です)。 あくまでも概要を理解するためのサンプルととらえてください。 もし気でしっかりとしたクライアントやサーバを書きたいなら、このページを読んだ上で、 さらに RFC を熟読し、そして wget・Apache・ftp コマンドなどのソースを参考にしてください。 このページに間違いを見付けたら、掲示板

  • FTP(File Transfer Protocol)~前編

    FTP〜原点はRFCを参照したいというニーズから FTPは、今日インターネット上で最もよく利用されるファイル転送用プロトコルとして知られる。ファイル転送用プロトコルとしては、Windowsネットワークなどで利用されるNetBIOSやUNIXでは一般的なNFS(Network File System)などもあるが、これらはいわゆる「ファイルマウント型」(OSのファイルシステムに対して外部ファイルシステムを仮想的にマウントする)であるのに対し、FTPは純粋なクライアント/サーバ型である。操作上は前者が便利なのにも関わらず、FTPがいまだにインターネットで標準プロトコルとされているは、ある種のOSに依存しない「マルチプラットフォーム」での動作を当初から考慮していたからだ。 このころまでには、すでに異なるホスト間でファイルを転送するという最もシンプルなFTPの前身ともいうべき機能が、UCLAなどを

    FTP(File Transfer Protocol)~前編
  • 「感情の共有」,「負荷との戦い」---ニコニコ動画の技術:ITpro

    インターネット・サービスの激戦区である動画配信で後発ながらYouTubeを上回る成長速度,YouTubeの3倍以上となる1日ひとり3時間以上という平均視聴時間を実現したニコニコ動画。開設後1年足らずで400万人の会員を獲得,日全体のトラフィックの約10分の1を占める。その成長速度はmixiも上回り,日史上最速と見られる。 ニコニコ動画は多くのメディアで語られ,2007年10月にはグッドデザイン賞も獲得したが,これまでは社会現象やマーケティングの観点から語られることが多かった。しかしニコニコ動画を作り上げ,その急拡大を支えたのはまぎれもなくエンジニア技術だ。多くのクリエイタやユーザーを魅了し,巨大なアクセスをさばく技術はどのようなものなのか。ドワンゴのエンジニアに聞いた。 「感情」を共有するアルゴリズム 動画の上に文字をかぶせるサービスはニコニコ動画以前にも存在した。また,動画のタイミ

    「感情の共有」,「負荷との戦い」---ニコニコ動画の技術:ITpro
  • inetd の仕組みを見てみる - naoyaのはてなダイアリー

    inetd や xinetd (以下 inetd) はインターネットサービスをデーモン化するのに共通している処理を担い、ほとんどの時間をアイドル状態で過ごすその手のサービスに必要なリソースを節約する役割を果たします。 inetd のひとつ面白いところは、inetd でサービス化したいプログラムの標準入力/標準出力がクライアントソケットの入出力に接続されるところです。例えば daytime 相当のサービスを自分で作ろうと思った場合 #!/usr/local/bin/perl # daytime.pl use strict; use warnings; use DateTime; use IO::Handle; STDOUT->autoflush(1); STDOUT->printf( "%s\n", DateTime->now(time_zone => 'Asia/Tokyo') ); と標

    inetd の仕組みを見てみる - naoyaのはてなダイアリー
  • IPA ISEC セキュア・プログラミング講座:Webアプリケーション編 第1章 総論:より良いWebアプリケーション設計のヒント

    ここで述べるのは、脆弱性が生まれにくいWebアプリケーションを構築するために設計段階、あるいはそれ以前の段階で考慮しておくとよい事項の例である。 (1) 開発環境の選択 1) プログラマが脆弱性をつくり易い環境を避ける 今日のWEBアプリケーション開発環境は、プログラミング言語の処理系に加えて、開発フレームワークやコンテンツ管理システム(CMS)、さらに外部のテンプレート言語までを加えた総合的な環境となってきている。 短時日で素早くサイトを立ち上げることを目的として、「軽量言語」と呼ばれる各種スクリプト言語が標準で備えているWEBアプリケーションを手軽に開発するための機能やライブラリをそのまま利用することは悪くない。しかし、その手軽さ故に、セキュリティの観点からは多くの脆弱性を生んできた経緯がある。 例えば、下記の事例が挙げられる。 PHPの4.1以前のバージョンの環境は、「registe

  • Site Cooler NZ | Points to Note When Shopping for a Washing Machine

    Points to Note When Shopping for a Washing Machine There are different washing machines brands in New Zealand. When shopping, therefore, you need to ensure that first, you get a quality machine; a machine that will last through many years without breaking down. You check product warranties and reviews when shopping to ensure a machine is a good quality. The material of the drum can be enamel, plas

  • 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)

  • squid2.6のCOSSの話(その2) - 最速配信研究会(@yamaz)

    squid2.6のCOSSの話の続き COSSのパフォーマンスのよさに関して「俺だまされてない?」というモヤモヤ感が高かったんだけど,あちこちの方々と議論した結果これが正解だろうという結論に行き着いた. ありがとう!>あちこちの方 友人との会話. yamaz: おっすおっす。いる? xxxxx: お久しぶりです! yamaz: squid2.6のCOSSって知ってる? xxxxx: 初耳です。<COSS yamaz: http://blog.nomadscafe.jp/archives/000705.html yamaz: http://wiki.squid-cache.org/SquidFaq/CyclicObjectStorageSystem yamaz: このあたりの話なんだけど、 yamaz: なぜコレが速いかっていう見解って持ってる? xxxxx : 3年ぐらい前、apacheを

    squid2.6のCOSSの話(その2) - 最速配信研究会(@yamaz)
  • 「コネクションプーリング都市伝説」はほんとに都市伝説?(その3) - 最速配信研究会(@yamaz)

    前回のシリアル/パラレル処理の視点に立ってコネクションプールについて考えてみたい. コネクションプールが遅いとは はてなおやさんが考察しているように 普通にmod_perl でコネクションプールを素直に張るとコネクション数が爆発する. 図にすると図1のような感じで個々のapacheがコネクションを複数持つので,サーバ台数が増えるとコネクション数が飛躍的に増えることがわかると思う. 図1 コネクションが爆発してる様子(正直書くのも大変) コネクション数が増えると単純にコネクションを維持するコストも増えていくので, このあたりが「コネクションプーリング都市伝説」の根拠になっていると思われる. これはこれで全くその通りで間違いない. さて,ここでもうちょっと大きな視点に立って,クライアント<->サーバ間の通信路が 1個の伝送路をパケットによって多重化しているととらえてみたい.そうするとここで シ

    「コネクションプーリング都市伝説」はほんとに都市伝説?(その3) - 最速配信研究会(@yamaz)