google/gopacket + libpcap で作るツールのパケットバッファ戦略 - Copy/Cut/Paste/Hatena
tcpdpの中のお話です パケットを一時的に保持するバッファ google/gopacket/pcap パッケージでパケットを取得するようなツールを作る場合、2つのバッファを持つことになります。 libpcapが持つバッファ google/gopacketが持つバッファ（バッファ付きチャネル）。1000で固定。 パケットは加工されつつ上記のバッファを経由して、最後にgopacketからパケットを受けとることになります。 そしてバッファには、以下のような特徴があります。 libpcapが持つバッファが溢れたらパケットロスが発生します gopacketのバッファサイズは固定です libpcapは ImmediateMode がOFFだと、libpcapが持つバッファにある程度パケットを貯めてからまとめて返します 上記特徴からみても、ツールが正しく動くようにするためには いかにlibpcapのバ
Geekなぺーじ : selectを使う
普通の状態では、readやrecvfromはデータが受信できるまでブロッキングします。 ソケットを一つしか利用していない場合にはブロッキングは非常に便利なのですが、ソケットが複数になると困ってしまいます。 複数のソケットを扱うとき、片方のソケットでブロッキングしたままになってしまうと他のソケットにデータが到着しても受信が出来なくなってしまいます。 そのため、複数のソケットを扱っていると、どのソケットからデータが受信可能か知りたくなります。 ブロッキングとは、関数が返ってこない事を表します。 例えば、readはデータを受信して関数が戻ってきます。 言い方を変えると、データを受信するまでブロックしています。 readやrecvfromをブロッキングしないノンブロッキング方式で使う事も可能ですが、ここではブロッキング方式のまま使う方法を説明します。 そのような機能を提供するのがselectです。
UNIX Domain Socket の SO_SNDBUF, SO_RCVBUF についての覚書 - hibomaの日記
macOS と Linux の UNIX Domain Socket の SO_SNDBUF, SO_RCVBUF について調べていた。 経緯 会社で @kurotaky のトラブルシューティングの相談を受けた際の覚書。 下記のように UNIX Domain Socket を挟んで IPC しているコードがあり、macOS と Linux で挙動が違っているのを調べていた。Linux では Go Ethereum が送ってくるデータを全部読み出せるが、macOS だと一部 ( 8192 バイト 注1 ) しか読み出せないとのことだった。 Ruby のコード <----- UNIX Domain Socket -----> Go Ethereum 色々調べてみたところ、macOS / Linux で UNIX Domain Socket のデフォルトの SO_SNDBUF, SO_RCVBU
或るプログラマの一生 » SOCK_SEQPACKET の使い方
表を見ると分かる通り、ほぼ SOCK_STREAM と同じです。「SOCK_STREAM のデータグラム版」と考えておくのがいいでしょう。 AF_LOCAL (AF_UNIX) での実装 仕様は上のとおりなのですが、実装となるといろいろと細かい話が出てきます。（なお、ここでは AF_LOCAL の話だけします） 多くの POSIX 実装において、（AF_LOCAL では）SOCK_DGRAM は順序性も信頼性も持つ。というか、そうでない実装は見たことがない。つまり、上の表における SOCK_SEQPACKET と SOCK_DGRAM との差異はコネクション指向かどうかという点だけになる。 SOCK_SEQPACKET は実装されていない環境があり、古めの OS だと使えないことがある。NetBSD なんかは現時点の stable である 5.0 ですら使えず、6.0-beta でようやく
FlutterでTCP通信 - Qiita
操作方法 1 装置を起動する 2 コントローラを起動する 3 コントローラからConnectする 4 ボタンが有効になったら、左右に動かす コントローラ import 'dart:io'; import 'dart:typed_data'; import 'package:flutter/material.dart'; import 'package:provider/provider.dart'; void main() { runApp( ChangeNotifierProvider( create: (context) => TcpClient(), child: MaterialApp( home: ClientPage(), debugShowCheckedModeBanner: false, ), ), ); } class TcpClient with ChangeNotif
アーケードゲームを支えるデバッグ術 - SEGA TECH Blog
ブログ読者のみなさん、はじめまして。 株式会社セガのベテランプログラマー阿部です。 このエントリーではデバッグ手法のあれこれについての体験談と、デバッグをテーマに一昨年に実施されたプログラマー向け新人研修の概要をお伝えしたいと思います。 EXE ファイルのデバッグ イーサネット絡みのデバッグ 周辺機器絡みのデバッグ デバッグスキルブートキャンプ 黒子に徹する、裏方系エンジニア EXE ファイルのデバッグ 同僚が作った EXE ファイルが手元にあり、あなたはこれを Windows で起動しようとしています。 起動してみたところ何も反応がなく、しかもそれは想定外のことでした。 「何コレ、動かないんだけど」とあなたが同僚に文句を伝えると、同僚はあなたに返します。 「こっちでは動いてるよ」 困りましたね。 あなたの手元には EXE のソースコードも無ければ、Visual Studio もありません
Rustで、Hello Worldを卒業した？次は、gRPCだよね！
こんにちは、NTTの藤田です。 Rustには公式なgRPCサポートがありません。gRPCなAPIがないなら、何も実装する気になりません、クラウドネイティブ時代ですからね。公式なgRPCサポートがない代わりに、4種類も非公式な実装がありますので、安心です。安定性や、コミュニティの活発度など、様々な比較の観点がありますが、今回は、Rustへの信仰の強さ、という観点で比較しました。 Rustには公式なgRPCサポートがない信仰の強さの評価軸他言語への依存度Rust以外は言語にあらず。他言語の存在を許容するようでは、信仰が強いとはいえません。全てをRustで再実装するべきです。 最新の非同期処理への対応今、Rust界の大きな話題といえば、11月のasync/awaitを利用した非同期処理を実現するためのFuture APIの安定化です。古い異端のコードを捨て、迅速に、定められた、正統な非同期処理の
データを送受信をするIoTデバイスの作り方 [ESP-WROOM-02版]
USBシリアル変換モジュールを使用してArduinoスケッチを「ESP-WROOM-02」に書き込んで「Wifi接続」「ネット上のファイルの取得」「GET/POST」を実行する方法です。 スケッチの書き込み後は「ESP-WROOM-02」だけで動作します。
![データを送受信をするIoTデバイスの作り方 [ESP-WROOM-02版]](https://cdn-ak-scissors.b.st-hatena.com/image/square/4af1465cf1036f95b1b69f4c0702e72611933727/height=288;version=1;width=512/https%3A%2F%2Fwww.petitmonte.com%2Fimages%2Fog_image.jpg)
ESP-WROOM-02 Arduino互換ボードでサクッとHTTP通信できたよ - Qiita
スイッチサイエンス製 ESP-WROOM-02 Arduino互換ボード スイッチサイエンスからESP-WROOM-02 Arduino互換ボードが発売されました。今まではESP-WROOM-02(ESP8266)をArduinoのスケッチを書き込んで使うためには、モジュールをはんだ付けしてブレッドボード上で使用したりと少々使いづらい部分がありました。それをこの互換ボードが解消してくれます ESP-WROOM-02 Arduino互換ボード ESP8266 Arduino CoreでHTTP通信をサクッとやってしまおう Arduino IDEでESP8266の開発を行うときに使うライブラリESP8266 Arduino Coreには、HTTP通信にかぎらず便利な機能が用意されています。Arduino IDEのメニューから[ファイル]→[スケッチの例]にESP8266関連のサンプルがずらっと
ネットワーク - TCP - boostjp
インデックス 接続 接続待機 メッセージ送信 メッセージ受信 名前解決して接続 タイムアウトを設定する 接続 同期バージョン 同期バージョンの接続には、boost::asio::ip::tcp::socketクラスのconnect()メンバ関数を使用する。 接続先の情報はtcp::endpointに、IPアドレス文字列と、ポート番号の2つを指定する。 connect()の第2引数としてerror_codeを渡した場合には、接続失敗時にエラー情報がerror_code変数に格納される。 error_codeを渡さなかった場合には、接続失敗時にboost::system::system_errorが例外として投げられる。 #include <iostream> #include <boost/asio.hpp> namespace asio = boost::asio; using asio:
boost.asioのタイムアウト処理を綺麗に書く方法教えて！ - Qiita
はじめに boost.Asioでは、非同期処理のタイムアウト処理を当然行うことが出来るが 一般的なソケットのような、関数にタイムアウト時間を設定するような簡易な方法ではない 非同期処理とは別に、タイマーWaitを非同期で書き、非同期処理が終了すればタイマーをキャンセルし タイマーが先に来れば 非同期処理をキャンセルしタイムアウト処理を行う という 冗長な処理が必要である それを、どのようにラップすればきれいに書けるのか？という話 まずはベタに書いてみる // タイムアウトを設定 deadline_timer.expires_from_now( boost::posix_time::milliseconds(timeout_ms)); deadline_timer.async_wait( [=](const boost::system::error_code &ec) { // タイムアウト
Boost.Asio 非同期処理のタイムアウトを設定する - Faith and Brave - C++で遊ぼう
タイムアウトには、async系メソッドと別にdeadline_timerを動かし、タイムアウトを設定します。 タイムアウトの前に非同期処理が完了した場合はdeadline_timer::cancel()を呼び、タイムアウト用のタイマーをキャンセルします。 そうすると、タイムアウトのハンドラが呼ばれなくなる・・・のではなく！タイムアウトのハンドラにエラー(boost::asio::error::operation_aborted)が渡されるので、タイムアウトハンドラがエラーじゃなかった場合に実際のタイムアウト処理を行います。 以下、サンプルコード： #include <boost/asio.hpp> #include <boost/bind.hpp> #include <iostream> namespace asio = boost::asio; class Client { asio::
ネットワーク越しリトライ考 - その手の平は尻もつかめるさ
ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン
シェルスクリプトでIPアドレスの計算 | Folioscope
IPAM や DHCP サーバーを実装するとき、IP アドレスを機械的に生成するために、IP アドレスの計算をする事があります。 例えば IPAM がラックやデータセンターから機械的に IP アドレスを割り当てたり、DHCP サーバーが連番の IP アドレスを割り当てたりします。 この記事ではシェルスクリプトで IP アドレスを計算する方法を紹介します。 IP アドレスと数値の変換 IP アドレスを計算する上で欠かせない操作が、IP アドレスと数値の相互変換です。 IPv4 アドレスは長さ 4 のバイト列に過ぎませんが、通常は192.168.0.1 のように人間の扱いやすい文字列で表現します。 一方 IP アドレスを計算するには、IP アドレスをバイト列や 32 ビット数値などの、計算機で扱いやすい形に変換します。 IP アドレスを数値として扱えると、数値演算で IP アドレスを計算したり
RTTとは - IT用語辞典
RTTとは、通信相手に信号やデータを発信してから、応答が帰ってくるまでにかかる時間。相手との物理的な距離や、経路上で中継・転送する装置などの数や処理時間に左右される。 電子回路や通信システムなどで、伝送にかかる時間を表す特性の一つとしてよく用いられる。双方向でやり取りを行うシステムの場合、回線などの時間あたりの伝送容量（帯域幅や通信速度）がいくら大きくても、RTTが大きければ送受信の度に大きな待ち時間が発生し、トータルの実効速度（スループット）や使用感は大きく損なわれる。 類義語：レイテンシ/レスポンスタイム発信した信号やデータが相手に届く（あるいはその逆）までにかかる時間は「レイテンシ」（latency/遅延時間）と呼ばれる。多くの場合、RTTはレイテンシの2倍に相手方での処理時間（物理的な反射などの場合はゼロ）を加えたものとなる。また、システムの応答や反応にかかる時間を表す場合、入力が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DartでSocket通信 | blog.monophile.net
How can i connect to TCP socket (not web socket) in flutter?
Socket class - dart:io library - Dart API
ESP HTTP Client - ESP32 - — ESP-IDF Programming Guide v5.2.1 documentation
https://www.zombie-hunting-club.com/entry/2015/06/17/113527