タグ

ipに関するmoritataのブックマーク (14)

  • When TCP sockets refuse to die

    While working on our Spectrum server, we noticed something weird: the TCP sockets which we thought should have been closed were lingering around. We realized we don't really understand when TCP sockets are supposed to time out! In our code, we wanted to make sure we don't hold connections to dead hosts. In our early code we naively thought enabling TCP keepalives would be enough... but it isn't. I

    When TCP sockets refuse to die
  • Pythonのsocketでプロセス間通信をして価格データ等を送信する

    どうも、お久しぶりです。キリンです。 取り敢えず1ヶ月ほど、連続でブログの更新を続けてみたのですが、それ以降更新が途絶えてしまっていました。業(FXの運用)のほうが今鳴かず飛ばずなので、なんとか盛り返そうと頑張ってます。 その中で、どうしてもプロセス間通信(IPC, Inter Process Communication)をしなければならない事案に遭遇してしまったので、忘備録も兼ねてPythonでSocketを使ったプロセス間通信の方法を調べる際に学習したことと、実際に作成したプログラムをご紹介します。きちんとTCP/IPの通信について勉強したわけではないので、間違った理解、解釈があるかと思います。その際はご指導いただけると助かります。 プロセス間通信がしたい Linux上でしか動かないPythonライブラリ Linux上でしか動かないPythonのライブラリをどうしても使いたいという事

    Pythonのsocketでプロセス間通信をして価格データ等を送信する
  • 固定IP接続回線・全国対応 ipq

    公開するサーバーのポートは必要なポートを公開するように変更してください。 ■固定IP1個の場合 割り当ての固定IPアドレス:A.B.C.0 RTX1200のLAN側IPアドレス:192.168.100.1/24 公開するサーバー:192.168.100.200(A.B.C.0) TCPの20番〜587番まで 外部へはA.B.C.0でアクセスする。 --- ip route default gateway pp 1 ip lan1 address 192.168.100.1/24 *工場出荷時設定 ip lan2 nat descriptor 1 pp select 1 pp always-on on pppoe use lan2 pppoe auto disconnect off pp auth accept chap pp auth myname PPPoEアカウント PPPoEパスワー

  • 5分で絶対に分かるSIP ― @IT

    SIP(Session Initiation Protocol)という言葉を聞いて、IP電話やVoIPといったものを思い浮かべる読者も多いのではないでしょうか? 確かにSIPは「IP電話のプロトコルである」といえますが、クライアントとサーバ間の通信が中心のインターネット上で、「クライアント同士の直接通信を実現」するという大きな機能と可能性を持つ技術なのです。VoIP/IP電話といったアプリケーションを基に、このSIP技術をひもといてみましょう。 電話をネットで再現する「SIP」 SIPが主に使われているVoIPは、その名のとおり音声をIPで伝えるアプリケーションです。音声をIPで単に相手に伝えることは意外と単純で、デジタル化された音声を細切れにしてパケットとして送信するだけです。このパケット送信には、通常RTP(Real-time Transport Protocol)というシンプルなプロ

    5分で絶対に分かるSIP ― @IT
  • 俺史上最強のiptablesをさらす - Qiita

    #!/bin/bash ########################################################### # このスクリプトの特徴 # # 受信・通過については基的に破棄し、ホワイトリストで許可するものを指定する。 # 送信については基的に許可する。ただし、サーバが踏み台になり外部のサーバに迷惑をかける可能性があるので、 # 心配な場合は、送信も受信同様に基破棄・ホワイトリストで許可するように書き換えると良い。 ########################################################### ########################################################### # 用語の統一 # わかりやすさのためルールとコメントの用語を以下に統一する # ACCEPT :

    俺史上最強のiptablesをさらす - Qiita
  • ソーシャルゲームのプラットフォーム業者および下請けのソースコード流用問題 - やまもといちろうBLOG(ブログ)

    関係各所への通達をまだ全部は済ませていないけど、報道が行われる可能性が高くなったので書く。 「業界に詳しくない」とか、私のブログを全部読んでなお「何が問題なのか分からない」とか感じる方は、次の2つの記事をしっかり読んでください。 ゲームのパクリは許されるのか?――グリー&DeNAが開けた禁断の扉 http://nlab.itmedia.co.jp/nl/articles/1203/08/news056.html すべてにソーシャル要素が入る時代に突入!ゲーム産業は再編に備えよ http://trendy.nikkeibp.co.jp/article/special/20120307/1039943/?P=1&rt=nocnt まあ、和田社長が仰るように、すべてのメソッドがソーシャルゲーム的な機能を具有して統合されていく過程にあるインタラクティブメディアとしてのゲームコンテンツが、その表現技

    ソーシャルゲームのプラットフォーム業者および下請けのソースコード流用問題 - やまもといちろうBLOG(ブログ)
  • Amazon Route 53による重み付けGSLB(Global Server Load Balance) | DevelopersIO

    GSLB(Global Server Load Balance)とは? GSLBとは、その名の通り地域的に離れたサーバーへ負荷分散する仕組みです。通常のロードバランサーは、同じ建物やラックの中で負荷分散をしますが、GSLBでは東京リージョンとシンガポールリージョンなど地域をまたいで負荷分散することができます。Amazon Route 53では、名前解決に重み付けをする形でGSLBを実現しています。 複数のリージョンにインスタンスを立てる 東京リージョンとシンガポールリージョンにインスタンスを立てます。 東京リージョンはこちら。動作が分かりやすいようにTokyo page!と表示させています。 続いてシンガポールリージョンにインスタンスを立てました。Singapore page!と表示させています。 Amazon Route 53でAレコードの重み付けをする。 2つのリージョンでインスタンス

  • DWR-PGのSIMロック解除(PWR-100F化) - hill-climber.com

    プラスエリアにも対応して何かと便利なDWR-PGだが、DoCoMoのSIMロックがかかっているため他社のSIMが使えない。近々海外出張の予定もあるため、現地で入手したSIMも使えるようにSIMロックを解除してみた。 1. 下記をダウンロードして同じフォルダに入れる。 PotaPhiChange.exe 光ポータブルPWR-100F用ファームウェア 2. PotaPhiChange.exeを実行し、メッセージに従って番号を選択していくとDWR-PGtoPWR-100F_Update.exeが作成される。 3. DWR-PGを体に付属されているUSBケーブルでPCと接続して、DWR-PGを再起動。 4. DWR-PGtoPWR-100F_Update.exeを実行するとファームウェアのアップデート開始。 上記の手順に成功するとSBや海外通信業者のSIMが使えるようになるはず。ちなみにPWR-

  • 0円の広域負荷分散システムCloudFlareが素晴らしい件 | fladdict

    fladdictの非公式プロジェクト(いわゆる裏dicct)に、posemaniacs.com というサービスがある。 絵のデッサン素材を無料配信するサイトだけど、いつのまにやら老舗サイトに。気がついたら1日の転送量が30〜40GBまで膨れ上がっていた。あまりの負荷にホスト元のhetemlさんでアクセス規制、あわや閉鎖の危機の大ピンチ。わりと気で、Pixivとか星海社とかマール社にサービス譲渡とかしようか悩んだ今日この頃でした。 そんな折、@ku_suke さんのご了解で導入してみた、CloudFlareというサービスが、全ての危機を救ってくれた。マジ多謝です。 どういうサービス? CloudFlareはCDN(広域負荷分散システム)。世界5カ所にデータセンターを有し、データをキャッシュして各地に配信するこで負荷分散してくれる。いわゆるAkamaiの同類だけど、ものすごい特徴が1つある。

  • TCP/IP エラー処理 connect 編

    connect(2) のエラー TCP において connect(2) 呼出し時に発生する可能性のあるエラーは以下の通りです。 タイムアウト RST 受信 EHOSTUNREACH また ENETUNREACH シグナル受信 その他 まず、connect(2) 時の正常な流れをしっかり覚えておいてください。 (connect(2) を呼んで) SYN を送る SYN+ACK が返ってくる (ここで connect(2) から戻る) ACK を送る タイムアウト もし仮に、SYN を送ったものの、相手側から SYN+ACK が返ってこない場合は、 (ローカルの TCP スタックが) しつこく SYN を再送します。何度 SYN を送っても SYN+ACK が返ってこない場合はあきらめてタイムアウトします。 「SYN+ACK が返ってこない」というのは、例えば以下のようなケースが考えられます。

  • TCPメモ(Hishidama's TCP Memo)

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

  • Linux socket プログラミング/パケットモニタリングプログラム

    無差別受信モードへの設定の方法は、かつては、 INET ドメインの SOCK_PACKET ソケットを作成し、ifr_flags に IFF_PROMISC をセットする というやり方が主流だったのですが、現在は上記のように PF_PACKET ドメインの SOCK_RAW ソケットもしくは SOCK_DGRAM ソケットを作り、setsockopt()にて無差別受信モードをセットする というやり方が主流のようです。(man packet(7) 参照) ↑ 1 /* 2 * packet monitor program 3 * pckmon2.c 4 * cc pckmon2.c -lnsl -o pckmon2 5 */ 6 #include <stdio.h> 7 #include <stdlib.h> 8 #include <netinet/in.h> 9 #include <err

  • 第15回 信頼性のある通信を実現するTCPプロトコル(2)

    TCPヘッダの構造 TCPでは信頼性の高い通信を実現するために、受信確認やスライディング・ウィンドウ制御、そしてさまざまな付加機能などを用意している。そのためUDPよりも複雑なヘッダ情報を持っている。「チェックサム」はIPヘッダなどと同様に、1の補数で計算する。 連載第7回「データグラム通信を実現するUDPプロトコル―2.UDPパケットの構造」で示したUDPパケットの構造と比べると、非常に複雑になっている。UDPでは、通信に先立ってコネクションを確立する必要のないデータグラム型通信モデルを使用しているため、送信される各UDPパケットは完全に独立していた。そのため、UDPパケットごとにあて先のポート番号(送信元を区別するための送信元ポート番号)さえあれば、相手にパケットを届けることができる。 だがTCPでは、通信に先立ってコネクションを開設し、さらに通信中にも、前回解説したシーケンス番号に基

    第15回 信頼性のある通信を実現するTCPプロトコル(2)
  • 覚悟はできてますか? - トンでもなく高価なIPv6

    back 概要: 増えつづける IPv4 の需要に対処するために提案された IPv6 は IPv4 とは互換性がなく、その代用品にはならない。 しかし人々は依然として IPv4 のサービスを必要とする。 したがってたとえ IPv6 が普及しても、その普及率が 100% になるまでは IPv4 の需要は減少しない。そのためサービスを提供する側はつねに IPv4 をサポートする必要にせまられ、IPv6 のメリットはいつまでたっても見えてこない。 結果としてインターネット全体の IPv6 の導入には予想以上の時間とコストがかかり、 普及までには長い忍耐が必要となる。 おことわり: これは Daniel J. Bernstein さん (以下 djb) による IPv6 mess (日語訳) および ngtransメーリングリスト (IPv6 への移行に関する問題を扱っていた) での彼の発言を読

  • 1