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.

I've been having a similar problem, but not related to the speed of requests.

I have mine set up to pull a web page every 60 sec, and I have an LED indicate when there was a connection failure. Maybe I should log the failures so I know for sure how often they happen, but it seems to have a fair number of them throughout the day.

The server is of course up and responding, but I'm not sure what to look at in my Arduino to see what the problem is.

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.)

I have not played with the ethernet lib yet. Does the status change to disconnected right away or does it takes a few moments depending on the response of the remote machine?Does the Stopping.... message always print exactly once?

In vb6, I have found that it takes time for the connection to fully stop after I issue the disconnect request. I have not yet played with my ethernet shield. Ideally you would say while ( !client.disconnected ) but I have not verified the types of 'states' that the library provides.

example: 'not connected' is not the same as 'disconnected' because we could be in transition of states.

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.

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.

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?

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.