Discussion :

[grandthor]

Bonjour,

Je crois que tout est dans le titre !! ^^

En fait j'ai un serveur linux qui gère des bornes wifi et j'utilise des petites radios pour me connecter à ce serveur.
Dès que je m'éloigne de trop d'une borne ou que la radio ce met en vielle, je perds la connexion.
Si je veux me reconnecter sur le serveur avec la même radio, je suis obliger de killer le processus de logon de cette radio.
Pour se faire, je suis sur ma machine window et je me connect en telnet sur le serveur linux et je kill le processus manuellement.

ps -fe | grep radioX
kill -9


Donc en fait je voudrais créer un petit programme en java qui se connect au serveur linux automatiquement, là je lui rentre le n° de la radio et il kill le processus.


Je suis encore dans la phase de recherche et je pense que le java est le meilleur language pour faire sa.

Si quelqu'un a une idée ou juste une remarque merci

[tchize_]

ca existe encore de linux avec du telnet?

Telnet a l'avantage d'être un protocole simple. Soit tu te trouve une librairie qui fait déj) java / telnet, soit tu attaque directement la socket. T'as pratiquement qu'à te connecter sur le port telenet, lire ce qu'on t'envoie, et y envoyer ce qu'il faut y envoyer, en pur texte

[grandthor]

ca existe encore de linux avec du telnet?

Telnet a l'avantage d'être un protocole simple. Soit tu te trouve une librairie qui fait déj) java / telnet, soit tu attaque directement la socket. T'as pratiquement qu'à te connecter sur le port telenet, lire ce qu'on t'envoie, et y envoyer ce qu'il faut y envoyer, en pur texte

Okai merci

La connexion c'est pas le problème je vois comment faire.
Par contre c'est plus l'authentification automatique et surtout les commandes et leur résultat.

En fait ma question c'est plus tot comment exécuter la commande ps -fe | grep radioX et afficher le résultat de cette derniere pour récupérer l'ID du processus à killer tout sa en java !!!

Voila est-ce que c'est possible ??

Et encore Merci pour ta réponse

[nouknouk]

salut,

si ton application est destinée à un système bien précis, tu peux faire quelque chose de très spécifique, donc:

1- tu fais une première version qui se connecte et qui te permet de taper les commandes au clavier. Cette première version enregistrera tout ce qui est reçu (donc ce que le serveur a écrit sur la console) et tout ce qui est émis (ce que tu as tapé au clavier).

2- tu peux ensuite faire une deuxième version qui enverra toute seule les commandes au clavier dès qu'elle aura reçu la chaine de caractères qui convient. Par exemple:

- lorsque ta socket recevra la chaine "login as: ", tu sauras qu'il faut automatiquement envoyer le login suivit d'un retour chariot.

- Puis tu attendras de recevoir la chaine "password: " pour envoyer le mot de passe

- Puis l'invite de commande "login@serverName:~$" pour envoyer la commande ps|grep qui va bien.
Dans le texte que tu vas petit à petit recevoir, tu vas attendre de retrouver l'invite de commande (pour déterminer quand ps|grep a terminé son exécution).
Et dans tout le texte qu'il y a avant, tu pourras extraire le PID du processus.

- etc...

[tchize_]

pas besoin de se casser la nenette à ce point là

tu te connecte sur le port
tu lit jusqu'à plus soif (plus rien à lire quoi)
-- message d'intro du serveur fini, on est dans le login:
tu écrit le login (avc le retour chariot)
tu lit jsuqu'à plus soif
tu écrit le password (avec le retour)
tu lit jusqu'à plus soif
tu balance ta commande
tu lit jusque à plus soif et éventuellement tu affiche le résultat
tu quitte sauvagement la socket :p

[nouknouk]

pas besoin de se casser la nenette à ce point là

Hem, sauf erreur de ma part, j'ai l'impression que ta solution est identique à la mienne

tu lit jusqu'à plus soif

Sauf que le "jusqu'à plus soif" n'est pas détectable en soi, sachant que le texte envoyé par le serveur peut éventuellement avoir été scindé en plusieurs paquets TCP.
D'où l'idée d'une façon plus propre pour détecter la fin de l'envoi, avec la ré-apparition de la chaîne de caractères correspondant à l'invite de commandes par exemple.