Impossible d'envoyer une commande par UDP en dehors de son réseau local.

L’auteur de ce sujet a trouvé une solution à son problème.

Reprise du dernier message de la page précédente

Aussi, quand vous parlez de pinger, c’est pinger une IP ou une IP ET un port ?

En udp, donc tu ping forcément une ip et un port qui là est le port que tu veux garder ouvert. Ça porte effectivement à confusion avec la commande ping. ;)

EDIT : Après, j’ai une alternative. C’est pas génial, mais bon. Si je peux envoyer une commande directement après avoir reçu une réponse, je pourrais très bien envoyer les commandes dans un tableau. Une sorte de liste d’attente. Et dès qu’un objet me parle, je lui envoie tout de suite toutes les commandes qui lui sont associées. L’inconvénient, c’est que si elle ne répond que toutes les heures, la commande ne sera effectuée que l’heure suivante.

Ça se fait beaucoup pour les objets connectés, avec des MQTT comme rabbitMQ. ;)

+1 -0
Auteur du sujet

Ah d’accord, merci, ça peut m’aider dans mes recherches. :) Par contre, je n’ai pas vu grand chose pour pinger de cette manière en Java. ^^

Ça se fait beaucoup pour les objets connectés, avec des MQTT comme rabbitMQ. ;)

Vraiment ? Excellent ! Alors ce principe n’est peut-être pas si mauvais du coup. :ange:

Édité par AlliageSphere

+0 -0

Cette réponse a aidé l’auteur du sujet

Pour pinailler, c’est pas totalement exact, le web c’est du TCP donc il y a une connexion établie de bout en bout.

Certes, mais du point de vue des intermédiaires, UDP ou TCP ça ne change rien… c’est des paquets à router. Quand on parle de NAT on est sur la couche 3, pas sur la couche 4.

Par contre, je n’ai pas vu grand chose pour pinger de cette manière en Java.

En fait le truc c’est dans cette discussion, il y a confusion entre la commande ping, et le concept de base du ping.

Ici, pinger, ça veut surtout dire échanger des messages régulièrement, pour s’assurer que les objets sont toujours en vie, et pour ne pas perdre les portes ouvertes par les NAT. En bref c’est un paquet UDP normal. Le but c’est pas d’utiliser le ping IGMP que fait la commande éponyme.

D’ailleurs, tu peux très bien envoyer un ping IGMP et recevoir la réponse, mais pas pour autant pouvoir communiquer avec l’objet au final. Quand tu envoies un ping iGMP depuis l’extérieur vers le réseau de la box, c’est la box qui répond, pas l’objet.

Si j’ai bien compris le principe de base des protocoles STUN et TURN, c’est essayer de savoir qui est derrière un NAT et qui ne l’est pas, et s’ils y sont les deux alors négocier un port. J’ai essayé une fois de mettre ça en place pour mamuser avec WebRTC, et effectivement c’est compliqué, j’ai pas réussi.

Édité par QuentinC

Ma plateforme avec 23 jeux de société classiques en 6 langues et 13000 joueurs: http://qcsalon.net/ | Apprenez à faire des sites web accessibles http://www.openweb.eu.org/

+1 -0
Auteur du sujet

En bref c’est un paquet UDP normal.

Ok, je vois. ^^

Donc pour éviter que le serveur ne perde la connexion à un objet il faut sans cesse envoyer des paquets UDP, même vides dès lors que l’on a reçu le premier message sur le serveur.

Mais du coup, la mise en place d’un d’un système comme je l’ai mentionné ci-dessus ne sera-t-elle pas trop gourmande en ressources pour un petit serveur ? Si l’on a 100 objets connectés, il faudrait, j’imagine, faire une boucle infinie qui enverrait toutes les secondes (peut-être, je ne sais pas) des paquets UDP à chacune des balises.

Après, ce ne sont que des paquets vides et une simple boucle, donc j’ai peut-être déjà ma réponse. :honte:

EDIT : La joie m’envahit ! :D

"Ma" méthode intermédiaire fonctionne ! :magicien: Il ne me reste plus qu’à trouver la manière d’effectuer le "hole punshing" si c’est bien ça. :)

