RtmpClientの使い方その3.1 うまく動かないのでHandshakeについて調べてみた。

先の記事での動作を実際にliverepeaterに適応してみたら、動画のデータへの対応がうまくいかず、動作不良がおこる模様でした。

やっぱりHandshakeがおかしいみたいです。(というかrtmpeの接続と認識されるような構成になってるっぽい。)

そこでorg.red5.server.net.rtmpをDEBUGに変更してサーバー、クライアントを動作させHandShakeがどうなっているか確認してみました。
以下サーバー側のログから動作概要抜粋

■RtmpClientでつないだ場合

• RTMPMinaConnection - RTMPMinaConnection created
• RTMPConnManager - Connection created, id: 5
• RTMPHandshake - Handshake ctor
•  - Player encryption byte: 3
•  - Detecting flash player version 9,0,124,2
•  - Player version byte: 9
•  - Scheme: 0 client digest offset: 310
•  - Temp: バイトデータ
•  - Scheme: 1 client digest offset:1168
•  - Temp: バイトデータ
•  - Unable to validate client
•  - Invalid RTMP connection data detected.
•  - Using new style handshake
•  - Public key: 数字の羅列
•  - Public key as bytes - length [128]: バイトデータ

となります。

■RtmpClientをEncrypt有効にしてつないだ場合

• RTMPMinaConnection - RTMPMinaConnection created
• RTMPConnManager - Connection created, id: 5
• RTMPHandshake - Handshake ctor
•  - Player encryption byte: 6
•  - Detecting flash player version 9,0,124,2
•  - Player version byte: 9
•  - Scheme: 0 client digest offset: 497
•  - Temp: バイトデータ
•  - Valid RTMP client detected.
•  - Using new style handshake
•  - Public key: 数字の羅列
•  - Public key as bytes - length [129]: バイトデータ
•  - Truncated public key length to 128
•  - Incoming public key [128]: バイトデータ
•  - Outgoing public key [128]: バイトデータ
•  - Shared secret [128]: バイトデータ

こちらの場合はScheme0の段階で有効なクライアントと判定されてそのあとで送られてくるPublish Keyのバイトが129バイトに、そのあとIncomming public key、Outgoing public key、Shared secretの３つのキーをやりとりしています。

■本物のFlashPlayerでつないだ場合

• RTMPMinaConnection - RTMPMinaConnection created
• RTMPConnManager - Connection created, id: 5
• RTMPHandshake - Handshake ctor
•  - Player encryption byte: 3
•  - Detecting flash player version 128,0,7,2
•  - Player version byte: 128
•  - Scheme: 0 client digest offset: 526
•  - Temp: バイトデータ
•  - Scheme: 1 client digect offset: 940
•  - Temp: バイトデータ
•  - Selected scheme: 1
•  - Valid RTMP client detected.
•  - Using new style handshake
•  - Public key: 数字の羅列
•  - Public key as bytes - length [129]: バイトデータ
•  - Truncated public key length to 128

Playerのencryption byte:3になっているので、暗号化は行わないと宣言されています。

versionは固有の値だからおいといて。

Scheme 1の認証で有効なクライアントと判定されています。

Publicキーでは先頭に0x00が追加された129バイトのデータになっています。

そして、Cryptを有効にしたときの接続で見られた３つのキーのやりとりはありません。

というわけでCryptを有効にした場合ともともとの状態との中間になる方法で接続しようとしないとだめっぽいです。

■RtmpClientのデフォルトで接続するが、Scheme1の認証を強制的に受け入れる場合

• RTMPMinaConnection - RTMPMinaConnection created
• RTMPConnManager - Connection created, id: 5
• RTMPHandshake - Handshake ctor
•  - Player encryption byte: 3
•  - Detecting flash player version 9,0,124,2
•  - Player version byte: 9
•  - Scheme: 0 client digest offset: 674
•  - Temp: バイトデータ
•  - Selected scheme: 1
•  - Valid RTMP client detected.
•  - Using new style handshake
•  - Public key: 数字の羅列
•  - Public key as bytes - length [128]: バイトデータ
•  - Truncated public key length to 128

最後のPublic keyのバイトの長さが128バイト・・・あたまに0x00をいれないとだめというわけか？

ちなみにこのバージョンでは、サーバー側のプログラムを書き換え認証を強制受け入れとしてあります。

■今後の攻め方

• Cryptを有効にした場合をベースにいらないものを省くという方向でせめればいいと思われる。
• Scheme1で認証されるようにすること。
• Public keyのバイト数は129バイトになるように調整する。

とすれば、うまくいきそうな気がします。

なお、暗号化のHandshakeをクライアントで実行させかつ、Player encryption byteを3(暗号化しないと宣言)として動作させ、Flash Media Serverに接続させようとしたところつながった瞬間に切断されました。

無効なクライアントと認証されてるっぽいです。Scheme0で有効性を検証してるのがだめなんだろうねぇ・・・