J'ai un client telnet qui, une fois connecté, lance un programme
Java et attend des commandes de mon client dans un certain format,
mais j'ai un problème lorsque celui-ci envoie des commandes de plus de
512 octets : le serveur ne les « reçoit » pas...
En simulant à la main, je constate qu'après le 512ème caractère,
le curseur est bloqué et je ne peux pas saisir plus (même pas Enter)
mais je peux revenir en arrière (Backspace), modifier et appuyer sur
Enter mais pas plus loin que le caractère 512...
Par contre, si j'essaye dans un shell Emacs (M-x shell), je
constate que ça marche sans problème... En regardant un peu avec le
client telnet, j'ai constaté avec « toggle options » qu'en lançant Emacs
dans telnet, le client telnet change de status en passant de :
telnet> status à telnet> status
Connected to localhost. Connected to localhost.
Operating in single character mode Operating in single character mode
Catching signals locally Catching signals locally
Remote character echo Remote character echo
Local flow control -------------> No flow control
Que dois faire mon client pour passer à un tel status ?
Les RFC 1080 et 1372 parlent de l'option TOGGLE-FLOW-CONTROL:
- lorsque mon client se connecte au serveur, ce dernier envoie IAC
DO TOGGLE-FLOW-CONTROL et mon client lui répond par IAC WONT
TOGGLE-FLOW-CONTROL puis ...
- mon client envoie un IAC DO TOGGLE-FLOW-CONTROL mais le serveur
répond par IAC WONT TOGGLE-FLOW-CONTROL ... donc je ne peux pas
envoyer d'IAC SB TOGGLE-FLOW-CONTROL OFF IAC SE...
Cela dit, je prends peut-être le problème à l'envers... Voilà le
log avec Emacs:
------------------------------------8<------------------------------------
smf1 $
telnet> status
Connected to localhost.
Operating in single character mode
Catching signals locally
Remote character echo
Local flow control
Escape character is '^]'.
smf1 $ emacs
RCVD IAC SB
Received suboption TOGGLE-FLOW-CONTROL OFF
..... Début de la session Emacs .......
telnet> status
Connected to localhost.
Operating in single character mode
Catching signals locally
Remote character echo
No flow control
Escape character is '^]'.
..... Fin de la session Emacs .......
RCVD IAC SB
Received suboption TOGGLE-FLOW-CONTROL ON
smf1 $
telnet> status
Connected to localhost.
Operating in single character mode
Catching signals locally
Remote character echo
Local flow control
Escape character is '^]'.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jacques Caron
Salut,
On Tue, 09 Dec 2003 01:29:30 +0800, Georges Ko wrote:
J'ai un client telnet qui, une fois connecté, lance un programme Java et attend des commandes de mon client dans un certain format, mais j'ai un problème lorsque celui-ci envoie des commandes de plus de 512 octets : le serveur ne les « reçoit » pas...
En simulant à la main, je constate qu'après le 512ème caractère, le curseur est bloqué et je ne peux pas saisir plus (même pas Enter) mais je peux revenir en arrière (Backspace), modifier et appuyer sur Enter mais pas plus loin que le caractère 512...
Je dirais que c'est le shell ou autre programme qui "attend" les commandes qui limite à 512 caractères, et pas telnet, non?
telnet> status à telnet> status Connected to localhost. Connected to localhost. Operating in single character mode Operating in single character mode Catching signals locally Catching signals locally Remote character echo Remote character echo Local flow control -------------> No flow control
Tu noteras surtout le "operating in single character mode" (par opposition à line mode) qui indique bien que ce n'est pas telnet qui bloque mais le programme au bout.
Que dois faire mon client pour passer à un tel status ?
(escape telnet) send wont LFLOW
Pas convaincu que ça marche, mais tu peux essayer. Mais comme dit plus haut, je doute très fortement que ce soit ça le problème.
Quel est le programme à qui tu envoies cette ligne de commande trop longue? Un shell? Lequel?
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Tue, 09 Dec 2003 01:29:30 +0800, Georges Ko <gko@gko.net> wrote:
J'ai un client telnet qui, une fois connecté, lance un programme
Java et attend des commandes de mon client dans un certain format,
mais j'ai un problème lorsque celui-ci envoie des commandes de plus de
512 octets : le serveur ne les « reçoit » pas...
En simulant à la main, je constate qu'après le 512ème caractère,
le curseur est bloqué et je ne peux pas saisir plus (même pas Enter)
mais je peux revenir en arrière (Backspace), modifier et appuyer sur
Enter mais pas plus loin que le caractère 512...
Je dirais que c'est le shell ou autre programme qui "attend" les commandes
qui limite à 512 caractères, et pas telnet, non?
telnet> status à telnet> status
Connected to localhost. Connected to localhost.
Operating in single character mode Operating in single character
mode
Catching signals locally Catching signals locally
Remote character echo Remote character echo
Local flow control -------------> No flow control
Tu noteras surtout le "operating in single character mode" (par opposition
à line mode) qui indique bien que ce n'est pas telnet qui bloque mais le
programme au bout.
Que dois faire mon client pour passer à un tel status ?
(escape telnet)
send wont LFLOW
Pas convaincu que ça marche, mais tu peux essayer. Mais comme dit plus
haut, je doute très fortement que ce soit ça le problème.
Quel est le programme à qui tu envoies cette ligne de commande trop
longue? Un shell? Lequel?
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Tue, 09 Dec 2003 01:29:30 +0800, Georges Ko wrote:
J'ai un client telnet qui, une fois connecté, lance un programme Java et attend des commandes de mon client dans un certain format, mais j'ai un problème lorsque celui-ci envoie des commandes de plus de 512 octets : le serveur ne les « reçoit » pas...
En simulant à la main, je constate qu'après le 512ème caractère, le curseur est bloqué et je ne peux pas saisir plus (même pas Enter) mais je peux revenir en arrière (Backspace), modifier et appuyer sur Enter mais pas plus loin que le caractère 512...
Je dirais que c'est le shell ou autre programme qui "attend" les commandes qui limite à 512 caractères, et pas telnet, non?
telnet> status à telnet> status Connected to localhost. Connected to localhost. Operating in single character mode Operating in single character mode Catching signals locally Catching signals locally Remote character echo Remote character echo Local flow control -------------> No flow control
Tu noteras surtout le "operating in single character mode" (par opposition à line mode) qui indique bien que ce n'est pas telnet qui bloque mais le programme au bout.
Que dois faire mon client pour passer à un tel status ?
(escape telnet) send wont LFLOW
Pas convaincu que ça marche, mais tu peux essayer. Mais comme dit plus haut, je doute très fortement que ce soit ça le problème.
Quel est le programme à qui tu envoies cette ligne de commande trop longue? Un shell? Lequel?
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Matthieu Moy
Georges Ko writes:
Que fait Emacs pour forcer le serveur à m'envoyer cette sous-option à OFF ?
stty ?
-- Matthieu
Georges Ko <gko@gko.net> writes:
Que fait Emacs pour forcer le serveur à m'envoyer cette sous-option à
OFF ?
Que fait Emacs pour forcer le serveur à m'envoyer cette sous-option à OFF ?
stty ?
-- Matthieu
gko
Jacques Caron wrote in message news:...
Je dirais que c'est le shell ou autre programme qui "attend" les commandes qui limite à 512 caractères, et pas telnet, non?
Quand je saisis le caractère "de trop", un bip est émis. Si je tape "stty -imaxbel" avant d'entrer dans le programme, ça bloque toujours mais il n'y a plus de bip:
imaxbel (-imaxbel) [Digital] Does (does not) ring bell on terminal when input buffer is full.
Quel est le programme à qui tu envoies cette ligne de commande trop longue? Un shell? Lequel?
Un interpréteur de commandes écrit en Java, mais le problème ne vient pas de lui, puisqu'il se comporte correctement dans Emacs...
Jacques Caron <jc@imfeurope.com> wrote in message news:<oprzvks1g2q1hokb@news.free.fr>...
Je dirais que c'est le shell ou autre programme qui "attend" les
commandes qui limite à 512 caractères, et pas telnet, non?
Quand je saisis le caractère "de trop", un bip est émis. Si je tape
"stty -imaxbel" avant d'entrer dans le programme, ça bloque toujours
mais il n'y a plus de bip:
imaxbel (-imaxbel)
[Digital] Does (does not) ring bell on terminal when input
buffer is full.
Quel est le programme à qui tu envoies cette ligne de commande trop
longue? Un shell? Lequel?
Un interpréteur de commandes écrit en Java, mais le problème ne vient
pas de lui, puisqu'il se comporte correctement dans Emacs...
Je dirais que c'est le shell ou autre programme qui "attend" les commandes qui limite à 512 caractères, et pas telnet, non?
Quand je saisis le caractère "de trop", un bip est émis. Si je tape "stty -imaxbel" avant d'entrer dans le programme, ça bloque toujours mais il n'y a plus de bip:
imaxbel (-imaxbel) [Digital] Does (does not) ring bell on terminal when input buffer is full.
Quel est le programme à qui tu envoies cette ligne de commande trop longue? Un shell? Lequel?
Un interpréteur de commandes écrit en Java, mais le problème ne vient pas de lui, puisqu'il se comporte correctement dans Emacs...
gko
Matthieu Moy wrote in message news:...
Que fait Emacs pour forcer le serveur à m'envoyer cette sous-option à OFF ?
stty ?
Ah ! Exécuter "stty raw" avant de lancer le programme résoud mon problème...
Merci pour le tuyau !
Georges
Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> wrote in message news:<vpqu14bkt1e.fsf@ecrins.imag.fr>...
Que fait Emacs pour forcer le serveur à m'envoyer cette sous-option à
OFF ?
stty ?
Ah ! Exécuter "stty raw" avant de lancer le programme
résoud mon problème...
Que fait Emacs pour forcer le serveur à m'envoyer cette sous-option à OFF ?
stty ?
Ah ! Exécuter "stty raw" avant de lancer le programme résoud mon problème...
Merci pour le tuyau !
Georges
Jacques Caron
On 8 Dec 2003 19:49:19 -0800, Georges Ko wrote:
Jacques Caron wrote in message news:...
Je dirais que c'est le shell ou autre programme qui "attend" les commandes qui limite à 512 caractères, et pas telnet, non?
Quand je saisis le caractère "de trop", un bip est émis. Si je tape "stty -imaxbel" avant d'entrer dans le programme, ça bloque toujours mais il n'y a plus de bip:
imaxbel (-imaxbel) [Digital] Does (does not) ring bell on terminal when input buffer is full.
Ce qui montre bien que le problème n'est pas au niveau de telnet, mais bien du système distant. C'est quoi comme OS?
Quel est le programme à qui tu envoies cette ligne de commande trop longue? Un shell? Lequel?
Un interpréteur de commandes écrit en Java, mais le problème ne vient pas de lui, puisqu'il se comporte correctement dans Emacs...
Sur FreeBSD, la définition de imaxbel est: imaxbel (-imaxbel) The system imposes a limit of MAX_INPUT (currently 255) char- acters in the input queue. If imaxbel is set and the input queue limit has been reached, subsequent input causes the system to send an ASCII BEL character to the output queue (the terminal beeps at you). Otherwise, if imaxbel is unset and the input queue is full, the next input character causes the entire input and output queues to be discarded.
Moi je dirais que l'interpréteur en question met (ou laisse) le terminal en mode ligne, alors que emacs est en mode caractère (nécessaire pour récupérer les séquences bizzaroïdes de emacs sans avoir à attendre un LF). Faudrait modifier les paramètres du terminal soit avec stty soit avec les APIs équivalentes.
On devient salement hors-charte, là, faudrait rediriger vers les groupe approprié en fonction de l'OS.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
On 8 Dec 2003 19:49:19 -0800, Georges Ko <gko@gko.net> wrote:
Jacques Caron <jc@imfeurope.com> wrote in message
news:<oprzvks1g2q1hokb@news.free.fr>...
Je dirais que c'est le shell ou autre programme qui "attend" les
commandes qui limite à 512 caractères, et pas telnet, non?
Quand je saisis le caractère "de trop", un bip est émis. Si je tape
"stty -imaxbel" avant d'entrer dans le programme, ça bloque toujours
mais il n'y a plus de bip:
imaxbel (-imaxbel)
[Digital] Does (does not) ring bell on terminal when input
buffer is full.
Ce qui montre bien que le problème n'est pas au niveau de telnet, mais
bien du système distant. C'est quoi comme OS?
Quel est le programme à qui tu envoies cette ligne de commande trop
longue? Un shell? Lequel?
Un interpréteur de commandes écrit en Java, mais le problème ne vient
pas de lui, puisqu'il se comporte correctement dans Emacs...
Sur FreeBSD, la définition de imaxbel est:
imaxbel (-imaxbel)
The system imposes a limit of MAX_INPUT (currently 255)
char-
acters in the input queue. If imaxbel is set and the
input
queue limit has been reached, subsequent input causes the
system to send an ASCII BEL character to the output queue
(the terminal beeps at you). Otherwise, if imaxbel is
unset
and the input queue is full, the next input character
causes
the entire input and output queues to be discarded.
Moi je dirais que l'interpréteur en question met (ou laisse) le terminal
en mode ligne, alors que emacs est en mode caractère (nécessaire pour
récupérer les séquences bizzaroïdes de emacs sans avoir à attendre un LF).
Faudrait modifier les paramètres du terminal soit avec stty soit avec les
APIs équivalentes.
On devient salement hors-charte, là, faudrait rediriger vers les groupe
approprié en fonction de l'OS.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
Je dirais que c'est le shell ou autre programme qui "attend" les commandes qui limite à 512 caractères, et pas telnet, non?
Quand je saisis le caractère "de trop", un bip est émis. Si je tape "stty -imaxbel" avant d'entrer dans le programme, ça bloque toujours mais il n'y a plus de bip:
imaxbel (-imaxbel) [Digital] Does (does not) ring bell on terminal when input buffer is full.
Ce qui montre bien que le problème n'est pas au niveau de telnet, mais bien du système distant. C'est quoi comme OS?
Quel est le programme à qui tu envoies cette ligne de commande trop longue? Un shell? Lequel?
Un interpréteur de commandes écrit en Java, mais le problème ne vient pas de lui, puisqu'il se comporte correctement dans Emacs...
Sur FreeBSD, la définition de imaxbel est: imaxbel (-imaxbel) The system imposes a limit of MAX_INPUT (currently 255) char- acters in the input queue. If imaxbel is set and the input queue limit has been reached, subsequent input causes the system to send an ASCII BEL character to the output queue (the terminal beeps at you). Otherwise, if imaxbel is unset and the input queue is full, the next input character causes the entire input and output queues to be discarded.
Moi je dirais que l'interpréteur en question met (ou laisse) le terminal en mode ligne, alors que emacs est en mode caractère (nécessaire pour récupérer les séquences bizzaroïdes de emacs sans avoir à attendre un LF). Faudrait modifier les paramètres du terminal soit avec stty soit avec les APIs équivalentes.
On devient salement hors-charte, là, faudrait rediriger vers les groupe approprié en fonction de l'OS.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
gko
Jacques Caron wrote in message news:...
Moi je dirais que l'interpréteur en question met (ou laisse) le terminal en mode ligne, alors que emacs est en mode caractère (nécessaire pour récupérer les séquences bizzaroïdes de emacs sans avoir à attendre un LF). Faudrait modifier les paramètres du terminal soit avec stty soit avec les APIs équivalentes.
On devient salement hors-charte, là, faudrait rediriger vers les groupe approprié en fonction de l'OS.
Vu que j'ai résolu mon problème en balançant un "stty raw", ce fil peut se terminer... Merci encore d'avoir jeté un coup d'oeil.
Georges
Jacques Caron <jc@imfeurope.com> wrote in message news:<oprzw55oepq1hokb@news.free.fr>...
Moi je dirais que l'interpréteur en question met (ou laisse) le terminal
en mode ligne, alors que emacs est en mode caractère (nécessaire pour
récupérer les séquences bizzaroïdes de emacs sans avoir à attendre un LF).
Faudrait modifier les paramètres du terminal soit avec stty soit avec les
APIs équivalentes.
On devient salement hors-charte, là, faudrait rediriger vers les groupe
approprié en fonction de l'OS.
Vu que j'ai résolu mon problème en balançant un "stty raw", ce
fil peut se terminer... Merci encore d'avoir jeté un coup
d'oeil.
Moi je dirais que l'interpréteur en question met (ou laisse) le terminal en mode ligne, alors que emacs est en mode caractère (nécessaire pour récupérer les séquences bizzaroïdes de emacs sans avoir à attendre un LF). Faudrait modifier les paramètres du terminal soit avec stty soit avec les APIs équivalentes.
On devient salement hors-charte, là, faudrait rediriger vers les groupe approprié en fonction de l'OS.
Vu que j'ai résolu mon problème en balançant un "stty raw", ce fil peut se terminer... Merci encore d'avoir jeté un coup d'oeil.
