Discussion :

[Emmanuel Delahaye]

Un Telnet écrit avec la bibliothèque gnet

http://gtermix.sourceforge.net/download.html

Regarde notamment le fichier telnet.c, il y est question de la négociation.

[dva2tlse]

arg' encore un pavé

oui, et je savais à l'avance qu'il serait apprécié; nan, sans dek' je ne le ferai plus (vous m'êtes trop précieux par vos indications pour que je prenne bêtement le risque que la conversation tourne court, et encore MERCI pour les éclairages que vous me donnez)

Regarde notamment le fichier telnet.c, il y est question de la négociation.

Oui merci; je disais avant-hier que j'étais en train de m'approprier le code de l'ancien fil de discution qu'avait écrit yartempion, mais en guise d'appropriation, je ne vais que lui piquer les quelques lignes qui entament la négociation, et je vais laisser tomber tout le reste qui me provoque des tas de passages en force à la compil', surtout que je ne sais pas corriger ces erreurs toutes relatives à des pointeurs non "castés" que je ne sait pas rendre propres.
(Alors que malgré mon inexpérience, mon code à moi était propre)
Bon aller, je vais voir ce que m'a indiqué Emmanuel, et à une prochaine fois,
David

[Emmanuel Delahaye]

Oui merci; je disais avant-hier que j'étais en train de m'approprier le code de l'ancien fil de discution qu'avait écrit yartempion, mais en guise d'appropriation, je ne vais que lui piquer les quelques lignes qui entament la négociation, et je vais laisser tomber tout le reste qui me provoque des tas de passages en force à la compil', surtout que je ne sais pas corriger ces erreurs toutes relatives à des pointeurs non "castés" que je ne sait pas rendre propres.

Donne un lien, je le clean en moins de 2[1], c'est ma spécialité.

-----------------
[1]unité à définir !

[dva2tlse]

le lien vers le code en question je l'ai déjà mis, ( http://www.developpez.net/forums/d34...rrerid=208640; ) et je viens d'y enlever tous les malloc, realloc et free, qui ne sont jamais utilisés dans le code que je vois en suivant ton lien; de toute façon, je suppose naïvement que ça ne doit servir que quand on a des gros pavés (!) de mémoire à utiliser; ce n'est pas le cas d'un négociation telnet avec ses trois malheureux caractères qui montent à dix ou douze en cas de sous-option compliquée. Donc je n'ai plus de gamelle sur le free double ou je-ne-sais quoi, mais je me retrouve simplement avec une négociation qui ne s'arrête jamais, ce qui est un simple problème dans la logique d'icelle qui ne va assurément pas être difficile à résoudre; juste du if-then-else bien taillé ou un switch adéquat. c'est tout bon,
à bientôt dès que ça se décante...
David

[Emmanuel Delahaye]

le lien vers le code en question je l'ai déjà mis, ( http://www.developpez.net/forums/d34...rrerid=208640; )

Je vais regarder demain. A l'époque, je l'avais renvoyé à ses études...

[dva2tlse]

