タグ

2015年7月13日のブックマーク (6件)

  • TCPメモ(Hishidama's TCP Memo)

    片方が他方に対して何らかの電文を送ると、相手は受け取ったという印にACKを返す。 ACKが来なければ相手が受け取っていないということなので、その場合はある程度待ってから再送する。 ACKは他の電文と一緒に送ってもよい。 コネクションは、【相手先IPアドレス・相手先ポート・自分のポート】の組で一意に表される。 コネクションは現在どういう状態にあるかを示すステータスを持っており、イベントに応じて遷移していく。netstatコマンドで表示されるのは、これ。 TCP/IPとソケットの関係 ソケット関数を呼び出すと、ソケットライブラリ(プロトコルスタック?OS?)がTCP/IPの規約に従って通信を行う。 listen(受付開始) サーバー側で接続の受付待ちを開始する。 コネクション(通信相手はいないので、相手先IPアドレス・ポートは無し、自分のポート番号だけ有り)はLISTEN状態になる。 conn

  • Linux システムコールのブロック・ノンブロックまとめ

    はじめに Linux にはブロックするシステムコールとノンブロックなシステムコールがあります。さて、システムコールが「ブロックする」とはどういうことでしょうか。よく、ブロックするシステムコールとは「処理が完了するまでプロセスの動作が中断され待たされること」という説明を見ますが、より詳細に、どういう処理の場合に待たされるのか、整理してみましょう。 「ブロックする」とは Linux において、システムコールがブロックするとは、「プロセスが、システムコール呼び出しの延長で待状態(TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE) に遷移し、CPU時間を消費せずにあるイベントが完了するのを待つようになる」、ことを指します。ブロックするシステムコールのうち代表的なものと、完了待ち対象イベントをまとめると、以下のようになります。 システムコール待ち対象イベント re

  • Charming Python: Functional programming in Python, Part 3

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    Charming Python: Functional programming in Python, Part 3
  • ウェブカツ運営者が語る!WEBサービスで起業したい人に読んで欲しい20のコト - Qiita

    プログラミング学習サービスやら、ペットサロン予約サービス、風俗予約サービスなど色々とやっている「かずきち」です。 ◾️その他Qiita記事 エンジニアで稼ぐために大切な20のコト ウェブカツ生を雇わない?転職できない?著作権無断使用の炎上から1年を経て思うところをぶっちゃける。 テックキャンプをウェブカツ!! 顧問が徹底レビューしてぶった切ってみた ■運営サービス一部 http://crazy-wp.com/ フリーランスエンジニアを育成するオンライン最大級のプログラミングスクール「ウェブカツ」 http://webukatu.com/ ■プログラミングスクール「ウェブカツ」の出版 「小学生からでもプログラミングを楽しく学べる漫画作りたいなー」と思い立ち、外注してウェブカツで漫画を作りました。KADOKAWAさんより出版しています。 はたらくプログラミング 完全版 (コミックエッセイ)

    ウェブカツ運営者が語る!WEBサービスで起業したい人に読んで欲しい20のコト - Qiita
  • OpenSSLの脆弱性(CVE-2015-1793)によるAltチェーン証明書偽造の仕組み - ぼちぼち日記

    TL;DR やっぱり書いていたら長文になってしまいました。あまりちゃんと推敲する気力がないので、変な文章になっているかもしれません。ご了承いただける方のみお読みください。 1. はじめに 昨晩未明にOpenSSL-1.0.2d, 1.0.1pがリリースされました。事前に予告されていた通り深刻度高の脆弱性CVE-2015-1793が修正されています。Advisoryを見ると、この脆弱性がiojs/Nodeに影響があるということが判明したので直ちにiojs/Nodeのアップデートを行い、今朝未明に無事脆弱性対応版をリリースしました。 今回が初めてではありませんが、深夜に日欧米のエンジニアgithub上で互いに連携しながら速やかにセキュリティ対策のリリース作業を行うことは何回やってもなかなかしびれる経験です。時差もありなかなか体力的には辛いものがありますが、世界の超一流のエンジニアと共同でリア

    OpenSSLの脆弱性(CVE-2015-1793)によるAltチェーン証明書偽造の仕組み - ぼちぼち日記
  • RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita

    "Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に

    RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita