今回は上位層に上がってHTTPです。まずはクライアントになってサーバーにリクエストを投げてみて、Wiresharkで観察する、の回。というのも別件投稿にてNode-REDのフローとして「サーバー」を「構築」途上であるためです。例のごとく、うさちゃんRabbit4000にNode-REDの対話相手になってもらいます。
※「うさちゃんと一緒」投稿順indexはこちら
別件の投稿は以下です。
ブロックを積みながら(68) Node-RED、HTTP in / out ノードその１
もともとNode-RED自体はHTTPに反応するサーバーとして動いておるのですが、特定URLにてHTTPでのリクエストに反応する「フロー」を作ってみてNode-REDのHTTP in / out ノードのお勉強をするのが上記の投稿の趣旨であります。その１では何も実体処理のない、GETでリクエストが来たらばほぼほぼ空の本体を「打ち返す」だけのフローを作ってあります。とりあえずブラウザからリクエストを投げたらばレスは返ってくる感じ。
しかしブラウザでは好き勝手なリクエストを書けるわけでもなさそうなので、うさちゃんにご登場願いました。
Rabbit4000上で走らせるプログラム
Dynamic C 10.72Eの以下のサンプルプログラムを利用させていただきました。
http_client.c
上記のソースのTCPCONFIG の#defineのところを以下のように書き換えてうさちゃんのアドレスとしています。
#define TCPCONFIG 1 #define _PRIMARY_STATIC_IP "192.168.2.59" #define _PRIMARY_NETMASK "255.255.255.0" #define MY_GATEWAY "192.168.2.1" #define MY_NAMESERVER "192.168.2.1"
これをビルドしてRabbit4000に書き込めば「テキストベースのHTTPクライアント」の出来上がりとな。
実機動作の観察
Node-REDのテスト用フローが仕掛けてあるURLにGETしてみます。URLは
http://192.168.2.121:1880/get_test
するとうさちゃんのSTDIOには以下のようなレスポンスが現れました。Bodyをみれば 中カッコ開いて閉じて。予定通りの「空」JSONオブジェクトであります。
一方、Node-RED側で受信したリクエストのうちヘッダ部分を覗いてみます。user-agentのところ
Digi-Rabbit-httpc/1.08
とな。いつもであればブラウザ様の名乗りが入っているここに、うさちゃんRabbitの名前が入っておりまするな。ちゃんと届いておるぞよと。
さて「本命の」WiresharkによるうさちゃんとNode-RED間の通信記録が以下に。
最初の３個のTCPのパケットは、うさちゃん側のSYNに始まりNode-RED側のACKに終わる３Wayハンドシェークですな。
その後薄緑のHTTPパケットがうさちゃんからのGETリクエスト。それに対するNode-RED側のACKにつづいて、HTTPのレスポンスが送られてます。
その後コネクションを切るためのFINパケットが行き来しています。これで接続切れた筈。
その後念押しのようにうさちゃん側からRSTが出ているけれどもこういうものなのかな～、後で調べてみます。
肝心のHTTP GETのパケットのダンプが以下に。GETしてます。
それに対するレスポンスが以下に。ちゃんとWiresharkはJSONオブジェクトが載っていると認識しているのね。
念のため、もう一例。GETにパラメータをつけた場合。
http://192.168.2.121:1880/get_test?abc=123
うさちゃん側のStdioでの観察は以下に。オウム返しのJSONオブジェクトが戻ってきてますな。
Wiresharkの通信のログ。
そしてHTTPリクエストパケットと。
HTTPのレスポンス・パケット
一応、HTTPでのやりとりの様子が観察できたと。疲れた割には内容がないな。