Bonjour a tous,
J'espère que je suis sur le bon newsgroups sinon, excusez-moi de vous
parasiter.
Je me suis lancé dans le codage en C d'un module permettant de récupérer
un fichier via un serveur ftp distant. La ou cela se complique, c'est
que je ne veux pas utiliser une librairie toute faite de client ftp, je
veux programmer une fonction 'get_fichier_ftp' (simplifiée) en utilisant
les sockets (d'une lib tcp/ip).
J'arrive à échanger des données via des sockets (socket, listen,
bind,...) mais pour me connecter a un serveur et suivre le protocole,
c'est une autre histoire. Est-ce que quelqu'un a une piste, une idée, un
exemple pour implémenter cette partie du protocole FTP ou est-ce que je
dois connaitre la RFC959 par coeur pour pouvoir le faire...
Merci pour votre aide,
aVr
Bonjour a tous, J'espère que je suis sur le bon newsgroups sinon, excusez-moi de vous parasiter. Je me suis lancé dans le codage en C d'un module permettant de récupérer un fichier via un serveur ftp distant. La ou cela se complique, c'est que je ne veux pas utiliser une librairie toute faite de client ftp, je veux programmer une fonction 'get_fichier_ftp' (simplifiée) en utilisant les sockets (d'une lib tcp/ip). J'arrive à échanger des données via des sockets (socket, listen, bind,...) mais pour me connecter a un serveur et suivre le protocole, c'est une autre histoire. Est-ce que quelqu'un a une piste, une idée, un exemple pour implémenter cette partie du protocole FTP ou est-ce que je dois connaitre la RFC959 par coeur pour pouvoir le faire...
Oui.
La question c'est pourquoi tu ne peux pas utiliser une bibliothèque existante, ou pourquoi tu ne pourrais pas lire une implémentation en source libre, pour apprendre comment on fait?
PLEASE NOTE: Some quantum physics theories suggest that when the consumer is not directly observing this product, it may cease to exist or will exist only in a vague and undetermined state.
aVrama <avrama@free.fr> writes:
Bonjour a tous,
J'espère que je suis sur le bon newsgroups sinon, excusez-moi de vous
parasiter.
Je me suis lancé dans le codage en C d'un module permettant de
récupérer un fichier via un serveur ftp distant. La ou cela se
complique, c'est que je ne veux pas utiliser une librairie toute faite
de client ftp, je veux programmer une fonction 'get_fichier_ftp'
(simplifiée) en utilisant les sockets (d'une lib tcp/ip).
J'arrive à échanger des données via des sockets (socket, listen,
bind,...) mais pour me connecter a un serveur et suivre le protocole,
c'est une autre histoire. Est-ce que quelqu'un a une piste, une idée,
un exemple pour implémenter cette partie du protocole FTP ou est-ce
que je dois connaitre la RFC959 par coeur pour pouvoir le faire...
Oui.
La question c'est pourquoi tu ne peux pas utiliser une bibliothèque
existante, ou pourquoi tu ne pourrais pas lire une implémentation en
source libre, pour apprendre comment on fait?
PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.
Bonjour a tous, J'espère que je suis sur le bon newsgroups sinon, excusez-moi de vous parasiter. Je me suis lancé dans le codage en C d'un module permettant de récupérer un fichier via un serveur ftp distant. La ou cela se complique, c'est que je ne veux pas utiliser une librairie toute faite de client ftp, je veux programmer une fonction 'get_fichier_ftp' (simplifiée) en utilisant les sockets (d'une lib tcp/ip). J'arrive à échanger des données via des sockets (socket, listen, bind,...) mais pour me connecter a un serveur et suivre le protocole, c'est une autre histoire. Est-ce que quelqu'un a une piste, une idée, un exemple pour implémenter cette partie du protocole FTP ou est-ce que je dois connaitre la RFC959 par coeur pour pouvoir le faire...
Oui.
La question c'est pourquoi tu ne peux pas utiliser une bibliothèque existante, ou pourquoi tu ne pourrais pas lire une implémentation en source libre, pour apprendre comment on fait?
PLEASE NOTE: Some quantum physics theories suggest that when the consumer is not directly observing this product, it may cease to exist or will exist only in a vague and undetermined state.
Mihamina Rakotomandimby (R12y)
Pascal Bourguignon wrote:
La question c'est pourquoi tu ne peux pas utiliser une bibliothèque existante,
Il veut apprendre.
ou pourquoi tu ne pourrais pas lire une implémentation en source libre, pour apprendre comment on fait?
Oui mais non. Si je veux apprendre à faire un kernel, me baser sur le code _actuel_ de FreeBSD ou Linux serait... décourageant. Ca aurait été interessant d'en suivre l'évolution depuis Minix, mais on est loin de Minix... Les projets en source libre existants se sont compliqué avec le temps. Un "débutant" ne peut pas prendre le train en marche simplement.
Pascal Bourguignon wrote:
La question c'est pourquoi tu ne peux pas utiliser une bibliothèque
existante,
Il veut apprendre.
ou pourquoi tu ne pourrais pas lire une implémentation en
source libre, pour apprendre comment on fait?
Oui mais non.
Si je veux apprendre à faire un kernel, me baser sur le code _actuel_ de
FreeBSD ou Linux serait... décourageant. Ca aurait été interessant d'en
suivre l'évolution depuis Minix, mais on est loin de Minix...
Les projets en source libre existants se sont compliqué avec le temps.
Un "débutant" ne peut pas prendre le train en marche simplement.
La question c'est pourquoi tu ne peux pas utiliser une bibliothèque existante,
Il veut apprendre.
ou pourquoi tu ne pourrais pas lire une implémentation en source libre, pour apprendre comment on fait?
Oui mais non. Si je veux apprendre à faire un kernel, me baser sur le code _actuel_ de FreeBSD ou Linux serait... décourageant. Ca aurait été interessant d'en suivre l'évolution depuis Minix, mais on est loin de Minix... Les projets en source libre existants se sont compliqué avec le temps. Un "débutant" ne peut pas prendre le train en marche simplement.
espie
In article <f15465$vlo$, Mihamina Rakotomandimby (R12y) wrote:
Si je veux apprendre à faire un kernel, me baser sur le code _actuel_ de FreeBSD ou Linux serait... décourageant. Ca aurait été interessant d'en suivre l'évolution depuis Minix, mais on est loin de Minix... Les projets en source libre existants se sont compliqué avec le temps. Un "débutant" ne peut pas prendre le train en marche simplement.
Ton analogie presente un leger probleme: si on veut faire un client ftp qui fonctionne, ca revient a prendre le train en marche de toutes facons, vu tous les petits details qui se sont rajoutes a la spec de base, et que tu ne peux ignorer.
Note que pour les noyaux, c'est un peu pareil. Meme en repartant de zero, vu la facon dont fonctionne le hard actuel, ca ne va pas non plus etre super-simple. Sauf si tu as du matos tres specifique, faire un semblant de noyau sur un PC aujourd'hui, ca revient a parler PCI, Sata, et USB... pas exactement une mince affaire.
In article <f15465$vlo$2@cabale.usenet-fr.net>,
Mihamina Rakotomandimby (R12y) <mihamina@rktmb.org> wrote:
Si je veux apprendre à faire un kernel, me baser sur le code _actuel_ de
FreeBSD ou Linux serait... décourageant. Ca aurait été interessant d'en
suivre l'évolution depuis Minix, mais on est loin de Minix...
Les projets en source libre existants se sont compliqué avec le temps.
Un "débutant" ne peut pas prendre le train en marche simplement.
Ton analogie presente un leger probleme: si on veut faire un client ftp
qui fonctionne, ca revient a prendre le train en marche de toutes facons,
vu tous les petits details qui se sont rajoutes a la spec de base, et que
tu ne peux ignorer.
Note que pour les noyaux, c'est un peu pareil. Meme en repartant de zero,
vu la facon dont fonctionne le hard actuel, ca ne va pas non plus etre
super-simple. Sauf si tu as du matos tres specifique, faire un semblant
de noyau sur un PC aujourd'hui, ca revient a parler PCI, Sata, et USB...
pas exactement une mince affaire.
In article <f15465$vlo$, Mihamina Rakotomandimby (R12y) wrote:
Si je veux apprendre à faire un kernel, me baser sur le code _actuel_ de FreeBSD ou Linux serait... décourageant. Ca aurait été interessant d'en suivre l'évolution depuis Minix, mais on est loin de Minix... Les projets en source libre existants se sont compliqué avec le temps. Un "débutant" ne peut pas prendre le train en marche simplement.
Ton analogie presente un leger probleme: si on veut faire un client ftp qui fonctionne, ca revient a prendre le train en marche de toutes facons, vu tous les petits details qui se sont rajoutes a la spec de base, et que tu ne peux ignorer.
Note que pour les noyaux, c'est un peu pareil. Meme en repartant de zero, vu la facon dont fonctionne le hard actuel, ca ne va pas non plus etre super-simple. Sauf si tu as du matos tres specifique, faire un semblant de noyau sur un PC aujourd'hui, ca revient a parler PCI, Sata, et USB... pas exactement une mince affaire.
Xavier Roche
Ton analogie presente un leger probleme: si on veut faire un client ftp qui fonctionne, ca revient a prendre le train en marche de toutes facons, vu tous les petits details qui se sont rajoutes a la spec de base, et que tu ne peux ignorer.
Euh, si. La RFC 959 impose uniquement une poignée de commandes:
5.1. MINIMUM IMPLEMENTATION
In order to make FTP workable without needless error messages, the following minimum implementation is required for all servers:
TYPE - ASCII Non-print MODE - Stream STRUCTURE - File, Record COMMANDS - USER, QUIT, PORT, TYPE, MODE, STRU, for the default values RETR, STOR, NOOP.
Bon, on est un peu HS ici, mais je dirais que de toute manière, ftp est un protocole mal baisé (l'injection de l'IP du niveau d'en dessous dans le protocole était décidément pas une bonne idée) et que pour faire joujou, HTTP est beaucoup plus abordable.
Ton analogie presente un leger probleme: si on veut faire un client ftp
qui fonctionne, ca revient a prendre le train en marche de toutes facons,
vu tous les petits details qui se sont rajoutes a la spec de base, et que
tu ne peux ignorer.
Euh, si. La RFC 959 impose uniquement une poignée de commandes:
5.1. MINIMUM IMPLEMENTATION
In order to make FTP workable without needless error messages, the
following minimum implementation is required for all servers:
TYPE - ASCII Non-print
MODE - Stream
STRUCTURE - File, Record
COMMANDS - USER, QUIT, PORT,
TYPE, MODE, STRU,
for the default values
RETR, STOR,
NOOP.
Bon, on est un peu HS ici, mais je dirais que de toute manière, ftp est
un protocole mal baisé (l'injection de l'IP du niveau d'en dessous dans
le protocole était décidément pas une bonne idée) et que pour faire
joujou, HTTP est beaucoup plus abordable.
Ton analogie presente un leger probleme: si on veut faire un client ftp qui fonctionne, ca revient a prendre le train en marche de toutes facons, vu tous les petits details qui se sont rajoutes a la spec de base, et que tu ne peux ignorer.
Euh, si. La RFC 959 impose uniquement une poignée de commandes:
5.1. MINIMUM IMPLEMENTATION
In order to make FTP workable without needless error messages, the following minimum implementation is required for all servers:
TYPE - ASCII Non-print MODE - Stream STRUCTURE - File, Record COMMANDS - USER, QUIT, PORT, TYPE, MODE, STRU, for the default values RETR, STOR, NOOP.
Bon, on est un peu HS ici, mais je dirais que de toute manière, ftp est un protocole mal baisé (l'injection de l'IP du niveau d'en dessous dans le protocole était décidément pas une bonne idée) et que pour faire joujou, HTTP est beaucoup plus abordable.
Pascal Bourguignon
"Mihamina Rakotomandimby (R12y)" writes:
Pascal Bourguignon wrote:
La question c'est pourquoi tu ne peux pas utiliser une bibliothèque existante,
Il veut apprendre.
Oui, alors c'est difficile de faire l'impasse sur les RFC.
Je ne commencerais pas par FTP, c'est un protocole plus compliqué que la plupart comme il utilise normalement deux connexions TCP/IP.
SMTP ou POP3 serait un bon commencement.
De toutes façons, une fois qu'on a implementé un protocole à partir seulement des RFC, ce n'est pas une mauvaise idée de jetter un oeuil sur d'autres implémentations et de comparer avec ce qu'on a fait.
ou pourquoi tu ne pourrais pas lire une implémentation en source libre, pour apprendre comment on fait?
Oui mais non. Si je veux apprendre à faire un kernel, me baser sur le code _actuel_ de FreeBSD ou Linux serait... décourageant. Ca aurait été interessant d'en suivre l'évolution depuis Minix, mais on est loin de Minix... Les projets en source libre existants se sont compliqué avec le temps. Un "débutant" ne peut pas prendre le train en marche simplement.
La question c'est pourquoi tu ne peux pas utiliser une bibliothèque
existante,
Il veut apprendre.
Oui, alors c'est difficile de faire l'impasse sur les RFC.
Je ne commencerais pas par FTP, c'est un protocole plus compliqué que
la plupart comme il utilise normalement deux connexions TCP/IP.
SMTP ou POP3 serait un bon commencement.
De toutes façons, une fois qu'on a implementé un protocole à partir
seulement des RFC, ce n'est pas une mauvaise idée de jetter un oeuil
sur d'autres implémentations et de comparer avec ce qu'on a fait.
ou pourquoi tu ne pourrais pas lire une implémentation en
source libre, pour apprendre comment on fait?
Oui mais non.
Si je veux apprendre à faire un kernel, me baser sur le code _actuel_ de
FreeBSD ou Linux serait... décourageant. Ca aurait été interessant d'en
suivre l'évolution depuis Minix, mais on est loin de Minix...
Les projets en source libre existants se sont compliqué avec le temps.
Un "débutant" ne peut pas prendre le train en marche simplement.
La question c'est pourquoi tu ne peux pas utiliser une bibliothèque existante,
Il veut apprendre.
Oui, alors c'est difficile de faire l'impasse sur les RFC.
Je ne commencerais pas par FTP, c'est un protocole plus compliqué que la plupart comme il utilise normalement deux connexions TCP/IP.
SMTP ou POP3 serait un bon commencement.
De toutes façons, une fois qu'on a implementé un protocole à partir seulement des RFC, ce n'est pas une mauvaise idée de jetter un oeuil sur d'autres implémentations et de comparer avec ce qu'on a fait.
ou pourquoi tu ne pourrais pas lire une implémentation en source libre, pour apprendre comment on fait?
Oui mais non. Si je veux apprendre à faire un kernel, me baser sur le code _actuel_ de FreeBSD ou Linux serait... décourageant. Ca aurait été interessant d'en suivre l'évolution depuis Minix, mais on est loin de Minix... Les projets en source libre existants se sont compliqué avec le temps. Un "débutant" ne peut pas prendre le train en marche simplement.
On Mon, 30 Apr 2007 22:37:07 +0200, Xavier Roche wrote:
Ne vous ait déjà pas arrivé de penser qu'il y a une différence entre un kernel et un client ftp ?
C'est un micro-kernel, et les messages sont envoyés par ftp.
Quelle idée !
Antoine Leca
En news:f15465$vlo$, Mihamina Rakotomandimby (R12y) va escriure:
Il veut apprendre.
Pascal Bourguignon wrote:
ou pourquoi tu ne pourrais pas lire une implémentation en source libre, pour apprendre comment on fait?
Oui mais non. Si je veux apprendre à faire un kernel, me baser sur le code _actuel_ de FreeBSD ou Linux serait... décourageant.
Certes. (Et inutile, aussi, mais c'est un autre débat.)
Ca aurait été interessant d'en suivre l'évolution depuis Minix, mais on est loin de Minix...
Mouais. Bof.
En ce qui concerne Linux, Linux puise quelques racines éparses dans Minix (par exemple au niveau du format de système de fichiers utilisé pour les disquettes), mais les connexions au niveau du source sont quasiment inexistantes, et ce depuis le tout début. Une rapide recherche sur la toile avec comme mots-clé « Tannenbaum Torvalds » ramène une ample documentation sur le thème. Il y a beaucoup plus de connexions entre Système V et Linux (à travers le livre de Maurice Bach) ; et pourtant le code est différent, au point que SCO n'a jamais réussit à établir la moindre filiation probante (devant les tribunaux).
En ce qui concerne FreeBSD, ce système d'exploitation n'a rien à voir _du tout_ avec Minix. En fait, si on parle d' « évolution » (guillemets indispensables), elle est --très partiellement-- dans l'autre sens, de BSD vers Minix !
Si on veut faire des études de filiation, il faudrait plutôt citer le livre de J. Lyons comme référence de départ. Et effectivement, l'évolution est vertigineuse. Mais l'étude du code de 1976 n'est probablement pas inutile (suivie de celle de 3/4BSD, en particulier en ce qui concerne la mémoire virtuelle), elle permet d'aquérir un sens de l'orientation qui permet de comprendre comment s'organise le noyau actuel de FreeBSD. De même, étudier le code de Linux 0.12 (par exemple) permet de comprendre l'organisation principale du système, sans être noyé dans les détails des améliorations de performances ou de l'indépendance du matériel.
Et je suis persuadé que quelqu'un qui commence par étudier ces « glorieux ancêtres » peut ensuite aborder beaucoup plus facilement le code actuel. Bien entendu, le même raisonnement vaut pour les projets similaires, comme par exemple... le client ftp de 4BSD (dans src/ucb/ftp, environ 50.000 caractères, sans guère de commentaires).
Les projets en source libre existants se sont compliqué avec le temps. Un "débutant" ne peut pas prendre le train en marche simplement.
Puisque tu en as cité un ! Il existe pourtant un projet de noyau, en « source libre », qui est suffisament abordable pour être effectivement enseigné. Certes le code d'aujourd'hui (la version 3 est sortie en 2006, en liaison avec la réédition du livre évidemment) est plus compliqué qu'il ne l'était en 1988-89, mais la puissance des outils n'a plus rien à voir, au final il est plus facile de travailler sur le code actuel que cela ne l'était à l'époque héroïque.
Évidemment, étudier le code du noyau de Minix sans le guide du livre, ou en moins d'un mois, c'est probablement hors de portée d'un débutant en programmation. De la même façon que cela l'était en 1989, d'ailleurs.
On touche là à une différence importante entre un projet « normal » (où il est effectivement difficile de prendre le train en marche, car rien n'est fait pour cela), qui va à terme sombrer dans l'oubli lorsque les développeurs actuels s'en désintéresseront (en fait, lorsque l'utilité deviendra inférieure au coût de maintenance), et les projets « marquants », qui suscitent un mouvement de fond comprenant entre autres une bibliographie, dont la consultation permet justement de prendre ce fameux train, et par tant d'abaisser le coût de la maintenance globale du projet (en augmentant la main-d'½uvre disponible; la force de travail devient moins chère s'il y a afflux de travailleurs vous diraient les économistes).
Antoine
En news:f15465$vlo$2@cabale.usenet-fr.net,
Mihamina Rakotomandimby (R12y) va escriure:
Il veut apprendre.
Pascal Bourguignon wrote:
ou pourquoi tu ne pourrais pas lire une implémentation en
source libre, pour apprendre comment on fait?
Oui mais non.
Si je veux apprendre à faire un kernel, me baser sur le code _actuel_
de FreeBSD ou Linux serait... décourageant.
Certes.
(Et inutile, aussi, mais c'est un autre débat.)
Ca aurait été interessant d'en suivre l'évolution depuis Minix,
mais on est loin de Minix...
Mouais. Bof.
En ce qui concerne Linux, Linux puise quelques racines éparses dans Minix
(par exemple au niveau du format de système de fichiers utilisé pour les
disquettes), mais les connexions au niveau du source sont quasiment
inexistantes, et ce depuis le tout début. Une rapide recherche sur la toile
avec comme mots-clé « Tannenbaum Torvalds » ramène une ample documentation
sur le thème.
Il y a beaucoup plus de connexions entre Système V et Linux (à travers le
livre de Maurice Bach) ; et pourtant le code est différent, au point que SCO
n'a jamais réussit à établir la moindre filiation probante (devant les
tribunaux).
En ce qui concerne FreeBSD, ce système d'exploitation n'a rien à voir _du
tout_ avec Minix. En fait, si on parle d' « évolution » (guillemets
indispensables), elle est --très partiellement-- dans l'autre sens, de BSD
vers Minix !
Si on veut faire des études de filiation, il faudrait plutôt citer le livre
de J. Lyons comme référence de départ.
Et effectivement, l'évolution est vertigineuse. Mais l'étude du code de 1976
n'est probablement pas inutile (suivie de celle de 3/4BSD, en particulier en
ce qui concerne la mémoire virtuelle), elle permet d'aquérir un sens de
l'orientation qui permet de comprendre comment s'organise le noyau actuel de
FreeBSD.
De même, étudier le code de Linux 0.12 (par exemple) permet de comprendre
l'organisation principale du système, sans être noyé dans les détails des
améliorations de performances ou de l'indépendance du matériel.
Et je suis persuadé que quelqu'un qui commence par étudier ces « glorieux
ancêtres » peut ensuite aborder beaucoup plus facilement le code actuel.
Bien entendu, le même raisonnement vaut pour les projets similaires, comme
par exemple... le client ftp de 4BSD (dans src/ucb/ftp, environ 50.000
caractères, sans guère de commentaires).
Les projets en source libre existants se sont compliqué avec le temps.
Un "débutant" ne peut pas prendre le train en marche simplement.
Puisque tu en as cité un !
Il existe pourtant un projet de noyau, en « source libre », qui est
suffisament abordable pour être effectivement enseigné. Certes le code
d'aujourd'hui (la version 3 est sortie en 2006, en liaison avec la réédition
du livre évidemment) est plus compliqué qu'il ne l'était en 1988-89, mais la
puissance des outils n'a plus rien à voir, au final il est plus facile de
travailler sur le code actuel que cela ne l'était à l'époque héroïque.
Évidemment, étudier le code du noyau de Minix sans le guide du livre, ou en
moins d'un mois, c'est probablement hors de portée d'un débutant en
programmation.
De la même façon que cela l'était en 1989, d'ailleurs.
On touche là à une différence importante entre un projet « normal » (où il
est effectivement difficile de prendre le train en marche, car rien n'est
fait pour cela), qui va à terme sombrer dans l'oubli lorsque les
développeurs actuels s'en désintéresseront (en fait, lorsque l'utilité
deviendra inférieure au coût de maintenance), et les projets « marquants »,
qui suscitent un mouvement de fond comprenant entre autres une
bibliographie, dont la consultation permet justement de prendre ce fameux
train, et par tant d'abaisser le coût de la maintenance globale du projet
(en augmentant la main-d'½uvre disponible; la force de travail devient moins
chère s'il y a afflux de travailleurs vous diraient les économistes).
En news:f15465$vlo$, Mihamina Rakotomandimby (R12y) va escriure:
Il veut apprendre.
Pascal Bourguignon wrote:
ou pourquoi tu ne pourrais pas lire une implémentation en source libre, pour apprendre comment on fait?
Oui mais non. Si je veux apprendre à faire un kernel, me baser sur le code _actuel_ de FreeBSD ou Linux serait... décourageant.
Certes. (Et inutile, aussi, mais c'est un autre débat.)
Ca aurait été interessant d'en suivre l'évolution depuis Minix, mais on est loin de Minix...
Mouais. Bof.
En ce qui concerne Linux, Linux puise quelques racines éparses dans Minix (par exemple au niveau du format de système de fichiers utilisé pour les disquettes), mais les connexions au niveau du source sont quasiment inexistantes, et ce depuis le tout début. Une rapide recherche sur la toile avec comme mots-clé « Tannenbaum Torvalds » ramène une ample documentation sur le thème. Il y a beaucoup plus de connexions entre Système V et Linux (à travers le livre de Maurice Bach) ; et pourtant le code est différent, au point que SCO n'a jamais réussit à établir la moindre filiation probante (devant les tribunaux).
En ce qui concerne FreeBSD, ce système d'exploitation n'a rien à voir _du tout_ avec Minix. En fait, si on parle d' « évolution » (guillemets indispensables), elle est --très partiellement-- dans l'autre sens, de BSD vers Minix !
Si on veut faire des études de filiation, il faudrait plutôt citer le livre de J. Lyons comme référence de départ. Et effectivement, l'évolution est vertigineuse. Mais l'étude du code de 1976 n'est probablement pas inutile (suivie de celle de 3/4BSD, en particulier en ce qui concerne la mémoire virtuelle), elle permet d'aquérir un sens de l'orientation qui permet de comprendre comment s'organise le noyau actuel de FreeBSD. De même, étudier le code de Linux 0.12 (par exemple) permet de comprendre l'organisation principale du système, sans être noyé dans les détails des améliorations de performances ou de l'indépendance du matériel.
Et je suis persuadé que quelqu'un qui commence par étudier ces « glorieux ancêtres » peut ensuite aborder beaucoup plus facilement le code actuel. Bien entendu, le même raisonnement vaut pour les projets similaires, comme par exemple... le client ftp de 4BSD (dans src/ucb/ftp, environ 50.000 caractères, sans guère de commentaires).
Les projets en source libre existants se sont compliqué avec le temps. Un "débutant" ne peut pas prendre le train en marche simplement.
Puisque tu en as cité un ! Il existe pourtant un projet de noyau, en « source libre », qui est suffisament abordable pour être effectivement enseigné. Certes le code d'aujourd'hui (la version 3 est sortie en 2006, en liaison avec la réédition du livre évidemment) est plus compliqué qu'il ne l'était en 1988-89, mais la puissance des outils n'a plus rien à voir, au final il est plus facile de travailler sur le code actuel que cela ne l'était à l'époque héroïque.
Évidemment, étudier le code du noyau de Minix sans le guide du livre, ou en moins d'un mois, c'est probablement hors de portée d'un débutant en programmation. De la même façon que cela l'était en 1989, d'ailleurs.
On touche là à une différence importante entre un projet « normal » (où il est effectivement difficile de prendre le train en marche, car rien n'est fait pour cela), qui va à terme sombrer dans l'oubli lorsque les développeurs actuels s'en désintéresseront (en fait, lorsque l'utilité deviendra inférieure au coût de maintenance), et les projets « marquants », qui suscitent un mouvement de fond comprenant entre autres une bibliographie, dont la consultation permet justement de prendre ce fameux train, et par tant d'abaisser le coût de la maintenance globale du projet (en augmentant la main-d'½uvre disponible; la force de travail devient moins chère s'il y a afflux de travailleurs vous diraient les économistes).
Antoine
aVrama
aVrama writes:
Bonjour a tous, J'espère que je suis sur le bon newsgroups sinon, excusez-moi de vous parasiter. Je me suis lancé dans le codage en C d'un module permettant de récupérer un fichier via un serveur ftp distant. La ou cela se complique, c'est que je ne veux pas utiliser une librairie toute faite de client ftp, je veux programmer une fonction 'get_fichier_ftp' (simplifiée) en utilisant les sockets (d'une lib tcp/ip). J'arrive à échanger des données via des sockets (socket, listen, bind,...) mais pour me connecter a un serveur et suivre le protocole, c'est une autre histoire. Est-ce que quelqu'un a une piste, une idée, un exemple pour implémenter cette partie du protocole FTP ou est-ce que je dois connaitre la RFC959 par coeur pour pouvoir le faire...
Oui.
La question c'est pourquoi tu ne peux pas utiliser une bibliothèque existante, ou pourquoi tu ne pourrais pas lire une implémentation en source libre, pour apprendre comment on fait?
Bonjour,
Merci pour vos réponses. J'ai trouvé un source 'ftp-client.c'(libre) sur le net. Cela me parait plus facile de le modifier pour mes besoins que de tout réécrire à partir de la RFC959. Encore merci. aVr
aVrama <avrama@free.fr> writes:
Bonjour a tous,
J'espère que je suis sur le bon newsgroups sinon, excusez-moi de vous
parasiter.
Je me suis lancé dans le codage en C d'un module permettant de
récupérer un fichier via un serveur ftp distant. La ou cela se
complique, c'est que je ne veux pas utiliser une librairie toute faite
de client ftp, je veux programmer une fonction 'get_fichier_ftp'
(simplifiée) en utilisant les sockets (d'une lib tcp/ip).
J'arrive à échanger des données via des sockets (socket, listen,
bind,...) mais pour me connecter a un serveur et suivre le protocole,
c'est une autre histoire. Est-ce que quelqu'un a une piste, une idée,
un exemple pour implémenter cette partie du protocole FTP ou est-ce
que je dois connaitre la RFC959 par coeur pour pouvoir le faire...
Oui.
La question c'est pourquoi tu ne peux pas utiliser une bibliothèque
existante, ou pourquoi tu ne pourrais pas lire une implémentation en
source libre, pour apprendre comment on fait?
Bonjour,
Merci pour vos réponses.
J'ai trouvé un source 'ftp-client.c'(libre) sur le net.
Cela me parait plus facile de le modifier pour mes besoins que de tout
réécrire à partir de la RFC959.
Encore merci.
aVr
Bonjour a tous, J'espère que je suis sur le bon newsgroups sinon, excusez-moi de vous parasiter. Je me suis lancé dans le codage en C d'un module permettant de récupérer un fichier via un serveur ftp distant. La ou cela se complique, c'est que je ne veux pas utiliser une librairie toute faite de client ftp, je veux programmer une fonction 'get_fichier_ftp' (simplifiée) en utilisant les sockets (d'une lib tcp/ip). J'arrive à échanger des données via des sockets (socket, listen, bind,...) mais pour me connecter a un serveur et suivre le protocole, c'est une autre histoire. Est-ce que quelqu'un a une piste, une idée, un exemple pour implémenter cette partie du protocole FTP ou est-ce que je dois connaitre la RFC959 par coeur pour pouvoir le faire...
Oui.
La question c'est pourquoi tu ne peux pas utiliser une bibliothèque existante, ou pourquoi tu ne pourrais pas lire une implémentation en source libre, pour apprendre comment on fait?
Bonjour,
Merci pour vos réponses. J'ai trouvé un source 'ftp-client.c'(libre) sur le net. Cela me parait plus facile de le modifier pour mes besoins que de tout réécrire à partir de la RFC959. Encore merci. aVr
