SilentCのhttpサーバー

某所で、Interface誌付録基板へtelnetでの接続は可能だが、ブラウザでアクセスすると「サーバーが見つからない」云々のメッセージが出てしまい、えらい困ったと言う話になっています。
http://micon.arrow.jp/modules/newbb/viewtopic.php?topic_id=868&forum=1&viewmode=flat&order=ASC&start=30

今回は別にこの事を解決するとかではなく、httpサーバーにtelnetで接続した場合にどうなるのかを試してみました。
普通telnetクライアントはtelnetのサーバー（ポート番号23）に接続したりしますが、勿論別のポート番号にも接続可能で、ネットワークアプリケーションの簡易的な動作確認にも使用できます。

例えばWindowsのコマンドプロンプトで以下の様にタイプします。
telnet 192.168.1.100 80
するとhttpサーバーはコネクションを受け入れてくれて、それ以降のメソッド待ちとなります。試しに適当なhttpサーバーに接続してみてください。
telnetでは接続完了後、入出力待ち画面となっていますので、以下の様にタイプします。
GET /
※エコーバックされないので、こちらから送った文字は見えません。
これでindex.htmかindex.htmlまたはindex.shtmlなどが存在すればそのファイルの内容を、無ければエラー情報を送り返してくれるでしょう。相手はWindows版のApacheです。



では同じ事をSilentCのhttpサーバーに行ってみます。

”G”をタイプしたとたんいきなり切断されてしまいました。

telnetクライアントの様に人間がタイプしたデータを転送する場合、どうしても人間のタイプのスピードが遅いので、1文字、1文字パケットで送っているのが実情です。「GET /」までを一気に送る事は人間には無理でしょう。
以下にPacMonでキャプチャして、パケットの解析を行った出力を貼って置きます。なお、全部の情報を載せると長いので、TCPヘッダー、TCPデータのみ掲載しています。
※解析結果をそのまま掲載しているので、半角カナが使われています。正しく表示できない環境もあるかもしれません。

<< ﾊﾟｹｯﾄ 1 >>
--- TCPﾍｯﾀﾞ [1464] → [80] ------------------------------------------------
【発信元ﾎﾟｰﾄ番号】1464 
【発信先ﾎﾟｰﾄ番号】80 (WWW)
【ｼｰｹﾝｽ番号】2716876110 (0xA1F03D4E)
【応答番号】0 (0x00000000)
【ﾃﾞｰﾀｵﾌｾｯﾄ】28 (0x1C)
【ﾌﾗｸﾞ】【URG】0【ACK】0【PSH】0【RST】0【SYN】1【FIN】0
【ｳｨﾝﾄﾞｳ】16384 (0x4000) ﾊﾞｲﾄ
【ﾁｪｯｸｻﾑ】0xDA05 (OK)
【緊急ﾎﾟｲﾝﾀ】0
【ｵﾌﾟｼｮﾝ】
【ｵﾌﾟｼｮﾝ番号】2 (最大受信ｾｸﾞﾒﾝﾄ長 = 1460 (0x05B4) ﾊﾞｲﾄ)
【ｵﾌﾟｼｮﾝ番号】1 (ｵﾍﾟﾚｰｼｮﾝなし)
【ｵﾌﾟｼｮﾝ番号】1 (ｵﾍﾟﾚｰｼｮﾝなし)
【ｵﾌﾟｼｮﾝ番号】4 (SACK許可)

<< ﾊﾟｹｯﾄ 2 >>
--- TCPﾍｯﾀﾞ [80] → [1464] ------------------------------------------------
【発信元ﾎﾟｰﾄ番号】80 (WWW)
【発信先ﾎﾟｰﾄ番号】1464 
【ｼｰｹﾝｽ番号】559858079 (0x215EC19F)
【応答番号】2716876111 (0xA1F03D4F)
【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14)
【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】0【RST】0【SYN】1【FIN】0
【ｳｨﾝﾄﾞｳ】1454 (0x05AE) ﾊﾞｲﾄ
【ﾁｪｯｸｻﾑ】0x5E0C (OK)
【緊急ﾎﾟｲﾝﾀ】0
【ｵﾌﾟｼｮﾝ】なし

