コグノスケ

未来から過去へ表示(*) link

過去から未来へ表示

もっと前

2015年8月18日 >>> 2015年8月5日

もっと後

2015年8月18日

permalink

編集する

netcat traditional版とnetcat OpenBSD版

ネットワークを経由した送受信を実現するのに便利なnetcatというツールがあります。わざわざソケットプログラムなどを書かなくても、単純な送受信が実現できる優れものです。

利用イメージは、Aというマシンで、produce_something | ncとしてnetcatでネットワークに送信し、Bというマシンでnc | consume_somethingとしてnetcatでネットワークから受信します。まるでネットワーク越しにパイプを繋ぐかのような感覚で利用できます（ncはnetcatのコマンド名）。

さてこのnetcatですがDebian Jessieで利用可能なnetcatは下記の2種類があります。

netcat traditional版（パッケージ名netcat-traditional）: Hobbitさんが書いたオリジナルのnetcatです。コマンド名はnc.traditionalです。
netcat OpenBSD版（パッケージ名netcat-openbsd）: OpenBSDのナイスガイ達が書き直して、機能追加したnetcatです。コマンド名はnc.openbsdです。

結論を先に書くと、特に理由が無ければnetcat OpenBSD版をオススメします。こちらの方が新しくて、多機能です。変な動きもしません。

netcat traditionalの変な動き

何が「変な動き」かというと、下記のようなごく普通の使い方でもnetcat traditionalは必ず終端でハングアップしてしまいます。

netcat traditionalにEOFを送ったときの動き

----- 送信側host1
nc.traditional host2 55555
（Ctrl+Dを押してEOFを送る）
（終了しない。。。）

----- 受信側host2
nc.traditional -l -p 5555
（終了しない。。。）

どうも入力に来たEOFの扱いが上手くない？ようで、EOFを受けるとCtrl+Cなどでkillしない限り、ずっと止まったままになってしまいます。この挙動を防ぐには -qというオプションでEOFが来たときの挙動を指定する必要があります。

netcat traditionalでEOF受信時の挙動を指定する

----- 送信側host1
nc.traditional -q 0 host2 55555
（Ctrl+Dを押してEOFを送る）
（終了する）

----- 受信側host2
nc.traditional -q 0 -l -p 5555
（送信側が終了したタイミングで終了する）

これで万事解決に見えますが、残念なことにnetcat tradtionalは標準入力から入力待ちするため、受信側をバックグラウンドに送ると入力待ちで停まってしまいます。

netcat traditionalをバックグラウンドで動作させると止まる


----- 送信側host1
while : ; do \
	cat /lib/x86_64-linux-gnu/libc-2.19.so | \
		nc.traditional -q 0 host2 5555 ; \
	sleep 1 ; \
done


----- 受信側host2
（準備）
rm pipe recv_file
mkfifo pipe
cat pipe > recv_file

cat > recv.sh << EOS
#!/bin/sh

while : ; do \
	nc.traditional -q 0 -l -p 5555 > pipe ; \
	sleep 1 ; \
done
EOS
chmod 755 recv.sh

（端末その1）
./recv.sh &
（Enterキーを押し続けると…）
[1]+  停止                  ./recv.sh★★★★止まってしまう★★★★

（端末その2）
while : ; do \
	cat pipe > recv_file ; \
	sleep 1 ; \
done

私の知る限りnetcat traditionalでこの問題を解決する方法はありません（たぶん）。代わりにnetcat OpenBSDを使って解決します。

なんとnetcat OpenBSDには -dオプションという標準入力を開かないように指定するそのものズバリのオプションがあるのです。

netcat OpenBSDで -dオプションを指定

----- 送信側host1
さっきと同じなので省略

----- 受信側host2
（準備）
cat > recv.sh << EOS
#!/bin/sh

while : ; do \
	nc.openbsd -d -l -p 5555 > pipe ; \ ★★★★nc.traditionalをnc.openbsdに変え、-dオプション追加★★★★
	sleep 1 ; \
done
EOS
chmod 755 recv.sh

（端末その1）
./recv.sh &
（Enterキーを押し続けても止まらない）

（端末その2）
さっきと同じなので省略

これでバックグラウンドに送ったnetcatが突然停止することはないはずです。

まとめ

以上の話をまとめると、

netcat traditionalを使うときは -qオプションを使ってEOFで止まらないようにしよう
netcat traditionalはバックグラウンドでの利用に適していないと思われる
バックグラウンドでnetcatを使うときは、netcat OpenBSDと -dオプションを使おう

結論をもう一度書いておくと「特に理由がないならnetcat.openbsdがオススメだよ！」ってことです。

編集者:すずき(2015/08/18 23:34)

コメント一覧

コメントはありません。

この記事にコメントする

2015年8月12日

permalink

編集する

SoCの製造元は言えません？

JBPress - 「司令塔がふたり」の異常事態を乗り越えた世界初※4K入力対応タブレット開発の舞台裏を読んで。

元々タブレットPCは映像入力できること自体が珍しいので「映像入力って誰か使うの？」と言われても不思議ではありませんが、そこにあえて「4K入力」を付けちゃう辺り、逆向きにぶっ飛んでる面白い商品だと思います。

京都がSoCの開発拠点だと書いてあるし、たぶん同じ部署の人がやってたアレだと思うんだけど、SoCの名前が書いて無いんですよね。

名前を出せないor出したくない？何かあるのかな…。

メモ: 技術系の話はFacebookから転記しておくことにした。

編集者:すずき(2015/11/29 04:21)

コメント一覧

コメントはありません。

この記事にコメントする

2015年8月11日

permalink

編集する

確率なんて飾りです（その2）

先日（2015年8月8日の日記参照）の続きです。SDガンダムジージェネレーションフロンティアのアイテムドロップ確率、やはり均等に出ている気がしないので、別のステージを使って100回ほど測り、出た順序も記録してみました。

113回中（一応、星が多いほど出やすい、ことになっている）

★: 8
★★: 3
★★★: 22
★★★★: 14
★★★★★: 66

前はたくさん出た ★4が消え ★5が倍増しました。なんだこれ。

下記は出現順序データです。

1, 4, 3, 5, 1, 5, 5, 5, 4, 1,
3, 5, 5, 5, 3, 3, 5, 1, 3, 4,
5, 3, 5, 1, 3, 1, 5, 5, 3, 5,
5, 5, 5, 3, 5, 3, 5, 4, 5, 5,
5, 2, 5, 5, 5, 5, 4, 4, 5, 5,
3, 4, 1, 5, 4, 4, 5, 5, 5, 5,
5, 5, 4, 2, 3, 5, 5, 5, 3, 5,
5, 5, 4, 3, 5, 1, 5, 5, 5, 5,
5, 5, 5, 5, 4, 2, 5, 5, 5, 3,
5, 5, 5, 5, 3, 4, 5, 4, 3, 3,
5, 5, 5, 5, 5, 5, 3, 5, 3, 5,
5, 3, 3,

前半30回で★1は6個、後半83回で★1は2個、と異様に前半に偏りました。偶然なのか、バカにしてるのか…どっちだろ。

（※）実験に使ったステージは、下記の通り。
SPクエスト「LCAM-01XB建造計画」 - 特級