Édité par AlliageSphere

+0 -0

Pas besoin d’envoyer aussi fréquemment que toutes les secondes. Il faudrait essayer de découvrir le timeout de la box mais ça doit être beaucoup plus que ça. En augmentant progressivement le temps d’attente entre deux paquets de manière exponentielle ça doit pouvoir se tester.

En TCP j’ai souvent vu des indications de l’ordre de 2h… J’ai un serveur de jeu en Java et j’ai même déjà dû virer des connexions zombies mortes depuis plus de 8h (j’ai même une tâche périodique qui s’occupe de faire ça).

En UDP c’est sûrement nettement moins, mais à mon avis ça doit au minimum être quelques minutes.

Ma plateforme avec 23 jeux de société classiques en 6 langues et 13000 joueurs: http://qcsalon.net/ | Apprenez à faire des sites web accessibles http://www.openweb.eu.org/

+1 -0
Auteur du sujet

Je remarque que Wireshark est souvent cité. Je vais voir ça de plus près. ^^

@QuentinC, c’est sympa de savoir ça ! Je vais essayer de trouver cette information. :)

Je me demandais justement si l’envoi régulier de paquets aurait un impact sur la consommation de données des balises. Si ce n’est que toutes les minutes, même approximativement, ça ne devrait pas être trop gourmand pour le forfait.

Je vais essayer d’en apprendre plus sur ces systèmes que vous avez mis en place. Ça peut être vraiment bien. ^^

Édité par AlliageSphere

+0 -0

Donc pour éviter que le serveur ne perde la connexion à un objet il faut sans cesse envoyer des paquets UDP, même vides dès lors que l’on a reçu le premier message sur le serveur.

UDP c’est du non connecté

Pour du TCP, c’est des keep-alive, et définit par le TCP_KEEPINTVL. Perso je le met généralement à 15 min à cause d’Android.

+0 -0
Auteur du sujet

Bonjour ! Désolé de ne pas avoir pu répondre plus tôt.

@<?php?> Je suis en train de télécharger Wireshark. :)

Ah oui ! Packet Tracer ! Je l’ai un peu utilisé en BTS SIO. Je pensais que c’était payant. Et…je l’avais oublié surtout. :o Je vais peut-être essayer de m’inscrire pour l’avoir. Merci !

@AmarOk Je vais essayer de trouver ce que m’a dit @QuentinC pour l’UDP. Si je dois programmer quelque chose pour garder la connexion avec une balise ne serait-ce qu’une minute, je serais déjà heureux. :lol:

Donc faire une sorte de "TCP_KEEPINTVL" maison j’imagine.

J’ai mis ce sujet en "Résolu". Mais si vous avez encore des choses à dire, vous pouvez. En tout cas, je vous remercie tous pour votre aide qui m’a été vraiment très utile et instructive. C’est génial ! ^^

A bientôt ! ;)

EDIT du 01/02/2019 - Résolution du problème : Bonjour ! Je reviens vers vous pour vous dire que mon problème est entièrement résolu ! Et vous n’y êtes pas pour rien. :)

Pour pouvoir envoyer des commandes à un objet connecté quand je le souhaite, c’est très simple au final. J’ai deux programmes. L’un envoie la commande destinée à un objet sur mon serveur. L’autre (mon serveur), reçoit cette trame inhabituelle. Il la traite, récupère l’IP et le port stockés et envoie la commande à mon objet. C’est aussi simple que cela. Et comme beaucoup l’ont dit précédemment, pour que cela puisse fonctionner, il faut garder un "canal ouvert". Ce qui signifie que l’objet connecté doit envoyer régulièrement des données à mon serveur pour que je puisse garder contact avec elle.

En fin de compte, j’essayais d’envoyer une commande à ma balise par l’intermédiaire d’un autre programme. Mais il n’y a QUE le programme utilisé pour la réception des données qui peut AUSSI envoyer des commandes.

Voilà, j’espère que ce sujet pourra aider d’autres personnes. :)

Édité par AlliageSphere

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte