tcp shutdown(2)の動きを見たりする - 地方エンジニアの学習日記
またまたTCPネタ。 www.amazon.co.jp を読んでいたら出てきた、shutdown(2)が色々と気になったので実験してみた。manを引くとこんな感じ。ざっくり言うとsocketに対して送信を行わない通知をしたら受信をしない通知をしたりするという機能となっています。SHUT_RDとSHUT_WRとSHUT_RDWRでそれぞれどう言うことが起きてるのかをtcpdumpを使って観測してみます。 書式 #include <sys/socket.h> int shutdown(int sockfd, int how); 説明 shutdown() は、 sockfd に関連づけられているソケットによる全二重接続 (full-duplex connection) の一部または全てを閉じる。 how が SHUT_RD ならば、それ以降の受信を禁止する。 how が SHUT_WR ならば
1回のソケットのsend()やssl_write()で送るバイト数の適切サイズ
ソケットの一回の送信で適切なサイズはありますか？ たとえば65535バイト送信したいとします。 下記のように全て送るか、 socket.send(buf, 65535); 下記のように小分けに送るか socket.send(buf, 2048); // bufを2048進めて繰り返す また、適切なサイズがあったとして OpenSSLのssl_write()の場合は事情が少し違うなどの情報もありましたら教えていただけると助かります。 個人的にはTCPの(イーサネットを考慮した)1セグメントは1460バイトらしいので、1460以上の場合は1460単位で分割して送るのが良いような気がしています。
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
【続】tcpの仕様上、接続先がコネクションをcloseしているかはパケットを一度は実際に送るまでわからないよという話 - Qiita
【続】tcpの仕様上、接続先がコネクションをcloseしているかはパケットを一度は実際に送るまでわからないよという話CGoMySQLTCP はじめに 以前、tcpの仕様上、接続先がコネクションをcloseしているかはパケットを一度は実際に送るまでわからないよという話という記事をかいたのですが、そのきっかけは 以前、アプリからDBにSQLを投げたところ、コネクションがinvalidだというエラーが起きました。この原因自体はとても簡単でサーバ側(DB側)のコネクションを保持するタイムアウト設定がクライアントよりも短かったというだけなのですが、「これってクライアントライブラリ側でソケットにwriteした時点でエラーになるんだからハンドリングしてコネクションプールに保持している他のコネクションをよしなに使ってよ！！」と思ったのでした。 でした。 これはgoのmysqlドライバーを利用した場合に発生
tcpの仕様上、接続先がコネクションをcloseしているかはパケットを一度は実際に送るまでわからないよという話 - Qiita
tcpの仕様上、接続先がコネクションをcloseしているかはパケットを一度は実際に送るまでわからないよという話CTCP はじめに サーバがコネクションをclose後しばらくして、クライアントがwriteしました。関数呼び出しの結果はエラーでしょうか？ 上記の正解は「何事もなく、成功する」です。この挙動が理解できている方はこの記事を読む必要はないかもしれません。 自分は「接続先がcloseしたソケットにwriteした場合はプロセスがSIG-PIPEを受け取るかシグナルをハンドリングしていた場合はEPIPEが返ってくる」と思っていました。 それは、Linuxのマニュアルに以下の記載があるためです。 EPIPE fd is connected to a pipe or socket whose reading end is closed. When this happens the writin
SDKにてTCP/IP通信
○SDKにてTCP/IP通信 ■WinSockを使うプログラムではWSock32.libをプロジェクトに参加させる必要がある 追加→既存項目の追加 にて VCのディレクトリ\Lib\WSock32.lib を追加 ○もしくはマクロで、WSock32.libを参加させます。 #pragma comment(lib, "wsock32.lib") （注意） #include "winsock2.h"は、windows.hの上に書く必要がある。 下に書くとエラーが連発します。 //-------------------------------------------------------------------------------- /* ■TCP/IPクライアントクラス #include <stdio.h> #include <winsock2.h> #pragma comment(li
PythonでTCP/IP通信を使おう！｜もちのき研究所
こんにちは、MSKです。 今日は、PythonでTCP/IP通信を行います。 TCP/IPの概要を解説して、Pythonで実際の動きをみたいと思います。 TCP/IPとは TCP/IP（Transmission Control Protocol/Internet Protocol）とは、インターネット通信や無線通信などに使われている通信プロトコルです。 TCP/IPは今使われている通信プロトコルの中でも最も使われているものの１つです。 TCP/IPの他に有名なものとしてUDPが上げられると思います。 さっきから出てきている「通信プロトコル」とはどういうものかというと、「データ通信を行う際に、送信側と受信側であらかじめ定められた共通のルール」です。 日本語しかわからない人に英語で指示をしても伝わらないように、データ通信の世界でも、この共通のルールを定めておかなければ、送信側と受信側のデータの
ソケットプログラミングのTips
概要 ソケットプログラミングに関するTipsをメモレベルで記載する。 切断検知と経路切断 TCPコネクションの切断検出 対向がclose()、shuttdown()、プログラム終了等をしたときの切断検出について。 OSをシャットダウンさせた場合も通常はアプリケーションの終了処理が走り、正常な切断が動く。 受信側の切断検出は、recv()がlength==0で返ってきたとき、または、errno==ECONNRESETとなる。（ECONNRESETはRSTによって切断された場合） 送信側の切断検出は、切断された後2回目のsend()がエラーとなる。 ※相手がclose()→こちらがsend()→相手にパケットが飛ぶが待ち受けプログラムがいないためRST応答が来る→もう1度send()→エラー ※send()自体はカーネルの送信バッファにデータコピーするだけなので、TCPレベルの応答（送信完了）
TCPとタイムアウトと私 - Cybozu Inside Out | サイボウズエンジニアのブログ
本部長や副本部長もプログラミングを（たまに）することで有名なサイボウズの運用本部長、山本泰宇です。 有名じゃないかもしれませんが、ブログに書いたので有名になるということでご了承ください。 今回は、先日発生した yrmcds に起因する障害の原因と対策を解説します。 yrmcds というのは、サイボウズが開発している memcached 互換のキーバリューストレージです。 問題の理解のため、まず TCP 通信で、通信先の相手の障害にどう対応するか解説します。 データの送信中に相手が落ちるケース このケースはさらに二つに分かれます。 相手の OS は生きているが、通信しているプログラムが落ちるケース 相手の OS ごと（あるいはネットワークごと）落ちるケース 1 と 2 の違いは、前者の場合 RST パケットが返ってくるのに対して、後者ではなにも返ってこない点です。後者の場合、ack されない
TCPサーバーの非同期処理はけっきょくどの手法がいいのか？ - Qiita
昔Unix系システムではselect()でIO処理を非同期にして、ファイルディスクリプタの状態に変化があった場合のみ処理を行うことができた。これはメモリやサーバーリソースが極端に少なかった時代に有効な手法だった(らしい)。90年代後半、00年代前半にはマルチスレッドが主流になり、サーバーサイドではAcceptして受け入れたクライアントのソケットをスレッドに渡して送受信を行うことでコネクションの多重化を行った。(もちろん目的に応じて非同期も活躍していた) 00年代後半からC10K問題が騒がれ、node.jsやnginxが登場した。大量のスレッドを生成してリソースやメモリを消費する方法よりも、再びソケットをノンブロッキングにしてディスクリプタの状態を監視する非同期処理が注目されるようになる。そして最近ではjavascript promise、RX、Reactive Extensionなどクライ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Multithreaded Server C++, Socket Programming