タグ

networkに関するtaroleoのブックマーク (12)

  • Netty: Home

    Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Netty is an NIO client server framework which enables quick and easy development of network applications such as protocol servers and clients. It greatly simplifies and streamlines network programming such as TCP and UDP socket server. 'Quick and ea

  • Aspera | IBM

    taroleo
    taroleo 2009/05/25
    激速らしい
  • Node crashing handling and VM statistics | ioremap.net | Page 3

    In a meantime elliptics network got a little bit harden node crash management – all transactions which were not sent prior node crash will be resent to another nodes according to the changed routing table. This was only slightly tested though, since real-life examples are a bit hard to catch. I will write a test script, which will write to the node which will forward all requests to another one, a

  • OpenJDK: NIO

    More New I/O APIs for the Java Platform This Project's mission is to produce the implementation of the (New) New I/O APIs being defined by JSR 203 as well as related work in the JDK. The main "umbrella" RFEs for this work are: 4313887 New I/O: Improved filesystem interface 4640544 New I/O: Complete socket-channel functionality 4607272 New I/O: Support asynchronous I/O This Project is sponsored by

  • gist:54029

  • クローリングしてる暇があるなら…論文かいたら? | EDGE Datasets(研究用データセット)

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    クローリングしてる暇があるなら…論文かいたら? | EDGE Datasets(研究用データセット)
  • Blog by Sadayuki Furuhashi

    MessagePackフォーマット仕様のPull Request #209をマージし、MessagePackにTimestamp型を追加しました。 ※この記事の英語版は XXX にあります(翻訳中) Extension型の型コード -1 として定義されているため、後方互換性が維持されています。つまり、既にExtension型に対応しているデシリアライザであれば、Timestamp型を使用して作成されたデータを、Timestamp型に対応していない古いデシリアライズで読み出すことができます。 新しいTimestamp型には timestamp 32、timestamp 64、timestamp 96 の3つのフォーマットがあり、よく使う値をより少ないバイト数で保存できるようになっています。例えば、1970年〜2106年までの時刻で、秒までの精度しか持たない時刻であれば、合計6バイトで保存でき

    Blog by Sadayuki Furuhashi
  • 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

    Re はやいTCPサーバの書き方 - kazuhoのメモ置き場
  • はやいTCPサーバの書き方 - nyaxtのPC作業ログ

    cagra高速化にあたってのノウハウを一部公開してみます。また明日校正/更新します。つっこみ待ちです。 select(2)の代わりにepoll_wait(2), kqueue, /dev/epoll等を使う 他に山ほど解説ページがあるので略 大量のディスクリプタを処理するようなサーバの場合、多少効果があるかもしれません。しかし、クライアント数が少ない場合、劇的な性能の向上は見込めないとおもいます。クライアント数が多い場合は、1セッション1スレッドなモデルではOS側のタスクスイッチングのオーバーヘッドが効いてくることも多いです。クライアント数を増やすには複数のセッションを1スレッドで処理できるようにすると良いです。実装にあたっては、non-blocking ioを活用すると効果的です。 TCP_NODELAYを設定する Nagleアルゴリズムをオフにします。多少応答性が良くなります。 これっ

    はやいTCPサーバの書き方 - nyaxtのPC作業ログ
  • 高木浩光@自宅の日記 - 日本のインターネットが終了する日

    ■ 日のインターネットが終了する日 (注記:この日記は、6月8日に書き始めたのをようやく書き上げたものである。そのため、考察は基的に6月8日の時点でのものであり、その後明らかになったことについては脚注でいくつか補足した。) 終わりの始まり 今年3月31日、NTTドコモのiモードが、契約者固有ID(個体識別番号)を全てのWebサーバに確認なしに自動通知するようになった*1。このことは施行1か月前にNTTドコモから予告されていた。 重要なお知らせ:『iモードID』の提供開始について, NTTドコモ, 2008年2月28日 ドコモは、お客様の利便性・満足の向上と、「iモード(R)」対応サイトの機能拡充を図るため、iモード上で閲覧可能な全てのサイトへの提供を可能としたユーザID『iモードID』(以下、iモードID)機能を提供いたします。 (略) ■お客様ご利用上の注意 ・iモードID通知設定は

  • メルマ!

    メルマ!サービス終了のお知らせ いつもメルマ!をご利用いただき誠にありがとうございます。 サービス開始以来、たくさんの皆様にご利用いただきましたメルマ!ですが、 誠に勝手ながら、2020年3月13日を持ってサービスを終了させていただく事となりました。 今までのご愛顧、誠にありがとうございました。 件に関するお問い合わせ info@melma.com

  • IPv6の最高転送速度記録更新 | スラド

    なぜこうゆう研究が必要なのかというと、インターネット通信で用いられて いる TCP/IPは、遠距離との大容量通信に向いていないと言われているからだ。 なぜなら、簡単に言うとTCP/IPでは受信側からの受信確認(アクノレッジ) を待ってから次のデータを送信する仕組みなので、地球の裏側のように 100ms以上の遅延があると単一のTCP/IP通信では 10Gbpsでの通信は不可能とされてきた。(1Gも多分無理なのでは?) そこで、複数のTCP/IPセッションに分割して送ったり、 TCP/IP以外の代替プロトコルが提案されてきたわけだが、 現在あるTCP/IPに改良を加えるだけで、遠距離大容量通信を 1つのTCPセッションで達成できた点に、これら一連の研究の意義があるというわ けです。 OS側のTCP/IPプロトコルスタックが対応すれば、アプリケーション側の 変更は不要だからね。 この点は、Tb-

  • 1