今回はソケット通信の最終回ということで、Unixドメインソケットについて紹介します。 UnixドメインソケットはPOSIX系OSで提供されている機能です。 コンピュータ内部でしか使えない代わりに、高速に通信が行えます。 TCP型（ストリーム型）と、UDP型（データグラム型）の両方の使い方ができます。 WindowsではこのUnixドメインソケットをそのまま使うことはできません。 似た概念の機能として、「名前付きパイプ」というものが存在します。 以降の説明では、まずUnixドメインソケットについて説明したあとで、 Windowsの名前付きパイプについても説明します。 （Windowsメインの方は、前半のUnixドメインソケット固有の説明については軽く流して読んでください。） Unixドメインソケットの基本 TCPとUDPによるソケット通信は、外部のネットワークに繋がるインタフェースに接続しま
Performance Analysis of Various Mechanisms for Inter-process Communication Kwame Wright Department of Electrical Engineering The Cooper Union wright2@cooper.edu Kartik Gopalan Hui Kang Department of Computer Science Binghamton University {kartik, hkang}@cs.binghamton.edu Abstract Unix-based operating systems feature several forms of Inter-Process Communication (IPC) including pipes, Unix domain so
ファイル記述子をUnixドメインソケット経由で渡す Unix 系の多くの OSには、ファイル記述子を別のプロセスに Unix ドメインソケット経由で渡す機能があります。一見、何のために使うのかよくわからない機能ですが、 glibc の nscd はこれをうまく使っています。 nscd (name service caching daemon) は glibc 内で行われる名前関連の問い合わせをキャッシュするサーバです。NIS や LDAP などを用いてネットワークベースでユーザ管理を行っている場合、 getpwuid() などの関数はユーザ名の取得にネットワークアクセスを必要としますが、 nscd を立ち上げておけば、二度目からの同じ問い合わせはキャッシュから得られます。 nscd を立ち上げている GNU/Linux システムでは、キャッシュファイルが /var/db/nscd 以下に作
前回までの続き。なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 - 達人出版会をまだ読んでいる。遅読。 Unixプロセスとリソースの基礎を再確認した - えいのうにっき プロセスとの情報のやりとりについて再確認した - えいのうにっき プロセスの適切な扱い方を再確認した - えいのうにっき 今回は、Unixプロセスとシグナルの基礎について再確認していく。 Unixシグナル・事始め Unixシグナルの「いろは」 シグナルを再定義する シグナルハンドリングの注意点 Unixシグナル・事始め 前回、子プロセスの終了を待ち受けるのに用いた Process.wait は、実行するとそこで自身（親プロセス）の処理を止めて子プロセスの終了を待った。これは ブロッキング呼び出し と呼ばれる。 では「親は親で何か別の仕事をしたいとき」はどうするかというと、これから見ていくシグナルを上手に使うと実
1992年のDr. Dobb's Journalの連載記事とともに開発が始まったフリーのUNIX系オペレーティングシステム「386BSD」。無料で利用できるBSD系OSの元祖として知られていますが、0.1リリース後開発が停滞し、多くの開発者達が、FreeBSDやNetBSDといった他のOSに移行したという経緯を持っています。 ところが最近、386BSDの創始者の一人、Lynne Jolitz氏が最新版であるv1.0/v2.0のソースコードをGitHub上に突如(?)、公開していたことが分かりました(slashdot)。 386BSDは開発者がUNIXシステムの全てを把握できた時代の貴重な遺産で、Linuxを開発したLinus Torvalds氏も、「386BSDが入手可能であったならば、Linuxを作ることはなかっただろう」と発言しています。 実際に動作させる場合、エミュレーターであるQe
_ なぜUnixはUnixなのか（Unix考古学を読み始めた） アスキーの鈴木さんにUnix考古学を頂いたので読み始めて、シェヘラザードの代わりに寝台の脇に置いて何夜か過ぎて大体半分読んだ。 抜群におもしろい。単なる読み物としてもおもしろいのだが、おおそういう理由でそうだったのか/こうなっているのかという説明が（あとがきを読むと、筆者は類書をネタにしているのではなく（ゼロではないだろうけど）、当事者たちのログや論文を読むことで事実関係を掘り起こして推測して結論づけたりしている。なるほど、その作業は電子の地層から掘り起こして塵を払ってつなぎ合わせて当時を復元していく作業にそっくりだ。それで「考古学」なのだな）なかなかに快刀乱麻で読んでいて実に楽しいのだ。 まずまえがきにぶっとぶ。 読み進めて次の文章に腰を抜かした。 人づてに聞いた話だが、著者の藤田氏は1970年代生まれよりも若い年代に本書を
2015-07-23 x86 Linux シェルを起動するシェルコードの作成 pwn 前回はHello, World!を出力するシェルコードを書きましたが、やはりシェルを起動しないとシェルコードらしくないのでシェルを起動するシェルコードを書いてみます。プログラムを起動するシステムコールはexecveです。これを使用してシェルを起動するシェルコードを書いてみます。 C言語での記述 execveのマニュアルを読む $ man 2 execve 名前 execve - プログラムを実行する 書式 #include <unistd.h> int execve(const char *filename, char *const argv[], char *const envp[]); 説明 execve() は、filename によって指定されたプログラムを実行する。 filename は、バイナ
toRuby & guRuby 出張版 でシグナルについてやってたので、関連して書いてみます。 どのような時にシグナルハンドラを定義するのか どのような時にシグナルハンドラを定義するのかという話がありました。 UNIXのデーモンプログラムは、何が由来なのかわかりませんが、SIGHUP で設定ファイルの再読み込みを行うのが慣習になっています。 SIGHUP はデフォルト動作ではプログラムを終了させてしまうだけなので、SIGHUP で特別な処理を行いたいプログラムはシグナルハンドラを定義しています。 本来 SIGHUP は端末が終了した時に端末上で動いていたプログラムに対してOSが発行するためのものです。 たとえば、端末エミュレータを開いて、 % sleep 9999 と実行してる状態で端末エミュレータを閉じると sleep プロセスに SIGHUP が送られます。別の端末から strace
2014-09-03 (Wed)#1ふと openSUSE 13.1 を install してみた。lsb_release の Description と /etc/os-release の PRETTY_NAME は一致しているようだ。 % lsb_release -a LSB Version: n/a Distributor ID: openSUSE project Description: openSUSE 13.1 (Bottle) (x86_64) Release: 13.1 Codename: Bottle % cat /etc/os-release NAME=openSUSE VERSION="13.1 (Bottle)" VERSION_ID="13.1" PRETTY_NAME="openSUSE 13.1 (Bottle) (x86_64)" ID=opensuse A
_ Dart アスキーの鈴木さんからプログラミング言語Dartを頂いた。 また新しい言語か、と思いながらパラパラ見てみると、なんか雰囲気が良いので少しまじめに読んでみた。 JavaScriptとJavaとC#の良いとこどりと書いてあるが、特徴は次のところだろう。 ・関数の記述はC#やJavaのラムダ式のように楽ちん。例）(x, y) => x * y ・EclipseベースのIDEが最初から用意されている ・型名の明示が可能（finalのような修飾子もあるし、リストとマップにはジェネリクスも利用できる）なので、型チェックを最初からされるのが好きな開発者でもOK（TODO:varで宣言した変数に限り、JavaScript並の自動型変換がある（便利ではあるけど諸刃の剣なのでそこを宣言で制御できるのなら良いと思った）かどうかは、ぱらぱら読んだだけだとわからなかった） ・クラスベースだが、必ずしも
Many people don’t realize that changing the target of a symbolic link (symlink) is not an atomic operation. “Changing” a symlink really means deleting it and creating a new link with the same file name. For example, if I have a symlink current that points to a directory old, and I want to change it to point to a directory new, I might use the following command: $ ln -snf new current Strace shows w
このFAQについて 1 プロセス制御 1.1 新しいプロセスの生成: fork() 1.1.1 fork()は何をするのですか? 1.1.2 fork()とvfork()の違いは何ですか? 1.1.3 forkによる子プロセスを終了するときにexitよりも_exitを使うのはなぜですか? 1.2 環境変数 1.2.1 どうすればプログラム内で環境変数の値を取得・設定できますか? 1.2.2 どうすれば全ての環境変数を調べられますか? 1.3 どうすれば一秒未満のsleepができますか? 1.4 粒度の細かいalarm()はどうすれば得られますか? 1.5 どうすれば親プロセスと子プロセスの間で通信できますか? 1.6 どうすればゾンビプロセスができることを防ぐことができますか? 1.6.1 ゾンビプロセスってなんですか? 1.6.2 どうすればゾンビプロセスになることを防げますか? 1.7
UNIX プログラミングテクニック を読みかえしていたら，以下のような解説が目に止まった．当時は何とも思わなかったもの，少し前まで Inferno の sh に clear が無いことを不思議に思い，調べているうちに Plan9 の哲学についての理解が深まった現在においては，いろいろと思うところがある． 端末にはいろいろな機能があります．たとえば，画面をクリアする clear は，ある文字列を端末に送るだけの単純な命令です．次のコマンドを実行してみましょう． % clear | cat -v ^[[H^[[2J % 出力は，端末の種類ごとに違います．xterm や kterm では上の例と同じ出力が得られますが，Sun のコンソールなら ^L， FreeBSD のコンソールでは ^[c になります． 端末は，これらの文字列を受け取ると，画面をクリアして左上にカーソルを移動します．これが，端
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
