Arduinoイーサーネットシールドの接続処理

Arduinoのイーサネットシールド（Ethernet Shield）にて、リセット後１回目のclient.connect()がtimeoutする問題があると書いたのですが、調べてみると、タイムアウトの発生条件は、「コネクションを切断した直後にリセットを行って、同一宛先に再接続した場合でした」。以下、分かったことを示します。

2009/6/7追記：hamayanさんからいただいたコメントに基づき確認方法を見直しました。

調査用のスケッチ

以下に示す調査用のスケッチを作成して、PC上のWeb Serverにアクセスしてみます。EthernetライブラリをIDE-0016に変更しました。

#include <Ethernet.h>

byte mac[] = { xx, xx, xx, xx, xx, xx };
byte ip[] = { 192, 168, 0, 110 };
byte server[] = { 192, 168, 0, 10 };

Client client(server, 80);

void setup()
{
  Ethernet.begin(mac, ip);
  Serial.begin(115200);
 
  delay(1000);
}

void loop()
{
  getpage();
  for(;;)
   ; //無限ループ
}

void getpage()
{
  Serial.println("connecting...");
  Serial.print("client.status = ");
  Serial.println(client.status(),HEX);
 
  if (client.connect()) {
    Serial.println("connected");
    Serial.print("client.status = ");
    client.write("GET /index.html HTTP/1.0\r\n\r\n");
    Serial.println(client.status(),HEX);
  } else {
    Serial.println("connection failed");
    Serial.print("client.status = ");
    Serial.println(client.status(),HEX);
    Serial.println();
    return;
  }

  while(true)
  {
    if (client.available()) {
      char c = client.read();
//      Serial.print(c);
    }
 
    if (!client.connected()) {
      Serial.println("disconnecting.");
      Serial.print("client.status = ");
      Serial.println(client.status(),HEX);
      client.stop();
      Serial.println("client.stop");
      Serial.print("client.status = ");
      Serial.println(client.status(),HEX);
      Serial.println();
      return;
    }
  }
}

スケッチアップロードの一回目の起動は、以下のように正しく動作します。各statusの意味を、「w5100.h」から抜粋しました。

connecting...
client.status = 0　→ SOCK_CLOSED
connected
client.status = 17　→ SOCK_ESTABLISHED
disconnecting.
client.status = 1C　→ SOCK_CLOSE_WAIT
client.stop
client.status = 0

一回目の動作が終了直後にリセットをかけて再接続すると、以下のように接続に失敗（タイムアウト）します。

connecting...
client.status = 0
connection failed
client.status = 0

LEDの点滅を見ていると、サーバーにパケットを投げているように見えます。WireSharkを使用してPC側でパケットキャプチャーを行うと、以下のように、Ethernet ShieldはTCP-SYNを投げてコネクション接続の要求を行っているのですが、PC（サーバー）側が応答していないことが分かりました。

なぜこうなるのかですが；

Ethernet Shieldからのアクセスが終わった直後に、netstatコマンドを使用してネットワークの接続状態を調べると、以下のようにEthernet Shieldとの接続は「TIME_WAIT」状態になっています。

C:>netstat -n
アクティブな接続
  プロトコル  ローカル アドレス          外部アドレス        状態
  TCP    127.0.0.1:27015        127.0.0.1:49178        ESTABLISHED
  TCP    127.0.0.1:49178        127.0.0.1:27015        ESTABLISHED
  TCP    192.168.0.10:80        192.168.0.110:1025     TIME_WAIT

TIME_WAITの意味は以下です（RFC793より）：
　対向側のTCPがFIN-ACKを受信するまでの十分な時間を確保するための待ち時間。

Windows側がTIME_WAIT状態中にArduinoをリセットした場合、Ethernet Shieldは前回アクセスと同一のソース・ポートを使ってTCP-SYNを投げるため、Windowsが応答しないようです。TIME_WAIT状態が終了するまで待ってリセットを行うと接続ができます。

冒頭に示したスケッチでは、client.connect()は1回しか実行しませんが、タイムアウトした際に再度client.connect()を行う処理を追加すると、TIME_WAIT中であっても、Ethernet Sheildがソース・ポートを1026に変えてTCP-SYNを投げるため2回目のclient.connect()は成功します。即ち、client.connect()をリトライすると成功することになります。

従って、これまでEthernetライブラリのバグではと思っていた事象は、WindowsのTCPセッション管理との兼ね合いで発生していることになります。

Linuxだとどうなるか

Linuxの場合、TIME_WAIT期間中にリセットによる再接続を行ってもタイムアウトせずに接続できました。リセット後のTCP-SYNで一度TCP-RSTが入るのですが、ポート番号は1025のままでもLinuxは新規のコネクションを受け入れるようです。

シーケンス図でまとめると

パケットキャプチャーで分かった動作シーケンスをWindows/Linuxそれぞれまとめると、以下のようになります。Windows/Linux共、Web ServerをApache2.2にして動作条件を統一しました。

Windows/Linuxそれぞれの動作概要を以下に示します（数字は、図のまる付き数字に対応します）。

■Windows (Vista)

1. Src Port 1025で一回目の接続
2. 切断。Server側からTCP-FINを送信している
3. Client (Ethernet Shield)もTCP-FINを送信する
4. Windowsの接続状態がTIME_WAITになる
   → TCPの教科書だと、FINは双方向で送信すること、TIME_WAIT状態は先にFINを送信したActive close側の状態遷移であるため、不思議な状態遷移をしているように見えます
5. Windows側でTIME_WAIT状態になっているSrc Port 1025を使って再接続
6. Windowsが応答せずタイムアウト
7. Src Port番号を変えて再接続すると成功する

■Linux

1. Src Port 1025で一回目の接続
2. 切断。Server側からTCP-FINを送信している
3. Client (Ethernet Shield)もTCP-FINを送信する
4. Linuxの接続状態がTIME_WAITになる
   → 双方向でTCP-FINを送信しており、一般的な終了シーケンスになっている
5. Linux側でTIME_WAIT状態になっているSrc Port 1025を使って再接続
6. LinuxがSYN-ACKを返さない（ACKフラグのみを返す）
7. TCP-RST後の再接続でコネクションが確立する
   → clinet.connect()のタイムアウトは発生しない

WindowsとLinuxで使用したWebサーバーが異なりますが、TCP-FINシーケンスの差分はカーネルの実装によるものなのか、もしくはサーバーアプリのSocket操作によるものなのかは分かりませんでした。
当初、ServerアプリがAbyssの際は、Server（Windows）がTCP-SYNを送信しないように見えたのですが、ApacheではTCP-FINの送信がキャプチャーできるようになりました。一回目の接続・解放シーケンスは、Windows/Linux共同様になりました。

メールチェッカーでも同様に、一回目のチェック終了直後にリセットを行うとタイムアウトが発生します。当方が使用するメールサーバーも (niftyですが）Windows的な動作になっているのでしょうか。BBルーターのNATで同一ポートの再接続が蹴られるということはないと思うのですが。

ということで、client.connect()のタイムアウトに関しては、リトライで救うしかないということが分かりました。