Encore bonjour les gars du net', bonjour à l'heure où j'écris, ou bonsoir pour l'heure à laquelle je suppose que vous me lirez.
Hier soir j'ai encore un peu bidouillé mon code et il se pose à moi la question suivante que je garde sous la main pour vous tenir en haleine le temps de quelques explications préalables.
J'ai donc enlevé d'icelui [mon code] les calloc, malloc et réalloc qui faisaient semblant de s'occuper de la mémoire et qui faisaient surtout prendre une belle gamelle à mon futur client telnet qui devient de plus en plus beau; et pour l'embellir encore, serait-il possible d'y enlever également les select et autres FDISSET et FDZERO, qui eux font semblant de multiplexer les E-S, alors qu'il n'y en a jamais que deux de chaque : modem et clavier en entrée, et écran plus modem en sortie; donc ce n'est peut-être pas la peine de faire compliqué si on peut faire simple !
À ce sujet d'ailleurs, avant même que le soi-disant multiplexage ne soit mis en place, mon embryon de client telnet entame la négociation avec le serveur en écrivant plusieurs commandes sur le socket, et le retour de la fonction write qui fait ces envois est bien non nul. (mais je pense à l'instant que j'aurais du vérifier si c'était bien 3, qui est le nombre d'octets de ces commandes simples que j'envoie)
Donc ça a l'air de marcher correctement avant même que soit mis en place, et probablement de façon bancale, le multiplexage en question.
Par ailleurs, dans l'exemple de code qui est au bout du lien que m'a envoyé Émmanuel, il n'y a aucune bidouille de ce genre; alors est-ce que je peux virer les select et autres &rd et &wr qui alourdissent mon code peut être sans nécessité absolue ?
Vous remarquerez que ce post d'aujourd'hui est vraiment bien... Pas de code, Pas de lourdeurs, une seule question, -nickel quoi.
David

[Emmanuel Delahaye]

alors est-ce que je peux virer les select et autres &rd et &wr qui alourdissent mon code peut être sans nécessité absolue ?
Vous remarquerez que ce post d'aujourd'hui est vraiment bien... Pas de code, Pas de lourdeurs, une seule question, -nickel quoi.
David

Plus c'est simple, mieux c'est.

Maintenant, attention à ne pas utiliser des mots 'hors contexte'.

Pas de 'modem' ici. Un socket. C'est tout.
Pas de 'multiplexage', mais une attente sur évènements multiples.

Etant donné que Windows ne sait pas gérer autre chose que les sockets avec select(), je ne pourrais pas te suivre dans l'usage de select().

Personnellement, j'utilise plutôt les threads, ce qui, à mon sens, est plus adapté au code synchrone. En gros, une tâche par fonction bloquante

• clavier ; fgets() ou fgetc()
• socket : recv().

Comme le proramme principal est déjà une tâche (thread), il suffit d'en créer un supplémentaire et le tour est joué.

• Tache principale (main() etc.) :
  
  • attente clavier
  • émission de données
• Tache ajoutée :
  
  • attente reception
  • affichage des données reçues

[dva2tlse]

Tu as l'air de trouver simple de créer des threads qui pourraient simplifier les choses, mais moi je n'en suis qu'à concevoir un travail monotâche, et je ne sais pas "créer" de threads tel le Merlin enchanteur moyen.
Et en plus j'ai fait une connerie moyenne en voulant nettoyer un peu trop mon code tel le maniaque moyen, et ça ne se connecte plus sur mon propre serveur; j'espère que c'est seulement à cause du firestarter, mais c'est pas sûr, je vérifie... OUF ça remarche; ça ne va pas loin puisque ça bloque juste après le premier ou deuxième envoi de commande au début, mais du moment qu'il cause avec le serveur, ça va bien.
En relisant le mot "firestarter" ci dessus, ça me fait penser que t'as parlé de windows alors que je ne m'en sers plus, c'est sous ubuntu que j'essaye d'initier une session telnet sur un serveur qui me laisserait continuer, alors quelles sont les considérations à prendre en compte dans ce que tu écris ?
à bientôt,
David

[Emmanuel Delahaye]

Tu as l'air de trouver simple de créer des threads qui pourraient simplifier les choses, mais moi je n'en suis qu'à concevoir un travail monotâche, et je ne sais pas "créer" de threads tel le Merlin enchanteur moyen.

http://emmanuel-delahaye.developpez.com/pthreads.htm

[dva2tlse]

mouais, j'ai lu ce que tu m'as envoyé mais j'ai pas envie de me plonger là dedans tant que ce n'est pas pour améliorer quelque chose qui marcherait; donc ça sera une étape ultérieure quand j'aurai vraiment BESOIN que ça marche mieux; or pour l'instant ça ne marche encore pas du tout; alors dis moi simplement si je peux m'en sortir en évacuant tous mes select et ce qui va avec.
Merci,
D.

