Bonjour,
je souhaiterais récupérer l'adresse IP du client qui se connecte sur le serveur arduino.
Existe il une fonction dans la bibliothèque Ethernet ou UIPEthernet?
Merci d'avance ![]()
Bonjour,
je souhaiterais récupérer l'adresse IP du client qui se connecte sur le serveur arduino.
Existe il une fonction dans la bibliothèque Ethernet ou UIPEthernet?
Merci d'avance ![]()
bonjour,
je ne sais pas s'il y a une équivalence à $adresse_ip = $_SERVER['REMOTE_ADDR']; en C++
Pour connaître les fonctions disponibles dans une bibliothèque, tu examines le fichier .h livré avec.
Pour trouver ce fichier, tu peux utiliser la fonction de recherche de ton ordi.
Les librairies d'origine Ethernet/Ethernet 2 ne disposent pas de cette fonction.
Mais c'est tres simple de l'ajouter en editant les fichiers EthernetClient.cpp et EthernetClient.h (quelques lignes de code a ajouter)
Je l'ai justement fait hier soir et ca marche sans problème.
Il y a une discussion en anglais qui en parle. En faisant une recherche on tombe facilement dessus.
Forhorse:
Les librairies d'origine Ethernet/Ethernet 2 ne disposent pas de cette fonction.
Mais c'est tres simple de l'ajouter en editant les fichiers EthernetClient.cpp et EthernetClient.h (quelques lignes de code a ajouter)
Je l'ai justement fait hier soir et ca marche sans problème.
Il y a une discussion en anglais qui en parle. En faisant une recherche on tombe facilement dessus.
si tu mettais ces lignes de codes, ca ne serait pas plus simple?
Je suis sur mon téléphone et elles sont sur mon pc a la maison.
Si le demandeur est pressé il demande a google et les trouveras sans doute facilement (j'ai moi même trouvé en 2mn hier soir)
Sinon je les mettrai ce soir oui, avec plaisir.
Bonjour, merci beaucoup pour vos réponse, je vais de suite essayer.
Je viens d'essayer, malheureusement, ça ne marche pas:
/home/quentin/Arduino/libraries/UIPEthernet/UIPClient.cpp:666:20: error: '_sock' was not declared in this scope
W5100.readSnDIPR(_sock, remoteIP);
Moi je n'ai pas la bibliothèque Ethernet car j'ai pas le shield officiel, j'ai UIPEthernet...
Tu dois avoir un équivalent de _sock dans cette librairie, il faut sans doute éplucher un peu les autres fichiers.
Je suis loin d'être bon en programmation et je vais peut être dire une connerie... mais il semblerait que _sock face référence au "socket" du chipset Ethernet utilisé par le client (le w5100 peut en avoir juste 4)
C'est une variable qui est utilisée dans pratiquement toutes les fonctions de la librairie (tu regarde par exemple comment est construit la fonction "read") donc en cherchant un peu tu trouveras comment s'appel cette variable dans ta librairie.
Le problème, c'est que la méthode read est complétement différente de celle d'EthernetClient.cpp:
Officiel:
int EthernetClient::read() {
uint8_t b;
if ( recv(_sock, &b, 1) > 0 )
{
// recv worked
return b;
}
else
{
// No data available
return -1;
}
}
UIPEthernet:
int
UIPClient::read()
{
#if ACTLOGLEVEL>=LOG_DEBUG_V3
LogObject.uart_send_strln(F("UIPClient::read() DEBUG_V3:Function started"));
#endif
uint8_t c;
if (read(&c,1) < 0)
return -1;
return c;
}
J'arrive pas à retrouver la variable qui est l'équivalent de _sock, on dirait que les 2 bibliothèque n'utilisent pas du tout la même logique...
J'ai pas cette librairie alors difficile de t'aider vraiment.
Mais si on peut pas retrouver l'equivalent dans les fonctions qui l'utilisent, il faut peut-être chercher l'equivalent à l'endroit où c'est créer.
Dans la librairie officielle ça semble être au début du fichier là où sont précisé les méthodes de la class.
EthernetClient::EthernetClient(uint8_t sock) : _sock(sock) {
}
quentin131:
on dirait que les 2 bibliothèque n'utilisent pas du tout la même logique...
Si c'est la même logique.
Dans le premier cas on utilise la fonction recv() pour lire un octet sur la socket. Selon le code de retour de recv(), on renvoie le résultat ou bien -1 pour signaler une erreur (et c'est plutôt pourri: et si la valeur lue est -1, comment savoir si il y erreur ou pas ?).
Va dans google et tape "man recv" pour comprendre la fonction recv, qui est une fonction de la bibliothèque standard du langage C.
Dans le second cas, la fonction utilisée est read() (à la place de recv).
read() est également une fonction de la bibliothèque standard du langage C. Mais ce read() standard attend 3 pramètres ! et ici il n'y en a que 2 (tape "man read" sur Google).
Donc ce read() là est surement propre à la bibliothèque UIPEthernet. Cherche la dans cette biblio.
A noter qu'ici aussi, on ne sais pas distinguer entre la réception de l'octet -1 et la détection d'une erreur...
J'ai cherché dans tous les fichiers de la bibliothèque est je n'ai pas trouvé... De plus, je ne comprend même pas comment la fonction read(de la classe UIPClient) fonctionne:
int
UIPClient::read()
{
#if ACTLOGLEVEL>=LOG_DEBUG_V3
LogObject.uart_send_strln(F("UIPClient::read() DEBUG_V3:Function started"));
#endif
uint8_t c;
if (read(&c,1) < 0)
return -1;
return c;
}
On dirait qu'il n'y a aucune communication avec le shield, la fonction lis dans une variable qui viens d'être définit (c). En plus, la fonction retourne un nombre(int) alors que je croyais que c'était un caractère, je n'y comprend rien, si quelqu'un peut m'aider à comprendre, ça m'aidera peut être à comprendre la suite...
Merci ![]()
la fonction int UIPClient::read() est une encapsulation de la fonction read(&c,1)
C'est cette dernière qui fait tout le boulot.
Dans les arguments de read (&c,1) il n'y a rien qui indique où elle va chercher les données.
C'est ce qui me fait penser que cette fonction, de prototype supposé
int read ( char* buffet, int nombre)
est une fonction membre de la classe UIPClient. Mais je peux me tromper.
Je reviens sur ma critique de mon post précédent sur le code de retour.
Si la lecture se passe bien, la variable c, de type uint8_t, c-a-d unsigned char, contient l'octet lu. Comme c'est un unsigned, sa valeur est comprise entre 0 et 255. Cette valeur est convertie en int pour être renvoyée par la fonction (sa valeur de retour). Cet int est compris entre 0 et 255.
En cas d'erreur de lecture, la fonction renvoie -1, c-a-d 0xFFFF.
Renvoyer un int, qui peut prendre plus de valeurs qu'un unsigned char, permet de renvoyer soir un caractère (0-255), soit une erreur (-1).
Ok, j'ai du nouveau: je viens de découvrir dans le fichier UIPClient.cpp la deuxième fonction read():
int
UIPClient::read(uint8_t *buf, size_t size)
{
#if ACTLOGLEVEL>=LOG_DEBUG_V3
LogObject.uart_send_strln(F("UIPClient::read(uint8_t *buf, size_t size) DEBUG_V3:Function started"));
#endif
if (*this)
{
uint16_t remain = size;
if (data->packets_in[0] == NOBLOCK)
return 0;
uint16_t read;
do
{
read = Enc28J60Network::readPacket(data->packets_in[0],0,buf+size-remain,remain);
if (read == Enc28J60Network::blockSize(data->packets_in[0]))
{
remain -= read;
_eatBlock(&data->packets_in[0]);
if (uip_stopped(&uip_conns[data->state & UIP_CLIENT_SOCKETS]) && !(data->state & (UIP_CLIENT_CLOSE | UIP_CLIENT_REMOTECLOSED)))
data->state |= UIP_CLIENT_RESTART;
if (data->packets_in[0] == NOBLOCK)
{
if (data->state & UIP_CLIENT_REMOTECLOSED)
{
data->state = 0;
data = NULL;
}
return size-remain;
}
}
else
{
Enc28J60Network::resizeBlock(data->packets_in[0],read);
break;
}
}
while(remain > 0);
return size;
}
return -1;
}
Mais je ne comprend pas comment est il possible qu'il y est deux fonctions du même nom? Comment le compilateur fait il pour les différencier?
Mais la librairie UIPEthernet c'est pour quel chip réseau ? le w5100 comme la lib officielle ou pour le Enc28J60 ?
Si c'est pour le w5100 je te dirais bien d'essayer d'utiliser la lib officielle quitte à l'adapter un peu pour ta version du shield.
Si c'est pour le Enc28J60 peut être en cherchant dans les notes d'applications microchip et leur librairie à eux.
le compilateur différencie les fonctions de même nom par leur signature :
ainsi int read( void) et int read (char*buffer, int nombre) sont bel et bien 2 fonctions différentes.
Ca s'appelle le polymorphisme du C++
Le chip réseau utilisé est le Enc28J60, il ne doit pas avoir le même fonctionnement que le W5100, je vais essayer de voir la datasheet, et j'ai publier une issue sur la page github de UIPEthernet pour voir si le créateur à une idée...