Hello!

I'm new to Arduino, and want to do the following.
I want simple board with a button, when i press the button i want it to do a http-request, and display contents on the mac using serial connection.

This shouldn't be too hard..

I thought I'd best approach this problem one sub-problem at the time.
My first step was to create the http-request and serial display.

I found the code below, and understand what it does..
I inserted the delay(500); pieces myself.

Problem with code below is that sometimes it can't connect to the server, I don't understand why cause it really is up. When I increase the amount of delay it seems to go better. But I want to be able to push the button (in the final) project multpile times per second....

This should be possible, shouldn't is? Could the problem be serverside? If anyone can help, it would help me a lot.

Thanks!

Code:

#include <Ethernet.h>

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
byte ip[] = { 10,0,0,7 };
byte server[] = {10,0,0,1};


Client client(server, 80);

enum CLIENT_STATE
{
	STEP1, STEP2, STEP3, STEP4
};

static CLIENT_STATE client_state;

void setup()
{
  Ethernet.begin(mac, ip);
  Serial.begin(9600);

  delay(1000);
}

void loop()
{

  if (client_state==STEP1)
  {
    Serial.println("connecting...");

  if (client.connect()) {
    Serial.println("connected");

    client.println("GET /index.html HTTP/1.0");
    client.println("Host: localhost");
    client.println("User-Agent: AVR ethernet");
    client.println("Accept: text/html");

    client.println();


    client_state=STEP2;
    delay(500);
  } else {
    Serial.println("connection failed");
    delay(500);
    client_state=STEP1;
  }
  }

    if (client_state==STEP2)
  {
  if (client.available()) {
    char c = client.read();
    Serial.print(c);
    client_state=STEP2;
  }
  else if (!client.connected())
  {    Serial.println();
    Serial.println("disconnecting.");
    client.stop();
    delay(500);
	client_state=STEP1;
    }

  }
}
 

I've rewritten the code. Now it is only the essence...
I do a request every second with the doRequest function... It works a couple of times, but then it suddenly can't connect anymore (i keep getting "Can't get a connection!").

After a while it suddenly can connect again, and i get results from te server again. Most of the time it works once or twice, and then the procees repeats... (can't get a connection, and after a while CAN get a connection.)

Does anyone has an idea where the problem could be?
Code:

#include <Ethernet.h>

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
byte ip[] = { 10, 0, 0, 12 };
byte server[] = {10,0,0,1 }; // local ip

Client client(server, 80);

void setup()
{
  Ethernet.begin(mac, ip);
  Serial.begin(9600);
}

void loop()
{
  doRequest();
  delay(1000);
}

void doRequest(){

  Serial.println("doRequest Function");
  while(!client.connect()) {
    Serial.println("Can't get a connection!");
  }
  Serial.println("(Finally) got a connection, so send get-request.....");
   client.println("GET /index.html HTTP/1.0");
   client.println();
  Serial.println("Reading incoming data");
  incoming();
  client.stop();
  Serial.println('socket stop');
}

void incoming(){
  while (client.available()) {
    char c = client.read();
    Serial.print(c);
  }

  if (!client.connected()) {
    Serial.println("Disconnected.");
  }
}
 

Mark,

Looks like you've found the solution. I was having the same exact issue. Putting in a delay is not reliable. Instead, looping until the connection ends works like a charm. Thanks!

Paul

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

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:

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:

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.

It looks like you guys fixed the problem!

I'm using code based on the example posted by NJPaul and the client.cpp modifications suggested by etracer, great work!

Oh and this patch is meant for the standard Ethernet library, it doesn't work with Ethernet2 yet.

Will this patch find it's way to the official distribution?

Did you remember to delete the Client.o file in the library directory? If not, the the library didn't recompile.

Quote:


I've only done a casual look at the Ethernet2 library, but from what I saw the Client::connect() code looked identical to the "official" library.

I'll be writing up this patch and submitting it to the developer's list. There are a couple of other bugs and enhancements that I'm still looking into.

1. The client can get into an unrecoverable state if the sketch opens connections and then fails to call client.stop() before issuing another client.connet(). After the fourth connect all sockets will be in use preventing any more connections. The insidious part is that there's no way to release the orphaned connections. Easily fixed by having the connect() return a fail result if there is already and active connection.

2. There are some situations where the client.stop() fails to disconnect and leaves an "ESTABLISHED" connection to the server. I'm still researching this.