Go Down

Topic: Problem with multpile (fast) client-requests (Eth) (Read 4 times) previous topic - next topic

macegr

This post deals with the same problem in a slightly different way: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1235991468/14#14

Looping until !connected() can still cause problems, because of the way the Ethernet library determines connection status.
Unique RGB LED Modules and Arduino shields: http://www.macetech.com/store

XNDR

I'm having similar problems... did you ever figure out how to fix this?

Here's some more information about this problem:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1238295170

NJPaul

In addition to the loop to check whether the connection has been closed, I noticed that a few well placed delay() statements are necessary. Otherwise, after 4 or 5 connections the ethernet board 'locks up'. More specifically, the tx LED on the ethernet board goes nuts but othewise all communications cease. Here is my code after I put in the delay statements. Works fine now. Disclaimer: I am very new to Arduino.

#include <Ethernet.h>

byte mac[] = {
 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
byte ip[] = {
 x, x, x, x };
byte server[] = {
 y, y, y, y };
Client client(server, 86);


int sen02=0;

void setup()
{
 Ethernet.begin(mac, ip);
 pinMode(2, INPUT);
 delay(1000);
}

void loop()
{

if(digitalRead(2)!=sen02){
sen02=digitalRead(2);
 client.connect();
 delay(1000);
 if(client.connected(){
   client.println("GET /HA/Event.php?Sen=2&Sta=1&Des=Text1 HTTP/1.0") ;
   delay(500);
   client.println();
   delay(500);
   while(client.connected()) {
     client.flush();
     client.stop();
     delay(1000);
     }
   }
 
}

}

etracer

Here's a fix (at least a work-around) to the multiple connect problem. The problem seems to be in how the TCP stack on the Wiznet chip is handling disconnects. It looks like it's failing to ACK the final FIN when the connection is closing. This leaves the socket in the SOCK_FIN_WAIT state from the client (Wiznet chip), and in the TIME_WAIT state on the server. Eventually these states timeout after about 30 seconds and the socket moves to a SOCK_CLOSED state.

So as you initiate each connection and subsequently close it (or it gets closed by the webserver), the one of the four available sockets for connections gets "stuck" waiting for the TCP connection to close (because of the FIN/ACK issue). After four connections in less than about 30 seconds, all of the sockets are in use (stuck waiting) and no more connections can be established. As each stock socket times out, then another connection can be made.

So the work-around is to change the Client connect() function to consider a socket in the SOCK_FIN_WAIT state available. This gets around the 30 second delay while the state times out. This solution is not ideal as it's not very nice to the server you connected to since it will end up with a bunch of TIME_WAIT connections that will eventually timeout. This could be bad if you make a lot of connections very quickly. It's what's happening now anyway, but you can only generate 4 at a time so it's not so bad on the server. The real fix is probably needed in the Wiznet TCP/IP stack on the chip - maybe there's an updated firmware??

Here's the revised connect() function in Client.cpp. Note that there are a couple of other enhancements to:
1. More intelligently choose the available socket instead of always picking the last one.
2. Bugfix for the _srcport overflowing and causing the connection to come from a privileged port.

Code: [Select]
uint8_t Client::connect() {

 uint8_t socketStatus;
 uint8_t i=0;

 _sock = 255;

 while ((i < MAX_SOCK_NUM) && (_sock == 255)) {
   socketStatus = getSn_SR(i);
   if ((socketStatus == SOCK_CLOSED) || (socketStatus == SOCK_FIN_WAIT)) {
     _sock = i;
   } else {
     i++;
   }
 }
 
 if (_sock == 255)
   return 0;
   
 _srcport++;

 if (_srcport > 64511)
   _srcport = 0;
   
 socket(_sock, Sn_MR_TCP, 1024 + _srcport, 0);
 
 if (!::connect(_sock, _ip, _port))
   return 0;
   
 while (status() != SOCK_ESTABLISHED) {
   if (status() == SOCK_CLOSED)
     return 0;
 }
 
 return 1;
}


Also, if we're going to consider the SOCK_FIN_WAIT state to be disconnected and eligible for new connections, the we probably need to update the connected() function as well:

Code: [Select]
uint8_t Client::connected() {
 uint8_t s = status();
 return !(s == SOCK_LISTEN || s == SOCK_CLOSED || (s == SOCK_CLOSE_WAIT && !available()) || (s == SOCK_FIN_WAIT));
}


With these changes I was able to make unlimited client connections to a webserver.

macegr

That's exactly what I was seeing, my fix was just to actually wait until the socket was closed. It still let me get a few requests per second.

Great work! The Wiznet chip is amazing, it's bad to see so much of its power go to waste. Wiznet supplies code for DHCP, which might be interesting to get running sometime.
Unique RGB LED Modules and Arduino shields: http://www.macetech.com/store

Go Up