vol43. DNSサーバーとping
たまに、dns server が落ちたりして、名前解決ができない事がある。
これまで、dns server の生存確認に、以下のように、ping を使っていたのだが、
$ ping 156.154.70.1
ping は通らないけど、dnsは動いているということがあるのね。。
(下のスクリーンショットから、ping の応答はないけど、DNSのresponse はあることが確認できる。)
まぁ、冷静に考えれば、そのdns server がicmp プロトコルをサポートしていなければ、
ping に対する応答がないのは当然であるといえば当然なのだが、
icmp はすべてのネットワーク機器はサポートしていると思い込んでいた。。
少しググると、dns のquery メッセージは、dig コマンドで投げることができる。
DNS server が生きていれば、DNS response メッセージを返すので、
これで確認できる。
dig [@server]
$ dig @156.154.70.2 ; <<>> DiG 9.9.5-9+deb8u5-Debian <<>> @156.154.70.2
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1469
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;. IN NS;; ANSWER SECTION:
. 512788 IN NS a.root-servers.net.
. 512788 IN NS b.root-servers.net.
. 512788 IN NS c.root-servers.net.
. 512788 IN NS d.root-servers.net.
. 512788 IN NS e.root-servers.net.
. 512788 IN NS f.root-servers.net.
. 512788 IN NS g.root-servers.net.
. 512788 IN NS h.root-servers.net.
. 512788 IN NS i.root-servers.net.
. 512788 IN NS j.root-servers.net.
. 512788 IN NS k.root-servers.net.
. 512788 IN NS l.root-servers.net.
. 512788 IN NS m.root-servers.net.;; Query time: 20 msec
;; SERVER: 156.154.70.2#53(156.154.70.2)
;; WHEN: Mon Oct 01 18:04:31 EDT 2018
;; MSG SIZE rcvd: 239
ちなみに、Linux では、dns server の設定は、/etc/resolv.conf で行う。
$ cat /etc/resolv.conf
domain ol.csi.178
search ol.csi.178
nameserver 156.154.70.1
nameserver の後のip address がDNS server のip address だ。
vol42. Quitaについて調べてみた
疑問
何か技術情報を調べるためにググると、最近はよくQuitaのサイトに投稿されている記事 がヒットする。
「Quitaって何だろう？」
「Quita はエンジニアに評判がいいと聞くけどなんでだろう？」
「なんでみんな技術ネタはQuita に投稿するの？」
ふと疑問に思ったので、Quitaについて少し調べてみた。
Quitaは
日本で最大のプログラマーコミュニティー
- 言語化することで自分の知識を整理
- 自分の備忘録
- 他者にも最大限貢献したい という目的を果たしている。
再利用可能な技術情報共有サイトというコンセプトに則って、サイトが設計されている
- 情報の取得がしやすい仕組みを整えている。(フォローやストック、ニュース フィード機能など。）
Quitaの概要
Quitaの特徴
- 再利用可能な知識の保存が目的
- タグを付けた文章、シンタックスハイライトされたコードで保存
- ニュースフィード
- エンジニアに特化した
- フォロー
- 興味のある言語をフォローできる
- ストック
- 興味のある記事をストックし、後で閲覧できる
感想
確かにQuitaのサイトを覗いてみると、UIは情報を検索するのに、使いやすそうな印象を受ける。 日本のエンジニアを応援するようなサービスが増えるのは、１エンジニアとしても嬉しい。
海外ではみな技術ネタはどこに投稿するんだろう？ 今度しらべてみよう
vol41. home theater room をつくろう
ミシガン州に住みはじめてはや１年経過。移住当初は文化の違い、言葉の違いに色々大変
な思いもしたが、最近は、ようやく余裕もでて日常生活を楽しめ始めるようになってきた
。
一軒家を賃貸しているのだが、アメリカの家には、地下室があるのが一般的。
finishされていない家も多数ある中、幸いなことに、我が家の地下室は物置場とfinishさ
れている部屋が一つある。
これまで地下室はほとんど利用されず、たまに子供の遊び場として利用したのだが、家族が 子供の夏休みを利用して帰国し、自分の時間を確保できるようになったため 、このチャンス を逃すものかと、この部屋を念願のhome theater room にすることにした。
地下室のtheater roomは、涼しいので夏はとても快適。大音量を出しても、1階には多少音 が伝わるかもしれないが、寝室のある2階までには迷惑かからないので、真夜中にも好き な映画が音楽が楽しめる。
TVはリビングで使っていた55inch のSHARPのTVを移動、あとは、PS4とDVD/Blueray player (アメリカではregionが日本と異なるため、PS4でアメリカのDVDは見れない。 Bluerayはregion freeなため視聴可能)を地下に移動する。あとは、音響だ。理想はもち ろん7.1ch !!
調べ始めると、アンプは思ったよりも安価で手に入る。
あとはスピーカーだけど、ググるとうわーめっちゃ高い。一つのスピーカーに５万も払えないよー
。どうしようー。でいろいろ調べてみると、以下のやつが手頃で良さそう。まずはこのエ
ントリーモデルのやつから初めて、もし欲が出て来たら少しずつ買い足していこうかな。
。
- Speaker
- Yamaha NS-SP1800BL 5.1ch
- $149
- Yamaha NS-SP1800BL 5.1ch
この世界は本当に「底のない沼」世界で、追求すればするほど、お金が湯水のようにとん
でいくみたい。スピーカー一つに何十万円もかけるらしいので気をつけなくては。。
vol40. RTP関連のRFCたち
RTPにまつわるRFCの内容を整理してみた。
RTP(Real-time Transport Protocol)。音声や動画などのデータストリームをリアルタイ ムに配信するための、通信プロトコル。でも、どういう仕組みで、リアルタイムを実現し ているのか？
RTPはアプリケーション層のプロトコル。 トランスポート層に通信オーバヘッドの軽く、再送要求のない、UDPを用いるだけでは不 十分なのか？
そんなことをふと疑問に思ったので、調べてみた。
一言でまとめると、UDPはsequence number がないので、順序の組み立てができない。 よって、RTPの「sequence number」を用いて、正しい順番にパケットを並び戻すことができる。 また「timestamp」を用いることで、意図的に遅延したフレームは破棄をすることで、 リアルタイム性を確保できる。
調べてみると、RTP基礎部分のRFCだけでもいくつかあるので、いかにまとめておく。
RTP: A Transport Protocol for Real-Time Applications
- RFC number
- RFC3550
- RFC1889(obsolete)
- 内容
- RTP header の定義
- 送信側のパケット送出タイミングを受信側でも復元できるようにする
- 符号データのパケット化
- 送信者のシーケンス番号とタイムスタンプ情報を送信
- 受信側は、これを参照にリアルタイム性を確保
- 送信側のパケット送出タイミングを受信側でも復元できるようにする
- RTP header
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- RTP header の定義
RTP Profile for Audio and Video Conferences with Minimal Control
- RFC number
- RFC3551
- RFC1890(obsolete)
- 内容
- 符号データごとの具体的なフレーミング方法，すなわちRTPパケットのフォーマット
オーティオやビデオデータの圧縮方法ごとにペイロードフォーマットがある それらを定義
定義されている payload type (audio)
PT encoding media type clock rate channels name (Hz) ___________________________________________________ 0 PCMU A 8,000 1 1 reserved A 2 reserved A 3 GSM A 8,000 1 4 G723 A 8,000 1 5 DVI4 A 8,000 1 6 DVI4 A 16,000 1 7 LPC A 8,000 1 8 PCMA A 8,000 1 9 G722 A 8,000 1 10 L16 A 44,100 2 11 L16 A 44,100 1 12 QCELP A 8,000 1 13 CN A 8,000 1 14 MPA A 90,000 (see text) 15 G728 A 8,000 1 16 DVI4 A 11,025 1 17 DVI4 A 22,050 1 18 G729 A 8,000 1 19 reserved A 20 unassigned A 21 unassigned A 22 unassigned A 23 unassigned A dyn G726-40 A 8,000 1 dyn G726-32 A 8,000 1 dyn G726-24 A 8,000 1 dyn G726-16 A 8,000 1 dyn G729D A 8,000 1 dyn G729E A 8,000 1 dyn GSM-EFR A 8,000 1 dyn L8 A var. var. dyn RED A (see text) dyn VDVI A var. 1 Table 4: Payload types (PT) for audio encodings定義されている payload type (video)
PT encoding media type clock rate name (Hz) _____________________________________________ 24 unassigned V 25 CelB V 90,000 26 JPEG V 90,000 27 unassigned V 28 nv V 90,000 29 unassigned V 30 unassigned V 31 H261 V 90,000 32 MPV V 90,000 33 MP2T AV 90,000 34 H263 V 90,000 35-71 unassigned ? 72-76 reserved N/A N/A 77-95 unassigned ? 96-127 dynamic ? dyn H263-1998 V 90,000 Table 5: Payload types (PT) for video and combined encodings
RTP Payload Format for H.264 Video
- RFC number RFC6184 RFC3984(obsolete)
- 内容
- h264 をRTPにのせる為のpayload format を定義
3種類のpayload structure を用意
- Single NAL Unit Packet
- 一つのNAL unitを一つのRTP message で送信する
- Aggregation Packet
- 複数のNAL unitを一つのRTP message で送信する
- Fragmentation Unit
- 一つのNAL unitを複数のRTP message に分割して送信する
Table 1. Summary of NAL unit types and the corresponding packet types NAL Unit Packet Packet Type Name Section Type Type ------------------------------------------------------------- 0 reserved - 1-23 NAL unit Single NAL unit packet 5.6 24 STAP-A Single-time aggregation packet 5.7.1 25 STAP-B Single-time aggregation packet 5.7.1 26 MTAP16 Multi-time aggregation packet 5.7.2 27 MTAP24 Multi-time aggregation packet 5.7.2 28 FU-A Fragmentation unit 5.8 29 FU-B Fragmentation unit 5.8 30-31 reserved -
- 一つのNAL unitを複数のRTP message に分割して送信する
- Single NAL Unit Packet
Ethernet AVB IEEE1722 で定義されているstream format の一つであるCVFを用 いて、h264 を送信する際も、このプロトコルを利用する
Value Name Description 0 MJPEG MJPEG Format (RFC 2435) 1 H264 H.264 Format (RFC 6184) 2 JPEG2000 JPEG 2000 Video (RFC 5371) IEEE1722-2016 Table 20 format_subtype field for RFC Format より
vol39. 日本 vs ポーランド戦で思うこと
サッカーW杯2018、1次予選 第３戦の試合をTV観戦した。
結果は0-1の敗戦だったが、日本代表は勝点4で、同H組2位を争うセネガルをフェアプレイ ポイント差でかわして、決勝トーナメントに進むことが出来た。
でも、観戦している中で日本代表がとった戦術について、いろいろな感情や思いが湧いて きた。きっと、この後、賛否両論、いろいろな意見がネットを中心にとび交うであろう。
その中の一つの意見として、自分もここに意見を述べてみたいと思う。
状況
状況はこうだ。
酷暑、前試合から中3日という状況だったため、日本代表は、先発を6人いれかえ、コンデ ィションのよい選手を優先させた。
試合内容は、日本代表が優勢、後半もチャンスがいくつかあった。しかし、後半14分にフ リーキックから失点。この時点ではコロンビア-セネガルは0-0の同点だったため、追いつ かないと決勝トーナメントに進めない状況。乾を投入し、点を取りにいくが、チャンスを つくれない。ボールも持てない。逆に、カウンターで更に失点する危機が多数。川島の2 度のスーパーセーブでなんとか持ちこたえる状況。
そんな中、 後半29分に、コロンビアが1点決めた。この時点で、セネガルと日本は勝点 数、得失点数、総得点数が共に同じ、直接対決は引き分け、という珍しい状況が起きた。 この場合、フェアプレイポイントと呼ばれる、もらったイエローカードやレッドカードか ら算出されるポイントで上位が判定される。そのフェアプレイポイントの差で日本が2位 の状態となった。
日本は攻めに行くも、まったくボールも奪えず、ボールを奪ってもまともな攻撃ができな い状況。その後、日本は長谷部を投入。セネガルがこのまま負けることを願い、守りには いったのだ。
ボールを保持した状態では、まったく攻めずにボールを回すだけ。守備では、カードをも らわないように接触プレーをさけてのディフェンス。ポーランドも勝っているので、特に ボールを追いかけない。観客からは大ブーイング。結果的にそのまま0-1で日本敗戦のま ま、試合終了。セルビアも0-1でコロンビアに破れ、試合終了。 結果、日本の決勝トーナメント進出が決まった。
感じたこと
この試合を観戦し終わって感じたことは、決勝トーナメントに進めるのは素直に嬉しい。 日本代表の試合が少なくとももう１試合みれるから。
でも、これは、後悔する戦い方だったと思う。
もし、セネガルが点を決めて追いついていたら、日本は決勝トーナメントに行けなかった 。その為に、決勝トーナメントにいけなかったら、本当に悔やんでもくやみきれない、他 者依存の戦い方だ。
それよりは、リスクを犯して1点を取りにいき、同点を目指して勝点を奪い、自力で決勝 トーナメントに進む戦いを目指してほしかった。後半失点するまでのパフォーマンスを見 ていたら、日本が攻めにいって、ポーランドから1点を奪える可能性は十分にあったと思 う。
反対論
客観的に考えるために、反対論を考えみよう。
リスクを犯して1点を取りにいき、2点目をポーランドに奪われた時にどう思うだろうか？ やはり悔しい。後に、守りに入ればよかったと後悔するか？確かにするかもしれない。
失点後のパフォーマンス。著しく攻めてを欠き、ボールが繋がらず、セカンドボールが奪 えない。
- 攻めの交代選手を入れて得点できる可能性、その時の失点する可能性
- 守りに入って、カードを貰わずに失点しない可能性
- セネガルが得点するであろう可能性
これらの可能性をすべて鑑みて出した結論が、西野監督のチョイスだったのだろう。 そういった意味では、結果論でいうと、正しい決断だという意見も一定の理解はできる。
まとめ
でも、そもそも何故、選手はワールドカップに出場したいと思うのか？
ワールドカップには、世界最高レベルで、全世界が見守る中で、自分達の力を試すために 、試合自体を楽しむために出場したいのではないのか？セネガル戦で、守って勝つより、 自分たちのプレーをして、みんなでカバーしながら戦おうという選択をして、守りきった ではないか！！あの時の気持ちを出してほしい。
もう一度言う。日本代表が予選を突破できたことは本当に嬉しい。 でも、もし全く同じ状況に、将来もう一度直面したら、その時は、ぜひとも戦ってほしい。 チャレンジしてほしい。それが皆に勇気を与えると思う。感動を与えると思うんだ。
勝っても負けても、日本代表として、日本人でよかった、 日本人が誇らしいという思えるような戦いを期待する！！
がんばれー、日本！！
追記 (2018/6/30)
試合後1晩が経ち、メディアには様々な意見がとび交う。 自分もいろいろな意見を聞き、西野監督の試合後の記者会見の模様をみて、出てきた思いは、
- 世界の最前線でやっている人間こそ、肯定的な意見を表明している
本当に厳しい世界で戦っているからこそ、なにがあっても結果を求める姿勢が大事なの ではないか？ - 同じ日本人なのだから、仲間を守らなくてどうする？
試合中は、試合をみていても楽しくなかったし、やる気のないプレーに怒れたりもしたけ ど、その後冷静になってみると、西野監督や選手達も複雑な思いをもった決断だったんだ と改めて理解できた。そして、そういう中で、短い時間で判断し、結果をもぎ取った。
世界でも賛否両論があるが、ここは、日本のサポーターとして、日本人とて、日本代表を後 押しできるよう、決勝トーナメントに連れて行ってくれた監督の判断を支持したい。
本当に難しい戦いになると思うけど、もしベルギーに勝ったら、すべてが報われるような 気がする。がんばれ、日本！！
vol38. windows10でmDNSの問題を解決する
先日、windows10で名前解決の問題にぶち当たった。windows10からLAN接続されている機 器に対してpingが通らないのである。
結論からいうと、windows10に実装されているmDNSを無効にして、3rd party のmDNSをイ ンストール(bonjour)したら問題が解決した。
windows10に3rd partyのmDNSをインストールしても、window10で実装された標準mDNS が優先的に使用される、かつ、このmDNSがバグってる(予想)ので、うまくうごかなかった模様 。レジストリを修正して、標準mDNSを無効にしないといけない。
解決に丸１日以上かかったので、うっぷんばらしと、今後の備忘録代わりにブログに投稿 しておく。
問題の概要
ホスト名(hogehoge.local)でターゲットを指定すると、ホスト名が見つからないと怒られ る。IPアドレス指定は問題なしなことから名前解決の問題。 ホスト名指定でも、ping に-4オプションを加えとipv4指定すると動くが、-6とipv6指定すると動かない。 以下はそのログ。
C:\Program Files (x86)\Microsoft Visual Studio 14.0>ping hogehoge.local
ping 要求ではホスト hogehoge.local が見つかりませんでした。ホスト名を確認してもう一度実行してください。
C:\Program Files (x86)\Microsoft Visual Studio 14.0>ping 192.168.100.18
192.168.100.18 に ping を送信しています 32 バイトのデータ:
192.168.100.18 からの応答: バイト数 =32 時間 <1ms TTL=64
192.168.100.18 からの応答: バイト数 =32 時間 <1ms TTL=64
C:\Program Files (x86)\Microsoft Visual Studio 14.0>ping fe80::2fc:70ff:fe00:1
fe80::2fc:70ff:fe00:1 に ping を送信しています 32 バイトのデータ:
fe80::2fc:70ff:fe00:1 からの応答: 時間 <1ms
fe80::2fc:70ff:fe00:1 からの応答: 時間 <1ms
C:\Program Files (x86)\Microsoft Visual Studio 14.0>ping hogehoge.local -6
ping 要求ではホスト hogehoge.local が見つかりませんでした。ホスト名を確認してもう一度実行してください。
C:\Program Files (x86)\Microsoft Visual Studio 14.0>ping hogehoge.local -4
hogehoge.local [192.168.100.18]に ping を送信しています 32 バイトのデータ:
192.168.100.18 からの応答: バイト数 =32 時間 <1ms TTL=64
192.168.100.18 からの応答: バイト数 =32 時間 <1ms TTL=64
システム構成
システム構成は以下の通り
- PC A (Windows10)
- PC A (Linux Debian(Vmware on Windows10))
- PC B (Windows7)
- 機器A (Linux: hogehoge.local)
- avahi daemon を利用して、mDNS をサポート。機器名はhogehoge.local
システム内の機器はEthernet Switch を通じて接続。システム内のすべての機器はipv4, ipv6対応している。
詳細
以下詳細。
PC A(windows10)から機器A(hogehoge.local)へのpingで名前解決ができない
PC B(Windows7)でも問題なし
その他
- windows10にもbonjour install してみたけどNG.
問題解決方法
冒頭にも述べたように、結論から言うと、windows10のmDNSの機能を無効にし、他のmDNSクライアントを 用いることで問題が解決する。
- mDNSを無効にする
- 3rd party のmDNS client をインストールする
- bonjour pint services for windows https://support.apple.com/kb/DL999?viewlocale=en_US&locale=en_US
これで動くようになった！！
いろいろ情報を集めたけど、最終的な決めてとなったのは以下の投稿。感謝！！
http:// https://superuser.com/questions/1330027/how-to-enable-mdns-on-windows-10-build-17134
vol37. mDNSとは
Linux 上で、avahi を使って、名前解決をする仕組みを知りたかったので調べてみた。 UDPの上位レイヤーで動作するmDNSというプロトコルを使用している。
mDNS とは何か
- multicast DNSの略
- 通常のDNSは、DNS server に問い合わせ名前解決を行う。
- mDNSは、マルチキャスト転送で、ネットワーク内のデバイスに問い合わせる事により、
名前解決を行う- DNSサーバーがいらない。
- RFC6762で規定
名前解決の流れ
- client は、mDNS query メッセージをマルチキャストで投げる
- 対応する機器はmDNS response メッセージをマルチキャストで応答
- mDNSは、マルチキャストアドレス 224.0.0.251、UDP 5353ポートを使用
- IPv4, IPv6のIP address の問い合わせは、query のType field で指定
zeroconf との関係
- 名前解決は、zeroconf ３つの技術のうちの1要素
- ip address の割り当て
- 名前解決
- device の位置の特定
- avahi はzeroconf を実現するためのLinux上での実装。apple はbonjourという実装。
nsswitchとは
- Linux における名前解決の為のclient system(avahi はmDNSの為の、server systemの
位置づけ) - local file, mdns, dns 等複数ある名前解決手法のうち、どの手法を用いて、どの順序
で名前解決をするかを決める。 設定ファイル
/etc/nsswitch.conf hosts: files mdns4_minimal [NOTFOUND=return] dns mdns優先順位は、files(/etc/hosts), mdn4_minimal, dns, mdns の順序。
miinimal はホスト名に.localが含まれていないと名前解決を行わない
mdns4 はIPv4のみ
mdnsはIPv4, IPv6双方で名前解決を行う。ping hogehote.local とうつと、上記の設定では、まず/etc/hostsの中身を確認し、次に
mdns ipv4 プロトコルで、名前解決を試みる。失敗したら、dns server に問い合わせを行い、 最後に、mdns (v4, v6) で解決を試みるというながれ。
