インデックス 接続 接続待機 メッセージ送信 メッセージ受信 名前解決して接続 タイムアウトを設定する 接続 同期バージョン 同期バージョンの接続には、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では、非同期処理のタイムアウト処理を当然行うことが出来るが 一般的なソケットのような、関数にタイムアウト時間を設定するような簡易な方法ではない 非同期処理とは別に、タイマーWaitを非同期で書き、非同期処理が終了すればタイマーをキャンセルし タイマーが先に来れば 非同期処理をキャンセルしタイムアウト処理を行う という 冗長な処理が必要である それを、どのようにラップすればきれいに書けるのか?という話 まずはベタに書いてみる // タイムアウトを設定 deadline_timer.expires_from_now( boost::posix_time::milliseconds(timeout_ms)); deadline_timer.async_wait( [=](const boost::system::error_code &ec) { // タイムアウト
タイムアウトには、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::
自分のサーバーの任意のポートへの接続を待ち受けて、そのまま別サーバーの別ポートへ転送する=ポートフォワード=にはstoneというソフトが定番?であったがもう古いもので、最新のOpenSSLライブラリではコンパイルできなくなってしまった(当方環境では)ので困っていたが現在ではsocatというコマンドで代用するらしいのでメモ。 インストール apt install socat 実行例 ローカルの8443ポートをexample1155.jpの443ポート(https)に転送する socat TCP4-LISTEN:8443,fork TCP4:example1155.jp:443 バックグランドで実行するには&をつける socat TCP4-LISTEN:8443,fork TCP4:example1155.jp:443 & このローカルマシンのIPが192.168.1.55であるとすると、ブラ
お客様各位 日頃弊社インターネットサービスをご利用頂きありがとうございます。 掲題の件につき下記の通りご連絡いたします。 【事象の概要】 弊社インターネットサービスで楽天モバイルの無料通話アプリ「Rakuten Link」を利用すると通話に支障がある。(片通話になったり発着信が出来なくなったりする) 【弊社の対応】 弊社インターネットサービスではRakuten Linkの動作は保証できません。 本件については楽天モバイルにお尋ね下さい。 楽天モバイルから弊社に申告するようにという回答があるようですが、弊社では回答すべき内容を楽天モバイルから提供されていません。 【上記対応を決定した理由】 詳細は弊社宛お問い合わせ願います。 【考え得る回避策】 ハイパー120プランまたは光1Gプランをご利用頂き、グローバルIPアドレスをご利用頂くと事象を回避できる可能性があります。 お客様のご判断でこれらプ
エンベデッドチーム 久保田です。 開発環境をWSL2 (Windows Subsystem for Linux)へ移行しました。 タイミングよく、「WSL2でUSBデバイスを使ってみよう」という記事が出回っていたので、aptpod CAN-USB Interface (AP-CT2A) もWSL2で動かせるのではないかという期待からintdash Edge Agent 含めて動作環境を整えてみましたのでご紹介します。 元記事 Adding USB support to WSL2 https://github.com/rpasek/usbip-wsl2-instructions USB support to WSL2 http://ktkr3d.github.io/2020/07/06/USB-support-to-WSL2/ intdash Edge Agent とは intdash Ed
ローカルで動くサーバーソフトをローカルから使うならUNIXドメインソケットで接続したほうがTCP接続よりはるかに高速である。 (ただし将来リモート接続になる可能性が高いなら設定が面倒なのでTCPのままのほうがよい) PostgreSQL postgresql-server側の設定 postgresql.conf unix_socket_directories = '/var/run/postgresql' # comma-separated list of directories # (change requires restart) unix_socket_group = '' # (change requires restart) unix_socket_permissions = 0777 # begin with 0 to use octal notation 再起動 /etc/i
The network configuration abstraction renderer Netplan is a utility for easily configuring networking on a linux system. You simply create a YAML description of the required network interfaces and what each should be configured to do. From this description Netplan will generate all the necessary configuration for your chosen renderer tool. How does it work? Netplan reads network configuration from
日本時間2011年2月3日深夜に、IPv4アドレスの中央在庫(IANA在庫)が枯渇しました。 もう、あれから10年です。 JPNIC : IANAにおけるIPv4アドレス在庫枯渇、およびJPNICの今後のアドレス分配について(2011年2月) 昔は、「IPv4アドレスは枯渇しない」と主張している人も多く、実際に枯渇するまでは、IPv4アドレス在庫が減り続けていることを信じない人も多かった記憶があります。 都市伝説だ、とか、石油と一緒で枯渇しない、といった主張がありました。 IPv4アドレス在庫の枯渇がどのように定義されているのかが複雑であるためわかりにくかったり、インターネットが使えれば良くてTCP/IPそのものには興味がない人が大半であるなどの要因もあり、いまだにIPv4アドレス在庫が枯渇したことを知らない人も多くいますが、気がつけばIPv4アドレスが枯渇してから10年経過しているわけで
ARP(Address Resolution Protocol)は、指定したIPアドレスからMACアドレスを求めるためのプロトコルです。 LAN上でパケットを送信するためには、IPアドレスだけでなく、送信先コンピュータのMACアドレスを知る必要があります。 通常、ARP要求をブロードキャストで送信すると、該当するIPアドレスを持つコンピュータがARP応答を返してきます。 (ここでいうARP要求のブロードキャストとは送信先のMACアドレスをFF:FF:FF:FF:FF:FFにして送信することです。) arpingは同じサブネット上の指定のIPアドレスからARP応答が返ってくることを確認するコマンドです。 arpingの基本的な使い方 arpingの例として、以下のコマンドでは192.168.245.1のmacアドレスを問い合わせます。 $ sudo arping 192.168.245.1
東京と大阪にある自社運営のデータセンターは、堅牢なファシリティに、冗長化された電源と拠点間を結ぶネットワーク、万全のセキュリティ管理がされた設備で運用しています。震度6強の地震にも耐える制震・耐震・免震構造を採用し、冗長構成の無停電電源装置(UPS)とエンジン発電機による電源設備、データセンター専用の高性能ハウジングラックなど、データセンターに求められるファシリティ能力を高次元でクリア。技術者による24時間365日の有人監視体制により、お客様の大切なシステムを安全にお預かりします。 制震・耐震・免震構造の設備とハウジングラック 大規模地震にも耐える、制震や耐震、免震構造を採用したデータセンター専用設計の構造です。また、ラックにもデータセンター専用の高性能ハウジングラックを使用し、お客様のデータを堅牢にお守りするだけでなく拡張性にも優れています。
ウェブサービスのシステム構成は日々変化していくものであり、プログラムのコードと同じようにバージョン管理を行いたいと考える人は多いはず。無料のオープンソースソフトウェア「drawthe.net」を使うと、構造化データを表現できるYAMLでネットワーク構成図を書くことができます。 GitHub - cidrblock/drawthe.net https://github.com/cidrblock/drawthe.net drawthe.net: Enterprise NTP http://go.drawthe.net/ drawthe.netはソースが公開されているので自分でビルドすることもできますが、公開されているウェブアプリを利用することもできます。drawthe.netにアクセスすると、サンプルとしてNTPサーバーの構成図が描かれていました。 自分でYAMLを記述するため、サンプルの記
ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン
lwIP (lightweight IP)は、幅広く使用されているオープンソースのTCP/IPのプロトコルスタックの実装であり、組み込みシステム向けに設計されている。 lwIPは、元々はAdam DunkelsによってSwedish Institute of Computer Scienceにおいて開発されていた。 現在は、世界中の開発者のネットワークによって開発されメンテナンスされている。 lwIPは、多くの組み込みシステムのメーカーで使われている。 アルテラ (Nios IIオペレーティングシステムにおいて)、アナログ・デバイセズ (Blackfin DSPチップのために)、[1]ザイリンクス、[2]ハネウェル (FAA認証を受けた航空システムに使用しているものがある)、フリースケール・セミコンダクタ(自動車向けマイクロコントローラー用のイーサネットストリーミングSW)などがその例であ
LTEもWi-Fiも、快適に使えるLTEモバイルルータ インターネットへの接続は、LTE回線(受信時150Mbps※2、送信時50Mpbs※2)に対応。スマートフォンなどと接続するWi-Fiは、電波干渉の少ない5GHz帯11ac※3の1ストリームに対応し、最大433Mbps※4で通信ができます。 タブレット、スマートフォン、ノートパソコンなどのモバイル機器を10台まで同時接続することが可能でベンリに使えます。 ※1 各通信事業者により、通信速度・エリアなどの提供サービスは異なります。詳しくは、通信事業者へご確認ください。なお、LTE-Advancedの技術の一つであるキャリアアグリゲーション(CA)は非対応です。 ※2 通信速度は、送受信時の技術規格上の最大値であり、実際の通信速度を示すものではありません。 ベストエフォート方式による提供となり、実際の通信速度は、通信環境やネットワークの混
こんばんは、cloudpack の 夜のonprepack津村です。 最近すっかり寒くなりましたが、自宅から電気食いの機器を廃止したら急遽暖房の出番が……。 将来結婚した暁には、愛情的にも、排熱的にも暖かい家庭を築きたいです……(ぉ SoftEtherVPNハマりどころ2選 さて、今回はAWSではなく、自宅インフラの話です。 最近自宅サーバを整理し、常時起動の自宅サーバをConoHaへ移設しました。 そして、IX2015とSoftEtherVPNを組み合わせ、EtherIPを使用しL2トンネル・VPNを構築しています。 最終的には「ネットに繋がれば即自宅環境」を目指します。(どや 今のネットワーク環境 ポイントとしては、 オンプレミス・VPNサーバ(ConoHa上)・L2TP/IPSecで同一のセグメントを使用 IX2015とSoftEtherVPNでEtherIPを構成 IX2015でW
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く