<< ﾊﾟｹｯﾄ 3 >>
--- TCPﾍｯﾀﾞ [1464] → [80] ------------------------------------------------
【発信元ﾎﾟｰﾄ番号】1464 
【発信先ﾎﾟｰﾄ番号】80 (WWW)
【ｼｰｹﾝｽ番号】2716876111 (0xA1F03D4F)
【応答番号】559858080 (0x215EC1A0)
【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14)
【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】0【RST】0【SYN】0【FIN】0
【ｳｨﾝﾄﾞｳ】16616 (0x40E8) ﾊﾞｲﾄ
【ﾁｪｯｸｻﾑ】0x22D3 (OK)
【緊急ﾎﾟｲﾝﾀ】0
【ｵﾌﾟｼｮﾝ】なし

<< ﾊﾟｹｯﾄ 4 >>
--- TCPﾍｯﾀﾞ [1464] → [80] ------------------------------------------------
【発信元ﾎﾟｰﾄ番号】1464 
【発信先ﾎﾟｰﾄ番号】80 (WWW)
【ｼｰｹﾝｽ番号】2716876111 (0xA1F03D4F)
【応答番号】559858080 (0x215EC1A0)
【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14)
【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】1【RST】0【SYN】0【FIN】0
【ｳｨﾝﾄﾞｳ】16616 (0x40E8) ﾊﾞｲﾄ
【ﾁｪｯｸｻﾑ】0xDBC9 (OK)
【緊急ﾎﾟｲﾝﾀ】0
【ｵﾌﾟｼｮﾝ】なし

---【ﾃﾞｰﾀ】1 (0x0001) ﾊﾞｲﾄ ----------------------------------- SJIS -------
0000  47                                                 G

<< ﾊﾟｹｯﾄ 5 >>
--- TCPﾍｯﾀﾞ [80] → [1464] ------------------------------------------------
【発信元ﾎﾟｰﾄ番号】80 (WWW)
【発信先ﾎﾟｰﾄ番号】1464 
【ｼｰｹﾝｽ番号】559858080 (0x215EC1A0)
【応答番号】2716876112 (0xA1F03D50)
【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14)
【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】0【RST】0【SYN】0【FIN】0
【ｳｨﾝﾄﾞｳ】1454 (0x05AE) ﾊﾞｲﾄ
【ﾁｪｯｸｻﾑ】0x5E0C (OK)
【緊急ﾎﾟｲﾝﾀ】0
【ｵﾌﾟｼｮﾝ】なし

<< ﾊﾟｹｯﾄ 6 >>
--- TCPﾍｯﾀﾞ [80] → [1464] ------------------------------------------------
【発信元ﾎﾟｰﾄ番号】80 (WWW)
【発信先ﾎﾟｰﾄ番号】1464 
【ｼｰｹﾝｽ番号】559858080 (0x215EC1A0)
【応答番号】2716876112 (0xA1F03D50)
【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14)
【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】0【RST】0【SYN】0【FIN】1
【ｳｨﾝﾄﾞｳ】1454 (0x05AE) ﾊﾞｲﾄ
【ﾁｪｯｸｻﾑ】0x5E0B (OK)
【緊急ﾎﾟｲﾝﾀ】0
【ｵﾌﾟｼｮﾝ】なし

<< ﾊﾟｹｯﾄ 7 >>
--- TCPﾍｯﾀﾞ [1464] → [80] ------------------------------------------------
【発信元ﾎﾟｰﾄ番号】1464 
【発信先ﾎﾟｰﾄ番号】80 (WWW)
【ｼｰｹﾝｽ番号】2716876112 (0xA1F03D50)
【応答番号】559858081 (0x215EC1A1)
【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14)
【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】0【RST】0【SYN】0【FIN】0
【ｳｨﾝﾄﾞｳ】16616 (0x40E8) ﾊﾞｲﾄ
【ﾁｪｯｸｻﾑ】0x22D1 (OK)
【緊急ﾎﾟｲﾝﾀ】0
【ｵﾌﾟｼｮﾝ】なし

