Problem in connecting to a server waiting for a TCP request using ESP8266

I'm using ESP8266 for connecting to a appspot-preview.l.google.com server which listens for TCP request and answers back a number (it's for training purposes).

Problem is from my location, I can't connect to the website properly even from my browser. Firefox and Chrome take about ~40 seconds to render the page (which has a list of people who issued TCP request to that server).

Now, my specific problem lies in ("AT+CIPSTART=\"TCP\",\"%s\",80\r\n", IPaddress). ESP8266 quickly replies a "ERROR" after trying to establish a TCP connection to that IP.

1- I want ESP8266 to wait and try connecting to the website in the same way my browser does (after ~40 seconds). How can I do this?

2- There is a "TCP keep alive" switch in the AT+CIPSTART command from official "ESP8266 AT Instruction Set": Is this option relevant to my problem? Why is there a comma inside the brackets?

Thanks

• The comma separates the parameters, as the TCP keep alive is an optional parameter, that last comma is optional as well. It is not needed if the last parameter is not used. That is why it is inside the brackets. – Bence Kaulics Dec 10 '17 at 20:37
• @BenceKaulics So the bracket is not needed as well? Is this a valid use case: AT+CIPSTART="TCP","1.2.3.4",80,60 ? Does this force ESP8266 to wait 60 seconds and listen for a response, then after that issue ERROR if any? – Zeta.Investigator Dec 10 '17 at 20:45
• why have you not tried setting the option before you posted the question? – jsotola Dec 10 '17 at 20:45
• Rather than struggling with appspot-preview.l.google.com why don't you run a TCP server on your PC? I've used Hercules and found it really useful for testing things like the ESP8266. – Steve G Dec 10 '17 at 21:21
• Keepalive is not the answer, what you want is to change the connection (and perhaps session) timeout, and for that you need documentation and/or source for the ESP8266 TCP/IP stack. But if it's taking 40 seconds from other devices, that server or connection provider are probably not the right choices. – Chris Stratton Dec 10 '17 at 21:23