[Emmanuel Delahaye]

mouais, j'ai lu ce que tu m'as envoyé mais j'ai pas envie de me plonger là dedans tant que ce n'est pas pour améliorer quelque chose qui marcherait;

Vu que tu as 2 entrées (clavier et socket) c'est ça ou select().

Les threads, c'est extrêmement simple. J'ai indiqué la structure du code et il ya des exemples pas à pas et détaillés dans mon article...

[dva2tlse]

Bon, j'y retourne voir, mais mon espoir que ça aille un peu plus loin s'évanouit.
bonsoir et merci,
David

[22h35] ben j'ai encore un peu lu sans trop comprendre, mais surtout j'ai vu que dans l'exemple que tu m'as signalé, il n'y avait ni select ni départ de thread.
D.

[dva2tlse]

Encore une petite question pour Émmanuel; ceci est une question concernant ce qui se passera quand ça marchera; est-ce que le fait d'avoir différents threads pour les différentes sources de données changera quoi que ce soit, vu que de toute féçon il n'y a qu'un seul microprocesseur qui se tape tout le boulot ?
Cependant ceci me décide à me refaire une petite lecture :

il ya des exemples pas à pas et détaillés dans mon article...

Mais je voudrais ton avis là dessus :

j'ai vu que dans l'exemple que tu m'as signalé, il n'y avait ni select ni départ de thread

à bientôt,
David

[Emmanuel Delahaye]

Encore une petite question pour Émmanuel; ceci est une question concernant ce qui se passera quand ça marchera; est-ce que le fait d'avoir différents threads pour les différentes sources de données changera quoi que ce soit, vu que de toute féçon il n'y a qu'un seul microprocesseur qui se tape tout le boulot ?

Bah, visiblement, tu ne sais pas ce que sont les threads... Le but n'est pas de faire du parallélisme, mais de ne pas bloquer le programme à cause d'une attente... Les traitements synchrones libèrent le processeur dès qu'ils passent en attente (fgetc(), fgets(), accept(), connect(), receive())

Si tu as une séquence

Code :

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

1
2
3
4
5
6
7
 
do
 fgets()
 send()
 recv()
 printf()
while(1)

ca marche beaucoup moins bien que 2 boucles séparées et indépendantes :
Emission

Code :

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

1
2
3
4
5
 
do
 fgets()
 send()
while(1)

Réception

Code :

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

1
2
3
4
5
 
do
 recv()
 printf()
while(1)

