TCPを（少しは）理解しておくべきその理由 | POSTD
この記事はTCPの 全て を理解する、あるいは 『TCP/IP Illustrated』 （訳注：日本語版: 『詳解TCP/IP〈Vol.1〉プロトコル』 ）を読破しようとか、そういうことではありません。ほんの少しのTCPの知識がどれほど欠かせないものなのかについてお話します。まずはその理由をお話しましょう。 私が Recurse Center で働いているとき、PythonでTCPスタックを書きました（ またPythonでTCPスタックを書いたらどうなるかについても書きました ）。それはとても楽しく、ためになる経験でした。またそれでいいと思っていたんです。 そこから1年ぐらい経って、仕事で、誰かが「NSQへメッセージを送ったんだが、毎回40ミリ秒かかる」とSlackに投稿しているのを見つけました。私はこの問題についてすでに1週間ほど考え込んでいましたが、さっぱり答えがでませんでした。 こ
Why you should understand (a little) about TCP
This isn’t about understanding everything about TCP or reading through TCP/IP Illustrated. It’s about how a little bit of TCP knowledge is essential. Here’s why. When I was at the Recurse Center, I wrote a TCP stack in Python (and wrote about what happens if you write a TCP stack in Python). This was a fun learning experience, and I thought that was all. A year later, at work, someone mentioned on
TCP Retransmit・DupACK・Fast Retransmit ～トラブルシューティング時のキーワード～ - troushoo
今回は、TCP Retransmit と DupACK と Fast Retransmit の紹介を行います。 いずれも、パケットロスといったネットワークの性能が出ない時に出現するキーワードです。 【TCP Retransmit】 Retransmit とは”再送”を意味する英単語です。 TCPでは、TCPデータの送信者が、受信者からACKを受け取れなかった場合、TCPデータの再送(=Retransmit)を行います。 これがTCP Retransmitです。 TCP Retrasmitの発生は、送信者と受信者の間でのパケットロスの可能性を示唆しています。 以下の例は、Retransmitが起こっているときのパケットキャプチャです。 ①で、192.168.122.129へ ”HTTP/1.1 200 OK” というデータを送っています。 ②の間、192.168.122.129へACKが受信
Kohei Ozaki, 小嵜耕平 | ho.lc
Kohei Ozaki (a.k.a. @smly) is a Software Engineer at Ubie. My specialties are around data and machine learning. I love to discover knowledge and hidden values in data.保険/金融/広告ほか様々な事業でデータ分析や研究開発などの業務を 10 年以上経験してきました。 現在はUbie株式会社でソフトウェアエンジニアをしています。またTURING株式会社でフェローをしています。 I am a Grandmaster of Kaggle competitions (an honor for top competitors with outstanding data science skills) with 19 gold medals
Kestrel:Reliable Read
メッセージングシステムで、dequeue 後に正しく処理できずに異常終了したらどうなるのか? Twitter などで利用されている Kestrel には reliable read という仕組みがあり、一度 dequeue したアイテムの処理中にエラーが発生しても、キューの先頭に enqueue できる。 この動作を実際に確認してみた。 Reliable Read Command Memcached プロトコルで reliable read をするには、キューからアイテムを取得する際に / に続けて以下のオプションを指定する。 /open : 一時的に dequeue /close : dequeue を確定 /abort : dequeue を取り消し、queue の先頭に enqueue Reliable Read Examples 以下の4パターンについて、キューの処理と peek
STORM
2. HADOOP VS STORM Batch processing Real-time processing Jobs runs to completion Topologies run forever JobTracker is SPOF* No single point of failure Stateful nodes Stateless nodes Scalable Scalable Guarantees no data loss Guarantees no data loss Open source Open source * Hadoop 0.21 added some checkpointing SPOF: Single Point Of Failure 3. COMPONENTS Nimbus daemon is comparable to Hadoop JobTrac
TwitterでつぶやいたStormの雑多な情報まとめ（その８ - 夢とガラクタの集積場
こんにちは。 #stormjp のタグでStormの雑多な情報まとめその７です。 段々、終わりが見えてきたような感はありますｗ ○81.Stormクラスタ自体のアップデートは起動しっぱなしでは無理。 安全確実を期すなら下記のフロー。 １．Topology全部落とす ２．Storm-Nimbus、UI、Supervisorを落とす ３．ZK上とローカルのファイルを全部削除 ４．Storm-Nimbus、UI、Supervisorを再起動 尚、Stormにとっては動作しながらのクラスタ自体のアップデートへ対応する優先度は低い。 ○82.storm.yamlのworker.childoptsでWorkerプロセス起動時のJVM引数を指定できるが、 その際「%ID%」と指定すればWorkerプロセスのIDに置換されて実行される。 83.LinearDRPCですとSpout/Boltの生成タイミング
リアルタイム分散処理Stormの耐障害性は？ - Tech-Sketch
リアルタイム分散処理とは 「ビッグデータ」処理のためにHadoopを用いますと、「複数のマシンに大量データ処理を分散して飛躍的に性能を向上する」ことが容易に可能となります。 ところがHadoopの弱点としまして、ビッグデータをいったん蓄積し、バッチで一括処理する形態で処理が行われますので、処理データが発生してからそれに対する処理結果が得られるまで必ずタイムラグが発生します。このため、クレジットカードの不正アクセス検知、センサーデータなどでの異常値検出のようなリアルタイムなレスポンス(低レイテンシー)が要求されるビッグデータ分野へのHadoopの適用は向いておりません。 このような随時発生する大量データ（ストリーミングデータ）を、蓄積せずにリアルタイムに処理する「リアルタイム分散処理」が求められています。 今回は、リアルタイム分散処理のソリューションとしてTwitter社より公開された
ackを捨てて、より高速なag(The Silver Searcher)に切り替えた - Glide Note
Geoff’s site: The Silver Searcher: Better than Ack ggreer/the_silver_searcher · GitHub パターン検索にはackを利用していて、通常利用時には特に不満は無かったんですが、 ファイル数が多いディレクトリだと遅かったので、もっと他の方法が無いかと調べていたら ackの3〜5倍速いというThe Silver Searcherというものが あったので導入。 The Silver Searcherの特徴 公式に書いてあるThe Silver Searcherの特徴 ackの3〜5倍高速 .gitignore、.hgignoreに記載されているものを検索対象から除外 検索対象から除外したいファイルは.agignoreに記載 agというコマンド名で、ackと比べてコマンドが短い(33%減!) なぜ高速なのかは https
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WebSocket Nagle アルゴリズム問題