タグ

2014年7月24日のブックマーク (7件)

  • ソケット通信メモ(Hishidama's TCP/UDP Socket Memo)

    TCPソケット サーバータイプとクライアントタイプの両方のアプリケーションを作らないといけないなら、サーバータイプから作るべきだろう。 (クライアントタイプだけ先に作っても動かせないから。まぁサーバータイプだけ動かしても、待ってるだけであまり意味無いけど(苦笑)) でも仕組みはクライアントタイプの方が簡単。 TCPを使う場合は、通信の最初にコネクションの確立を行う必要がある。 サーバーでlisten・accept、クライアントでconnectが成功すればコネクションが確立したことになる。 どのポート番号を使うかについては、サーバー側はアプリケーションの作成者が決める必要がある。[/2007-06-16] クライアント側のポート番号は、ソケットライブラリがそのマシンで使っていない番号を自動的に割り振ってくれるので、気にしなくてよい。 IANAの基準では、1~1023は「よく知られたポート(w

  • Progress作業メモ - nekomoaruku's diary

    TODO wsチャットサーバ、ws 認証token発行API、hapi token認証をチャットサーバーに追加、ws wsチャットサーバ webにあるサンプルみたいなのはできた。 wsの認証&idとconnectionのhashをどこで作るか考えた。 パフォーマンス的には、handleUpgrade()をoverrideするのが良いと思った。ただ大変そうなので、カスタム認証用に用意されているverifyClient()に書けばいい。と思ったら、verifyClient()が呼ばれる段階では、connection(コード上はclient)が作られてない。なので結局、'connection'eventで拾う。まとめ。認証はverifyClient()に書く。idとconnectionとのhashは、'connection'イベント処理に書く。 Handshakeリクエスト時にブラウザ上のjsが

    Progress作業メモ - nekomoaruku's diary
  • node.jsのいろいろなモジュール23 – wsでWebSocket接続 | DevelopersIO

    wsモジュール wsモジュールは、WebSocketプロトコル(RFC-6455に準拠する)の実装ライブラリです。 socket.ioのように多機能ではありませんが、シンプルな作りで非常に高速に動作するのが特徴です。 ※socket.ioも内部でwsを使用しています 環境構築方法 今回使用した動作環境は以下のとおりです。 OS : MacOS X 10.7.4 Node.js : v0.8.15 npm : 1.1.66 適当なディレクトリを作成し、そこでnpmを使用して必要モジュールをインストールします。 今回はexpressも使用するので、いっしょにインストールしましょう。 % mkdir ws % cd ws % npm install ws express wsモジュールを使ったチャット ありふれた例ですが、wsモジュールとexpressモジュールを使用してシンプルなチャットをつく

    node.jsのいろいろなモジュール23 – wsでWebSocket接続 | DevelopersIO
  • 今更だけどSocket.ioについてまとめてみる - blog::wnotes.net

    ちょっとSocket.ioを導入する機会があったので、色々調査したのをメモしておきます。 Socket.ioとは node.jsのnpmとして提供されている、WebSocketを手軽に扱えるモジュールです。 多分すごい有名なので、だいたいみなさん知ってると思います。 他にはwebsocket-serverとかもあるんですが、こっちの方が有名ですかね。 特徴として、クライアントサイドのトランスポートがクロスブラウザなところでしょうかね。とても助かります。 詳しいところは公式サイトを見るといいと思います。 Socket.IO: the cross-browser WebSocket for realtime apps. すんごい出たばっかりの頃にも触ったことがあったんですが、今使ってみると機能がすごい増えててびっくり。 機能の紹介とかは他のサイトを見てもらうとして、備忘録的に自分がやった所なん

  • ErlangのCowboyを試す - pocketberserkerの爆走

    cowboyを触ってみたのでメモ代わりに。 cowboyを触ろうと思った理由はmspgack-rpc-erlangの内部にcowboyが使われているからという理由です。特に理由になってない。 参考にした記事とか 家リポジトリのREADMEとexampleを参考にしました。 extend/cowboy · GitHub 環境 私はErlang R15B02で試しました。 cowboyのインストール rebarを使うので、rebar.configを以下のように記述しました。 {deps, [ {cowboy, ".*", {git, "git://github.com/extend/cowboy.git", "master"}} ]}. rebarのテンプレート機能を使う rebarのテンプレート機能を使って必要そうなファイルを生成してもらいましょう。 $ ./rebar create-ap

    ErlangのCowboyを試す - pocketberserkerの爆走
  • rebar、それはErlangのビルドツール

    Erlangのコンパイラと言えばerlcですが、Erlang専用のビルドツールが存在します。それがrebarです。 まず、入手から。githubから落としてきます。 git clone git://github.com/basho/rebar.git そして、rebarをビルドします。もちろんErlang OTPはインストール済みな状態からやりましょう。 cd rebar ./bootstrap これでrebarコマンドができあがります。さっそく実行してみましょう。rebarがサポートするコマンド一覧を出力してみます。 ./rebar -c いろいろ出てくれば成功です。 新規にプロジェクトを始めるときには、以下のようにして自動生成させます。 mkdir myproject cd myproject cp ../rebar/rebar . ./rebar create-app appid=m

  • WebSocket通信のメリットを考える

    何故だか昨日のエントリが意外なほど読まれている。(^^;;; Twitterでの言及も過去最大級かも。特に、 サーバーとの通信はAjax併用でも良いんですが、多分全部WebSocketでやる方がシンプルだし速度面やセキュリティ面でも優位があります。 この文章に引っ掛かった人が多いようで、これについてもうちょっと掘り下げてみます。 ★ Ajaxの代替としてのWebSocket そもそもの話として、素のWebSocketではリクエスト(この場合クライアント→サーバのメッセージの意)とレスポンス(サーバ→クライアント)を対応付けることができません。これを実現するためには自力でサーバ/クライアントの双方にメッセージをハンドリングするための仕組みを実装しならず、それは結構めんどうな作業です。 今回、その部分をフレームワーク化しようとしているので、それが実現できた場合のメリットを考えてみます。 ざっと

    WebSocket通信のメリットを考える