C'est essentiellement du au fait que dans un terminal, la réception de données en beaucoup plus importante en volume que l'émission de données (en gros 1/10). Si à la moindre commande, on fait une réception, on risque de louper 90% du message (il n'est pas perdu, mais il arrive après la prochaine commande, ce qui est absurde...

Si on met une boucle de réception quel est le critère pour en sortir ? Il n'y a pas d'autre solution simple que les threads. Chacun sa boucle et affaire réglée.

[delete]

Au risque de dire une connerie, initialement, les échanges entre telnet client & serveur ne se sont jamais fait avec des threads puisque n'existant pas à l'époque.

Eventuellement il pouvait y avoir des processes avec un échange via shared memory, messages queues et synchro avec semaphores...

Ceci dit je reste sur ma position que c'est une vaste erreur de développer un client telnet alors qu'il y en a plein sur le "marché"...

[Emmanuel Delahaye]

Au risque de dire une connerie, initialement, les échanges entre telnet client & serveur ne se sont jamais fait avec des threads puisque n'existant pas à l'époque.

La solution Unix est d'utiliser des processus (fork() etc.) C'est lourd et compliqué...

Eventuellement il pouvait y avoir des processes avec un échange via shared memory, messages queues et synchro avec semaphores

voila...

Ceci dit je reste sur ma position que c'est une vaste erreur de développer un client telnet alors qu'il y en a plein sur le "marché"...

A titre expérimental, ce n'est pas inintéressant. Pour en faire un produit, non, évidemment, surtout que c'est un gruyère bien connu, surtout face à SSH.

[delete]

A titre expérimental, ce n'est pas inintéressant. Pour en faire un produit, non, évidemment, surtout que c'est un gruyère bien connu, surtout face à SSH.

A titre pédagogique, effectivement tu as raison.

Nous en parlions déjà quant à la gestion des TTY, même hors Telnet... misère, misère...

[dva2tlse]

Chers messieurs, je vous laisse à vos discussions stratosphériques qui me passent 30 000 pieds au dessus de la tête, et j'ai un petit client telnet terre à terre qui plante tout gentiment au moment d'une demande de sous-négociation de l'option 24, donc tout va très bien puisque c'est une vulgaire "Erreur de segmentation" (mal traduite je trouve) et donc il devrait me suffire de reporter ce qui se passe au niveau des négociations vers celui des SOUS-négociations, et mon client ira encore un peu plus loin vers l'ouverture d'une session avec le serveur.

Pour delete :

c'est une vaste erreur de développer un client telnet alors qu'il y en a plein sur le "marché"

"plein sur le marché", peut-être, mais pas mon-mien qui se connecte à une machine A quand je ferai "boulot A" ou à la machine B quand je ferai "boulot B" pour contrôler un deuxième type de calculs, et si je veux bien passer quelques temps à bosser depuis chez moi parfois, ce n'est pas pour le perdre, ce temps, à taper des adresse IP compliquées qui se ressemblent toutes alors que je pourrais être connecté avant même que d'avoir fini de taper.

Pour Émmanuel :

A titre pédagogique

bien sûr que c'est ça qui m'intéresse, et j'ai même commencé à coder en C pour résoudre le problème du cavalier d'Euler; maintenant j'en suis à voir un peu ce qui se passe avec le net', et bientôt, mon fils m'aidera à faire quelques premiers pas en html puisqu'il en à appris des rudiments lors d'un stage scientifique cet été où il a fait de l'astronomie et ça.

Pour tous : (si un des assez nombreux autres lecteurs peut me donner l'information pour ma culture générale, qui manque pourtant cruellement de quelque chose de vraiment général)
J'ai lu dans le man de htonl, htons, ntohl et ntohs, que

Sur les i80x86, l’ordre des octets de l’hôte est LSB [.../...] alors que sur les réseaux, notamment internet, l’ordre est MSB.

Il me semble que sous unix on a aussi du MSB, et alors ces quatre fonctions de renversement n'auraient plus lieu d'être; est-ce bien le cas ? (que unix soit en MSB et que ces quatre fonction sont inutiles sous unix)
à bientôt,
David

[Emmanuel Delahaye]

Pour tous : (si un des assez nombreux autres lecteurs peut me donner l'information pour ma culture générale, qui manque pourtant cruellement de quelque chose de vraiment général)
J'ai lu dans le man de htonl, htons, ntohl et ntohs, que
Il me semble que sous unix on a aussi du MSB, et alors ces quatre fonctions de renversement n'auraient plus lieu d'être; est-ce bien le cas ? (que unix soit en MSB et que ces quatre fonction sont inutiles sous unix)
à bientôt,
David

Ce n'est pas une question de système mais d'architecture. En x86, les données sont stockées LSB en tête. En 68k/PowerPC, c'est MSB en tête. il y a même d'autre codages sur certaines machines exotiques.

L'important est que le réseau est MSB en tête (c'est la norme pour le bits et pour les bytes).

Afin d'assurer l'interopérabilité entre les différentes machines, il convient de respecter la norme.

[dva2tlse]

Ça y est presque, j'ai vu ma propre invite de login par telnet, YOUPI; alors demain j'essaye de me logger pour de bon et finito ou presque; enfin il sera devenu possible de penser à des améliorations cher Emmanuel.
à bientôt,
D.