Discussion :

[electroremy]

Bonjour,

Lorsqu'on utilise le shield Ethernet W5500, j'ai déjà remarqué que la fonction client.stop() est très lente.

En cause : un timeout qui va jusque au bout, car Ethernet.socketStatus(sockindex) == SnSR::CLOSED ne se produit pas ou alors trop tard

J'ai donc supprimé cette partie en la mettant en commentaire, voyez le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
void RLucasS_EthernetClient::stop() {
	if (sockindex >= MAX_SOCK_NUM) return;
	// attempt to close the connection gracefully (send a FIN to other side)
	Ethernet.socketDisconnect(sockindex);
 
	// Waiting for the connection to close is useless and VERY SLOW !
	/*
	// wait up to a second for the connection to close
	unsigned long start = millis();
	do {
		if (Ethernet.socketStatus(sockindex) == SnSR::CLOSED) {
			sockindex = MAX_SOCK_NUM;
			return; // exit the loop
		}
		delay(1); 
	} while (millis() - start < _timeout); 
	*/
 
	delay(1); 
 
	// if it hasn't closed, close it forcefully
	Ethernet.socketClose(sockindex);
	sockindex = MAX_SOCK_NUM;
}

Ca fonctionne très bien et de façon ultra rapide !

J'ai plusieurs cartes Arduino qui communiquent entre elles avec ce shield Ethernet, et aussi à des clients de type ordinateur et à des server web.

Aucun bug avec ma version de client.stop().

Des logiciels faits en VB.NET qui émulent un client ou un server sur mon PC ne bronchent pas non plus (aucune exception, alors que les HTTP listener de VB.NET que j'utilise sont très pointilleux)

Même le sévère W3C validator ne trouve rien à redire face à ce comportement de mon server Arduino.

D'ou ma question :

- à quoi ça sert d'attendre que Ethernet.socketStatus() soit égal à CLOSED ?

- à quoi sert Ethernet.socketDisconnect() ?

Je précise que dans les headers HTTP que j'envoie, j'indique bien "Connection: close"

4 hypothèses :
- le socket "de l'autre coté" ne tiens pas compte de la commande "FIN"
- la fermeture propre du socket est très lente
- la bibliothèque Ethernet est mal écrite vis à vis des caractéristiques de la puce W5500
- la puce W5500 a un défaut interne et c'est elle qui ne ferme pas ses sockets

A bientôt

[electroremy]

Bonjour,

j'ai trouvé l'auteur de la bibliothèque sur Github et j'ai posé la questions sous forme d'issue

https://github.com/PaulStoffregen/Ethernet/issues/53

A bientôt

[Beginner.]

Salut,

Espérons qu'il va répondre...

[electroremy]

Bonjour,

Wireshark semble dire que les instructions "FIN" sont bien envoyées et reçues des deux côtés



Ce relevé a été fait avec ma version de la fonction socket.close(), donc le problème vient soit de la puce W5500 soit de la bibliothèque

A bientôt