dealing with improper disconnection of yclient.connected

Dear Forum,
I am connecting to an Arduino Yun via a sockit connection. The arduino is connected to the PC via wifi. It basically works but I have had some problems with the computer putting the wireless adaptor to sleep which means I loose the sockit connection. Once this happens, it is not possible to recover the sketch and reconnect without restarting the sketch, either by pressing the reset button or rebooting the whole arduino. This is troublesome because the whole thing is in an enclosure. Of course, I can stop the computer putting the wifi to sleep but finding a way around this problem would make my sketch code more robust.

The basic structure of the code within the main loop is shown below. There is more to it than this but it illustrates the principle:

    Serial.println("Client Connected:");
    String string = "";
    String Msg = "";
    char *myChar;
    char charBuf[50];
    int Outcome;
    while(yclient.connected()){        // this loop will continue while a connection is active
           // in this bit, the sketch responds to inputs via the sockit connection when they arrive
       // here there should be no connection so I can blink an LED to show the connection status

Can anyone suggest how I can either cause the sketch to reboot without having to reset the sketch manually by doubling clicking the button near the RJ45 ethernet connection or preferably have a way in which the sketch can handle a situation where the connection drops out without ending the sockit connection in a nice way?


Rather than reboot the sketch, why not make so that the client can reconnect?



// here there should be no connection so I can blink an LED to show the connection status

In this section, call yclient.stop() to clean up the old connection, and then make the connection again. Do this by calling server.accept() if it's an incoming connection, or client.connect() is it's outbound.

You may need to have a flag to indicate whether a client connection is active. That way, if you make it into the connected section and the flag is unconnected, you know you just got a new connection and can re-initialize things if needed. Similarly, if you get to the not connected section, and the flag shows connected, you can call the client.stop() and do any other cleanup.

An example of handling repeating incoming connections IS HERE
An example of handling repeating outgoing connections IS HERE

Thank you shapeshifter.
Well the yclient.stop() does not really help. The problem is that the Arduino is stuck in the while loop and without any way of getting out, then it stays stuck.

What I have done which sort of works but which is rather nasty is to run another instance of yserver.accept() so that I can listen for new calls and if they connect, then I can break out of the loop. Therefore, even if my original connection is stuck, a new attempt can break the loop.

while(yclient.connected()){        // this loop will continue whilts a connection is active
      YunClient yclient2 = yserver.accept();  // it is possible to accept another input. If this happens disconnect
      if(yclient2.connected()){      // then we have another attempt to connect
        yclient.stop();  // stop the original connection
        Msg = "Second input received\n";
        yclient2.write((uint8_t*)&Msg[0], Msg.length());
        string = "";
        yclient2.stop();  // stop the second attempt

So this is fairly ugly because it drops all connections. I can at least re-open the socket from my PC.
If anyone else can think of a nicer way of doing this .....


Perhaps you should re-think your program structure. You’re better off if loop() checks if anything needs to be done on this pass, does it, and exits. Having the while(connected) loop inside of loop() is not such a good idea.

Take a look at my incoming connection example again: on each oasis of the loop, it checks of the client is connected: if so, it reads any pending data (but doesn’t wait for more data) and then sends a string and gets out. It doesn’t stay any longer than necessary.

That may be part of why you are having trouble, but it also seems that connected() is reporting a connection exists when it doesn’t exist any more?

You could also try to restructure the whole concept where the Linux side does all of the network communications, handling what it can pandora then passing the payload tongue sketch as needed. The Linux side is more powerful and robust, especially when it comes to networking.