<< ﾊﾟｹｯﾄ 8 >>
--- TCPﾍｯﾀﾞ [1464] → [80] ------------------------------------------------
【発信元ﾎﾟｰﾄ番号】1464 
【発信先ﾎﾟｰﾄ番号】80 (WWW)
【ｼｰｹﾝｽ番号】2716876112 (0xA1F03D50)
【応答番号】559858081 (0x215EC1A1)
【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14)
【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】0【RST】0【SYN】0【FIN】1
【ｳｨﾝﾄﾞｳ】16616 (0x40E8) ﾊﾞｲﾄ
【ﾁｪｯｸｻﾑ】0x22D0 (OK)
【緊急ﾎﾟｲﾝﾀ】0
【ｵﾌﾟｼｮﾝ】なし

<< ﾊﾟｹｯﾄ 9 >>
--- TCPﾍｯﾀﾞ [80] → [1464] ------------------------------------------------
【発信元ﾎﾟｰﾄ番号】80 (WWW)
【発信先ﾎﾟｰﾄ番号】1464 
【ｼｰｹﾝｽ番号】559858081 (0x215EC1A1)
【応答番号】2716876113 (0xA1F03D51)
【ﾃﾞｰﾀｵﾌｾｯﾄ】20 (0x14)
【ﾌﾗｸﾞ】【URG】0【ACK】1【PSH】0【RST】0【SYN】0【FIN】0
【ｳｨﾝﾄﾞｳ】1454 (0x05AE) ﾊﾞｲﾄ
【ﾁｪｯｸｻﾑ】0x5E0A (OK)
【緊急ﾎﾟｲﾝﾀ】0
【ｵﾌﾟｼｮﾝ】なし

別にだからどうと言った話ではなく、「人によって実装が異なるのは面白いなぁ！」と言う話でした。

※それとは別に、SilentCはコネクション時にオプションを返さない仕様みたいないので、コネクション時に相手MSSを取得する様に作られている方は、注意が必要かもしれません。

コメント 9

HTTPのデータの送られ方って、いろいろありますよね。
だから悩むことも多いというか。
Webブラウザも、ネスケとかは確か全部PUSHが付いてきたし
IEは最後にPUSHが付くとか、実装によって全然ちがうので
結局「この環境で動作確認しました」でしか出せないことも。
個人的には「最後のデータにPUSHをつける」に統一してくれ
ないかなぁと思ってます。
まぁユーザーエージェントで見分ければいいんだろうけど。
さすがにRAM1kBのマイコンとかじゃぁダメっすな。
by ＪＵＮ (2008-09-14 22:28) 

あれ？かぶった。１個消してくらはい。
by ＪＵＮ猫 (2008-09-14 22:30) 

> 結局「この環境で動作確認しました」でしか出せないことも

激しく同意。
MAC OSの旧いバージョン、確か８くらいだっけなぁ、3way hand shakeの最後のACK応答にPSHフラグ付けてデータを載せて来た事が有って、決して間違いでは無いのだけれど、思っても見ない事でビックリしました。

だからネットワーク物の開発依頼を受けたりした時は、必ず実機での対抗試験をやらしてくれ！と。
結構この時出るんですよね、色々と。
by hamayan (2008-09-15 00:32) 

ふむふむ。キャプチャしまくったりとかで。
で結局、実機合わせみたいになっちゃうんですよね。
パソコンが古くなってきて、新しいのに変えたら動かない
とかなってトラブるっていう。
by ＪＵＮ猫 (2008-09-15 17:48) 

Ｎａｖａｊｏには２年前からお世話になっております。
初期のＮａｖａｊｏで一つ嵌っています。
ＵＤＰの送信でわからない現象が起きています。
送信データの中にたまに１バイト余分なコードが挿入されて送信されます。
その時は当然本来のデータ最後の１バイトが欠けています。
挿入場所はランダムでコードは必ず０ｘ１２（１２ｈ）です。
結果的にはチェックサムエラーとなりますのでチェックサム計算後に挿入されていると思われます。
送信バイト数は３４０バイトぐらいで１００ｍＳ毎に同じデータを送信することで確認しました。
エラー確認はWiresharkプロトコルアナライザーです。
送信側はＨ８－３０６９（akiとほぼ同じ）受信側はWindowsXPです。


by ILoveNavajo (2008-09-30 21:52) 

> 初期のＮａｖａｊｏ

初期のNavajoってもしかしてこれに搭載していた物でしょうか？。
http://akizukidenshi.com/catalog/items2.php?q=%22K-00211%22&s=popularity&p=1&r=1&page=

確かにこのバージョンには問題が有った様な記がしますが、ちょっと今は判らないです。

