Ethernet shield client.stop()

Projects Programming
1

My Arduino (MEGA 2560) running as server, waiting for clients:

EthernetClient client = server.accept();
if (client) {
    while (!client.available());
    while (client.available())
      client.read();
    if (client.connected()) {
      unsigned long start = millis();
      client.write('a');
      Serial.print("before stop: '" + String(millis() - start) + "'\n");
      client.stop();
      Serial.print("after stop: '" + String(millis() - start) + "'\n");
    }
}

When connecting via telnet, client.stop() takes 1ms
When connecting via a Go program, client.stop() either takes whatever Timeout is, or as long till the Go program closes the connection.
In all three cases, client.connected() will return false afterwards.

Go (Client) code:

connection, err := net.Dial("tcp", ipPort)
if err != nil {
	panic(err)
}
///send some data
connection.Write([]byte{16,
	0, 0, 0, 0, 0, 0, 0, 0,
	1,
	39,
	255, 31,
	255, 31,
	116})
buffer := make([]byte, 1024)
mLen, err := connection.Read(buffer)
if err != nil {
	fmt.Println("Error reading:", err.Error())
}
fmt.Println("Received: ", string(buffer[:mLen]))
time.Sleep(time.Second * 2)
connection.Close()

But I don't like that a client can cause the stop function to block for give timeout, as I can't use multithreading on the Arduino. Using a 1ms timeout isn't a good solution either.
I did a lot network programming some time ago and I can't remember that "close" needs the other side to agree.

2

Okay, well ... it's like it is: Ethernet/src/EthernetClient.cpp at b16c38a5bd0e25143da8d0e9cdeba5b90db62d0a · arduino-libraries/Ethernet · GitHub

3

The process of gracefully closing a TCP connection is defined in RFC 793. if I remember well, the standard procedure for closing a TCP connection involves the initiating side sending a FIN message to signal the end of data transmission, which the receiving side acknowledges with an ACK, followed by the receiver sending its own FIN message, which the initiator acknowledges with a final ACK, ensuring both sides agree to close the connection in an orderly manner.

4

thank you for your reply.
Understood, but the lack of an function / parameter to force the closing is still annoying. As the server as only 4 active clients at a time, the clients send the request, the server saves the request and reply okay, followed by closing the connection to make room for the next client. If a client can block the connection because not reacting correct on the graceful close, it's an issue. But anyway, I will set the timeout to 0 before calling stop. Not the prettiest solution, but it's doing the job.

5

You could always modify the library and add a non-blocking version of the function that would return immediately. You'd then add another function to poll its progress and let you know when disconnect has succeeded or timed out. You'd call this polling function from your main code until one of the two possibilities occurs. You might even enter a PR to have your new functions added to the official library.