by hamayan (2008-10-01 00:16) 

hamayanさん、ここに書込む内容か迷ったのですがお答えありがとうございます。まずければ場所変えします。
初期などといい加減な言い方ですみません。　navajo_3068f_104.zip　です。
使い方に問題があるのかどうか？
今までＴＣＰだけでしたが今回ブロードキャストの問合せに自機が該当する場合に応答するためにＵＤＰサーバーを追加しました。
これは相手方の起動時だけ問合せがあるため、”定期的にプロセスをKILLされたか判断”の時を利用して違う機器にデータを送信するというもです。
うまく動作するのですが例の現象が発生します。０ｘ１２のコードは？
ＵＤＰ部はsystem.cfgでCRE_TSKし起動後act_tskに変更してあります。
by ILoveNavajo (2008-10-01 21:03) 

> 送信データの中にたまに１バイト余分なコードが挿入されて送信されます。
> その時は当然本来のデータ最後の１バイトが欠けています。
> 挿入場所はランダムでコードは必ず０ｘ１２（１２ｈ）です。

考えられる事は、メモリ/メモリ間の転送で謎の挿入が起きていると思われる点で、しかし単純なソフトウエアのバグなら必ずこの状態が発生しますので、もっと面倒な理由が有るのかもしれません。

Navajo内部でUDPの送信中に発生するメモリ/メモリ転送はUDPチェックサムの前に行われる固定長メモリプールへの転送が有ります。
しかしこの時に発生しているなら、間違ったデータを含んだチェックサム計算が行われるので、相手側ではUDPのチェックサムエラーは発生しない事になります。

それ以降細かいメモリへの書き込み等は発生しますが、一番問題になりそうなのが、RAMからRTL8019ASへの転送でしょう。
ここで発生するとしたら、余計なデータの挿入と、一番最後の正常なデータの抜けが発生する可能性が有ります。

さて、秋月の3069ネットワークボードは、昔から色々問題が指摘されて来た訳ですが、大きい物を上げると、
１．RTL8019ASにクリスタルではなくセラロックが付いていた。
これはもう大きなパケットが軒並みロストする現象に見舞われます。EthernetフレームのCRCでエラーになるので、相手側はパケットが送られて来た事すら判らないのですが、今回の事には関係無さそうです。

２．DRAMのタイミングがギリギリ
DRAMの設定をする時にタイミング計算をしてみたのですが、20MHzで何処だか詳しい所は忘れましたがギリギリ（あくまでも配線遅延等は入れていない）でした。もしCPUクロックに25MHzを使用したら、完全に規格を満足しないでしょう。

３．IOCHRDYを使用していない
つまりWAIT要求ですね。これがH8のWAIT入力端子に接続されていません。
負荷が掛かっている状態、つまりブロードキャストが沢山飛んでいたり、自分宛のパケットが沢山届いている状態の時、頻繁にIOCHRDYがアサートされる事は確認しています。

取り敢えず今出来る事は、WAITを最大にしてみて下さい。

by hamayan (2008-10-02 12:32) 

hamayanさん、アドバイスありがとうございます。
ＳＨ３のＬＩＮＵＸでも同じような事をしてるのですが問題なかったので嵌っていました。
色々調べて見るとＬＩＮＵＸでもＮＥ２０００互換チップには色々小細工しているみたいですね！チップにより色々#deineしてますね。
ところでアドバイスの通りチップエリアのＷＡＩＴを２から３にすると頻度がかなり少なくなる事がわかりました。ＩＯＣＨＲＤＹも繋ぎたいところですが同時進行のＴＣＰはＯＫですしＵＤＰは同じデータを何度も送っているのでチェックサムエラーは捨てられても良しと言う事でヤメにしました。２系統のきついＲＳ－２３２Ｃ通信をどじらせたくないので！
傾向が分かりましたので、ありがとうございます。
ここで又良いものを見つけました！一人のためとうたってますが私も待っていたものでした。<nava_v14_tcpip.zip>です。まだいじくりまわしてませんが、ただ単純に<include>と<tcpip>を入れ替えたらエラーの嵐に会いました。出来れば低レベルな２人目？のために<navajo_3068f_104.zip>みたなフルのnavajoを置いてもらえると助かります。（＾＾；

by ILoveNavajo (2008-10-07 22:43)