voilà qu'on me dit qu'il n'y a pas que des connexions tcp, dont je suis
chargé du transport, mais aussi de connexions udp !!
est il possible de faire un tunnel ssh pour une connexion udp, comme on
fait pour une connexion tcp ?
ou alors un truc qui permette de mettre de l'udp sur du tcp, qu'on
puisse mettre sur du ssh apres ?
--
si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE
(seulement dans le 1/4 h où mon ordi est mis en veille,
donc je vous invite à réclamer à free : l'acces à arp -s,
ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )
"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"
In article (Dans l'article) <d4qj2e$2p8c$, Nicolas George <nicolas$ wrote (écrivait) :
Bob qui Trolle wrote in message <4270676c$0$31265$:
Je ne connais pas d'unix où il soit possible de définir une interface réseau (donc, un port noyau, donc, system-wide) sans devoir à un moment ou à un autre passer root.
Justement, un tunnel SSH ne demande pas de définir d'interface réseau, uniquement une socket en écoute, et ça ne nécessite à aucun moment de passer root, sauf si on veut choper un port privilégié.
voilà :-) y a rien qui fait comme un tunnel ssh, mais en udp au lieu de tcp ?
-- si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE (seulement dans le 1/4 h où mon ordi est mis en veille, donc je vous invite à réclamer à free : l'acces à arp -s, ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )
"don't put your PC out of the window, put windows out of your PC" "petit Free qui devient grand, gêne les requins blancs"
In article (Dans l'article) <d4qj2e$2p8c$1@biggoron.nerim.net>,
Nicolas George <nicolas$george@salle-s.org> wrote (écrivait) :
Bob qui Trolle wrote in message
<4270676c$0$31265$636a15ce@news.free.fr>:
Je ne connais pas d'unix où il soit possible de définir une interface
réseau (donc, un port noyau, donc, system-wide) sans devoir à un moment
ou à un autre passer root.
Justement, un tunnel SSH ne demande pas de définir d'interface réseau,
uniquement une socket en écoute, et ça ne nécessite à aucun moment de passer
root, sauf si on veut choper un port privilégié.
voilà :-)
y a rien qui fait comme un tunnel ssh, mais en udp au lieu de tcp ?
--
si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE
(seulement dans le 1/4 h où mon ordi est mis en veille,
donc je vous invite à réclamer à free : l'acces à arp -s,
ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )
"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"
In article (Dans l'article) <d4qj2e$2p8c$, Nicolas George <nicolas$ wrote (écrivait) :
Bob qui Trolle wrote in message <4270676c$0$31265$:
Je ne connais pas d'unix où il soit possible de définir une interface réseau (donc, un port noyau, donc, system-wide) sans devoir à un moment ou à un autre passer root.
Justement, un tunnel SSH ne demande pas de définir d'interface réseau, uniquement une socket en écoute, et ça ne nécessite à aucun moment de passer root, sauf si on veut choper un port privilégié.
voilà :-) y a rien qui fait comme un tunnel ssh, mais en udp au lieu de tcp ?
-- si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE (seulement dans le 1/4 h où mon ordi est mis en veille, donc je vous invite à réclamer à free : l'acces à arp -s, ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )
"don't put your PC out of the window, put windows out of your PC" "petit Free qui devient grand, gêne les requins blancs"
Nicolas George
Thomas wrote in message :
y a rien qui fait comme un tunnel ssh, mais en udp au lieu de tcp ?
Comme je l'ai dit quelques messages plus haut, en tout généricité c'est impossible. Sur des protocoles particuliers, faut voir.
Thomas wrote in message
<fantome.forums.tDeContes-7188A9.19083430042005@news16-e.proxad.net>:
y a rien qui fait comme un tunnel ssh, mais en udp au lieu de tcp ?
Comme je l'ai dit quelques messages plus haut, en tout généricité c'est
impossible. Sur des protocoles particuliers, faut voir.
y a rien qui fait comme un tunnel ssh, mais en udp au lieu de tcp ?
Comme je l'ai dit quelques messages plus haut, en tout généricité c'est impossible. Sur des protocoles particuliers, faut voir.
Thomas
In article (Dans l'article) <d4o2vl$1kmp$, Nicolas George <nicolas$ wrote (écrivait) :
Thomas wrote in message :
est il possible de faire un tunnel ssh pour une connexion udp, comme on fait pour une connexion tcp ? ou alors un truc qui permette de mettre de l'udp sur du tcp, qu'on puisse mettre sur du ssh apres ?
En toute généralité, non, à cause du fait qu'UDP est un protocole sans connexion. Si on en sait un peu plus sur le protocole particulier qu'on souhaite faire suivre, il y a probablement moyen de faire des cas particuliers.
UDP est un protocole sans connexion, ca veut dire qu'on ne se connecte pas, on envoie directement les données à une ip et à un port sans savoir si elles arrivent, c'est ca ?
donc, sur l'ordi qui est à un bout du tunnel ssh, on peut ecouter en udp sur ce port, et sur l'ordi qui est à l'autre bout du tunnel, envoyer les données comme en tcp (sauf qu'il n'y a pas de connexion) non ?
-- si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE (seulement dans le 1/4 h où mon ordi est mis en veille, donc je vous invite à réclamer à free : l'acces à arp -s, ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )
"don't put your PC out of the window, put windows out of your PC" "petit Free qui devient grand, gêne les requins blancs"
In article (Dans l'article) <d4o2vl$1kmp$2@biggoron.nerim.net>,
Nicolas George <nicolas$george@salle-s.org> wrote (écrivait) :
Thomas wrote in message
<fantome.forums.tDeContes-3B79FA.14294827042005@news16-e.proxad.net>:
est il possible de faire un tunnel ssh pour une connexion udp, comme on
fait pour une connexion tcp ?
ou alors un truc qui permette de mettre de l'udp sur du tcp, qu'on
puisse mettre sur du ssh apres ?
En toute généralité, non, à cause du fait qu'UDP est un protocole sans
connexion. Si on en sait un peu plus sur le protocole particulier qu'on
souhaite faire suivre, il y a probablement moyen de faire des cas
particuliers.
UDP est un protocole sans connexion, ca veut dire qu'on ne se connecte
pas, on envoie directement les données à une ip et à un port sans savoir
si elles arrivent, c'est ca ?
donc, sur l'ordi qui est à un bout du tunnel ssh, on peut ecouter en udp
sur ce port,
et sur l'ordi qui est à l'autre bout du tunnel, envoyer les données
comme en tcp (sauf qu'il n'y a pas de connexion)
non ?
--
si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE
(seulement dans le 1/4 h où mon ordi est mis en veille,
donc je vous invite à réclamer à free : l'acces à arp -s,
ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )
"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"
In article (Dans l'article) <d4o2vl$1kmp$, Nicolas George <nicolas$ wrote (écrivait) :
Thomas wrote in message :
est il possible de faire un tunnel ssh pour une connexion udp, comme on fait pour une connexion tcp ? ou alors un truc qui permette de mettre de l'udp sur du tcp, qu'on puisse mettre sur du ssh apres ?
En toute généralité, non, à cause du fait qu'UDP est un protocole sans connexion. Si on en sait un peu plus sur le protocole particulier qu'on souhaite faire suivre, il y a probablement moyen de faire des cas particuliers.
UDP est un protocole sans connexion, ca veut dire qu'on ne se connecte pas, on envoie directement les données à une ip et à un port sans savoir si elles arrivent, c'est ca ?
donc, sur l'ordi qui est à un bout du tunnel ssh, on peut ecouter en udp sur ce port, et sur l'ordi qui est à l'autre bout du tunnel, envoyer les données comme en tcp (sauf qu'il n'y a pas de connexion) non ?
-- si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE (seulement dans le 1/4 h où mon ordi est mis en veille, donc je vous invite à réclamer à free : l'acces à arp -s, ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )
"don't put your PC out of the window, put windows out of your PC" "petit Free qui devient grand, gêne les requins blancs"
Nicolas George
Thomas wrote in message :
UDP est un protocole sans connexion, ca veut dire qu'on ne se connecte pas, on envoie directement les données à une ip et à un port sans savoir si elles arrivent, c'est ca ?
C'est ça.
donc, sur l'ordi qui est à un bout du tunnel ssh, on peut ecouter en udp sur ce port, et sur l'ordi qui est à l'autre bout du tunnel, envoyer les données comme en tcp (sauf qu'il n'y a pas de connexion) non ?
Oui, on peut faire ça. Ça marche pour un sens. Mais ensuite, que faire des réponses ? Un processus qui écoute sur une socket UDP reçoit à chaque paquet d'une part les données, d'autre part la paire adresse IP / port de l'expéditeur, et il peut répondre par le même chemin. Si on fait un tunnel, cette adresse de retour est celle du tunnel. Si le tunnel travaille avec une seule socket à l'arrivée, l'adresse de retour est définitivement perdue. Si le tunnel veut pouvoir avoir l'adresse de retour, il doit créer autant de socket à l'arrivée qu'il reçoit lui-même de paquets d'origines différentes, ce qui pose le problème : pendant combien de temps ces socket doivent-elles être gardées ?
Comme il n'y a pas de connexion, il n'y a rien qui dise au tunnel qu'un dialogue est terminé. On peut très bien imaginer un protocole à base de requête-réponse instantanée et unique, avec des requêtes d'énormément de sources différentes : garder la socket ouverte même seulement quelques secondes peut faire exploser le tunnel. D'un autre côté, on peut avoir un serveur qui répond plusieurs paquets, éventuellement avec plusieurs (dizaines de) secondes d'intervale, mais qui au contraire traite en général avec une ou deux sources différentes au plus : si on garde la socket ouverte moins de quelques dizaines de seconde on casse le protocole.
Si on connaît le protocole qu'on veut tunneler, on peut adapter, mais un tunnel qui fonctionne en toute généralité est impossible.
Thomas wrote in message
<fantome.forums.tDeContes-097557.22230330042005@news16-e.proxad.net>:
UDP est un protocole sans connexion, ca veut dire qu'on ne se connecte
pas, on envoie directement les données à une ip et à un port sans savoir
si elles arrivent, c'est ca ?
C'est ça.
donc, sur l'ordi qui est à un bout du tunnel ssh, on peut ecouter en udp
sur ce port,
et sur l'ordi qui est à l'autre bout du tunnel, envoyer les données
comme en tcp (sauf qu'il n'y a pas de connexion)
non ?
Oui, on peut faire ça. Ça marche pour un sens. Mais ensuite, que faire des
réponses ? Un processus qui écoute sur une socket UDP reçoit à chaque paquet
d'une part les données, d'autre part la paire adresse IP / port de
l'expéditeur, et il peut répondre par le même chemin. Si on fait un tunnel,
cette adresse de retour est celle du tunnel. Si le tunnel travaille avec une
seule socket à l'arrivée, l'adresse de retour est définitivement perdue. Si
le tunnel veut pouvoir avoir l'adresse de retour, il doit créer autant de
socket à l'arrivée qu'il reçoit lui-même de paquets d'origines différentes,
ce qui pose le problème : pendant combien de temps ces socket doivent-elles
être gardées ?
Comme il n'y a pas de connexion, il n'y a rien qui dise au tunnel qu'un
dialogue est terminé. On peut très bien imaginer un protocole à base de
requête-réponse instantanée et unique, avec des requêtes d'énormément de
sources différentes : garder la socket ouverte même seulement quelques
secondes peut faire exploser le tunnel. D'un autre côté, on peut avoir un
serveur qui répond plusieurs paquets, éventuellement avec plusieurs
(dizaines de) secondes d'intervale, mais qui au contraire traite en général
avec une ou deux sources différentes au plus : si on garde la socket ouverte
moins de quelques dizaines de seconde on casse le protocole.
Si on connaît le protocole qu'on veut tunneler, on peut adapter, mais un
tunnel qui fonctionne en toute généralité est impossible.
UDP est un protocole sans connexion, ca veut dire qu'on ne se connecte pas, on envoie directement les données à une ip et à un port sans savoir si elles arrivent, c'est ca ?
C'est ça.
donc, sur l'ordi qui est à un bout du tunnel ssh, on peut ecouter en udp sur ce port, et sur l'ordi qui est à l'autre bout du tunnel, envoyer les données comme en tcp (sauf qu'il n'y a pas de connexion) non ?
Oui, on peut faire ça. Ça marche pour un sens. Mais ensuite, que faire des réponses ? Un processus qui écoute sur une socket UDP reçoit à chaque paquet d'une part les données, d'autre part la paire adresse IP / port de l'expéditeur, et il peut répondre par le même chemin. Si on fait un tunnel, cette adresse de retour est celle du tunnel. Si le tunnel travaille avec une seule socket à l'arrivée, l'adresse de retour est définitivement perdue. Si le tunnel veut pouvoir avoir l'adresse de retour, il doit créer autant de socket à l'arrivée qu'il reçoit lui-même de paquets d'origines différentes, ce qui pose le problème : pendant combien de temps ces socket doivent-elles être gardées ?
Comme il n'y a pas de connexion, il n'y a rien qui dise au tunnel qu'un dialogue est terminé. On peut très bien imaginer un protocole à base de requête-réponse instantanée et unique, avec des requêtes d'énormément de sources différentes : garder la socket ouverte même seulement quelques secondes peut faire exploser le tunnel. D'un autre côté, on peut avoir un serveur qui répond plusieurs paquets, éventuellement avec plusieurs (dizaines de) secondes d'intervale, mais qui au contraire traite en général avec une ou deux sources différentes au plus : si on garde la socket ouverte moins de quelques dizaines de seconde on casse le protocole.
Si on connaît le protocole qu'on veut tunneler, on peut adapter, mais un tunnel qui fonctionne en toute généralité est impossible.
manu
Thomas wrote:
UDP est un protocole sans connexion, ca veut dire qu'on ne se connecte pas, on envoie directement les données à une ip et à un port sans savoir si elles arrivent, c'est ca ?
donc, sur l'ordi qui est à un bout du tunnel ssh, on peut ecouter en udp sur ce port, et sur l'ordi qui est à l'autre bout du tunnel, envoyer les données comme en tcp (sauf qu'il n'y a pas de connexion) non ?
A ma connaissance, SSH ne sait faire suivre que du TCP. A moins de faire de l'UDP via PPP sur SSH, on ne peut pas envoyer de l'UDP à travers un tunnel SSH.
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Thomas <fantome.forums.tDeContes@free.fr> wrote:
UDP est un protocole sans connexion, ca veut dire qu'on ne se connecte
pas, on envoie directement les données à une ip et à un port sans savoir
si elles arrivent, c'est ca ?
donc, sur l'ordi qui est à un bout du tunnel ssh, on peut ecouter en udp
sur ce port,
et sur l'ordi qui est à l'autre bout du tunnel, envoyer les données
comme en tcp (sauf qu'il n'y a pas de connexion)
non ?
A ma connaissance, SSH ne sait faire suivre que du TCP. A moins de faire
de l'UDP via PPP sur SSH, on ne peut pas envoyer de l'UDP à travers un
tunnel SSH.
--
Emmanuel Dreyfus
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
UDP est un protocole sans connexion, ca veut dire qu'on ne se connecte pas, on envoie directement les données à une ip et à un port sans savoir si elles arrivent, c'est ca ?
donc, sur l'ordi qui est à un bout du tunnel ssh, on peut ecouter en udp sur ce port, et sur l'ordi qui est à l'autre bout du tunnel, envoyer les données comme en tcp (sauf qu'il n'y a pas de connexion) non ?
A ma connaissance, SSH ne sait faire suivre que du TCP. A moins de faire de l'UDP via PPP sur SSH, on ne peut pas envoyer de l'UDP à travers un tunnel SSH.
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Bob qui Trolle
Khanh-Dang wrote:
Tiens, d'ailleurs, je me demandais s'il existait une couche IP en userland pour Unix ?
Bin ça dépend de ce que tu entends pas userland, mais va voir du côté de GNU/Hurd, il y a des concept très intéressants.
Merci du conseil.
Vu mon niveau (autodidacte, donc faible) sur le sujet, je me suis contenté des FAQ. L'idée qui consiste à rendre le système extensible par le biais de serveurs est séduisante, mais, séparation des prinvilèges mis à part, en quoi cela diffère-t-il d'un noyau monolithique très modulaire ? Comment gérer le coût du context-switching ?
Je comprends aussi que le fait que plusieurs tâches (au sens du processeur) soient simultanément vivantes permettrait éventuellement à l'une d'elles de "dépanner" l'autre... mais alors : où est l'ordonnanceur ? Dans le petit noyau réduit aux tâches essentielles ? N'arrive-t-on pas au même résultat avec des machines virtuelles disposant chacun d'un système monolithique éventuellement très modulaire ?
(Ne pas hésiter à rediriger là où il faut, puisque GNU's not Unix)
Khanh-Dang wrote:
Tiens, d'ailleurs, je me demandais s'il existait une couche IP en
userland pour Unix ?
Bin ça dépend de ce que tu entends pas userland, mais va voir du côté de
GNU/Hurd, il y a des concept très intéressants.
Merci du conseil.
Vu mon niveau (autodidacte, donc faible) sur le sujet, je me suis
contenté des FAQ. L'idée qui consiste à rendre le système extensible par
le biais de serveurs est séduisante, mais, séparation des prinvilèges
mis à part, en quoi cela diffère-t-il d'un noyau monolithique très
modulaire ? Comment gérer le coût du context-switching ?
Je comprends aussi que le fait que plusieurs tâches (au sens du
processeur) soient simultanément vivantes permettrait éventuellement à
l'une d'elles de "dépanner" l'autre... mais alors : où est
l'ordonnanceur ? Dans le petit noyau réduit aux tâches essentielles ?
N'arrive-t-on pas au même résultat avec des machines virtuelles
disposant chacun d'un système monolithique éventuellement très modulaire ?
(Ne pas hésiter à rediriger là où il faut, puisque GNU's not Unix)
Tiens, d'ailleurs, je me demandais s'il existait une couche IP en userland pour Unix ?
Bin ça dépend de ce que tu entends pas userland, mais va voir du côté de GNU/Hurd, il y a des concept très intéressants.
Merci du conseil.
Vu mon niveau (autodidacte, donc faible) sur le sujet, je me suis contenté des FAQ. L'idée qui consiste à rendre le système extensible par le biais de serveurs est séduisante, mais, séparation des prinvilèges mis à part, en quoi cela diffère-t-il d'un noyau monolithique très modulaire ? Comment gérer le coût du context-switching ?
Je comprends aussi que le fait que plusieurs tâches (au sens du processeur) soient simultanément vivantes permettrait éventuellement à l'une d'elles de "dépanner" l'autre... mais alors : où est l'ordonnanceur ? Dans le petit noyau réduit aux tâches essentielles ? N'arrive-t-on pas au même résultat avec des machines virtuelles disposant chacun d'un système monolithique éventuellement très modulaire ?
(Ne pas hésiter à rediriger là où il faut, puisque GNU's not Unix)
Nicolas George
Emmanuel Dreyfus wrote in message <1gvwqjg.fm9aqcxv1e52N%:
A ma connaissance, SSH ne sait faire suivre que du TCP.
Il n'y aurait aucune impossibilité à ajouter des homologues aux options -R et -L de ssh pour de l'UDP, ou, encore plus simple, à écrire un petit programme auxiliaire qui utiliserait un tunnel TCP pour y faire passer ses données.
Sauf que, comme je l'ai expliqué un message plus haut, il n'est pas possible d'obtenir un fonctionnement correct et générique pour une telle option -- ce qui explique certainement que ça n'ait pas été fait.
Emmanuel Dreyfus wrote in message
<1gvwqjg.fm9aqcxv1e52N%manu@netbsd.org>:
A ma connaissance, SSH ne sait faire suivre que du TCP.
Il n'y aurait aucune impossibilité à ajouter des homologues aux options -R
et -L de ssh pour de l'UDP, ou, encore plus simple, à écrire un petit
programme auxiliaire qui utiliserait un tunnel TCP pour y faire passer ses
données.
Sauf que, comme je l'ai expliqué un message plus haut, il n'est pas possible
d'obtenir un fonctionnement correct et générique pour une telle option -- ce
qui explique certainement que ça n'ait pas été fait.
Emmanuel Dreyfus wrote in message <1gvwqjg.fm9aqcxv1e52N%:
A ma connaissance, SSH ne sait faire suivre que du TCP.
Il n'y aurait aucune impossibilité à ajouter des homologues aux options -R et -L de ssh pour de l'UDP, ou, encore plus simple, à écrire un petit programme auxiliaire qui utiliserait un tunnel TCP pour y faire passer ses données.
Sauf que, comme je l'ai expliqué un message plus haut, il n'est pas possible d'obtenir un fonctionnement correct et générique pour une telle option -- ce qui explique certainement que ça n'ait pas été fait.
Nicolas George
Bob qui Trolle wrote in message <42755326$0$8239$:
L'idée qui consiste à rendre le système extensible par le biais de serveurs est séduisante, mais, séparation des prinvilèges mis à part, en quoi cela diffère-t-il d'un noyau monolithique très modulaire ?
C'est une question d'élégance de l'organisation, justement, de propreté et de simplicité de l'organisation. Par exemple, avec un système à micro-noyau, débugger un nouveau filesystem serait aussi simple que lancer gdb sur le serveur : on garde la difficulté intrinsèque du programme, mais on évacue toute la difficulté qu'il y a à travailler en mode noyau.
Comment gérer le coût du context-switching ?
C'est le gros problème des micro-noyaux.
Je suppose que *LA* référence sur ce sujet, c'est _Operatings Systems, Design and implementation_ de Tannenbaum et Woodhull, mais je n'en suis encore qu'aux premiers chapitres, donc je ne peux pas dire.
Bob qui Trolle wrote in message
<42755326$0$8239$636a15ce@news.free.fr>:
L'idée qui consiste à rendre le système extensible par
le biais de serveurs est séduisante, mais, séparation des prinvilèges
mis à part, en quoi cela diffère-t-il d'un noyau monolithique très
modulaire ?
C'est une question d'élégance de l'organisation, justement, de propreté et
de simplicité de l'organisation. Par exemple, avec un système à micro-noyau,
débugger un nouveau filesystem serait aussi simple que lancer gdb sur le
serveur : on garde la difficulté intrinsèque du programme, mais on évacue
toute la difficulté qu'il y a à travailler en mode noyau.
Comment gérer le coût du context-switching ?
C'est le gros problème des micro-noyaux.
Je suppose que *LA* référence sur ce sujet, c'est _Operatings Systems,
Design and implementation_ de Tannenbaum et Woodhull, mais je n'en suis
encore qu'aux premiers chapitres, donc je ne peux pas dire.
Bob qui Trolle wrote in message <42755326$0$8239$:
L'idée qui consiste à rendre le système extensible par le biais de serveurs est séduisante, mais, séparation des prinvilèges mis à part, en quoi cela diffère-t-il d'un noyau monolithique très modulaire ?
C'est une question d'élégance de l'organisation, justement, de propreté et de simplicité de l'organisation. Par exemple, avec un système à micro-noyau, débugger un nouveau filesystem serait aussi simple que lancer gdb sur le serveur : on garde la difficulté intrinsèque du programme, mais on évacue toute la difficulté qu'il y a à travailler en mode noyau.
Comment gérer le coût du context-switching ?
C'est le gros problème des micro-noyaux.
Je suppose que *LA* référence sur ce sujet, c'est _Operatings Systems, Design and implementation_ de Tannenbaum et Woodhull, mais je n'en suis encore qu'aux premiers chapitres, donc je ne peux pas dire.
Thomas
In article (Dans l'article) <d53s74$jgr$, Nicolas George <nicolas$ wrote (écrivait) :
Emmanuel Dreyfus wrote in message <1gvwqjg.fm9aqcxv1e52N%:
A ma connaissance, SSH ne sait faire suivre que du TCP.
Il n'y aurait aucune impossibilité à ajouter des homologues aux options -R et -L de ssh pour de l'UDP, ou, encore plus simple,
à écrire un petit programme auxiliaire qui utiliserait un tunnel TCP pour y faire passer ses données.
c'est ca que je compte faire :-)
Sauf que, comme je l'ai expliqué un message plus haut, il n'est pas possible d'obtenir un fonctionnement correct et générique pour une telle option -- ce qui explique certainement que ça n'ait pas été fait.
merci pour toutes les explications :-) je connais pas le protocole, mais il y a 1 seul client en tout, deja :-)
(pendant que j'y suis, y aurais personne ici qui connaitrait le "module adam-4570" par hasard ?
-- si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE (seulement dans le 1/4 h où mon ordi est mis en veille, donc je vous invite à réclamer à free : l'acces à arp -s, ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )
"don't put your PC out of the window, put windows out of your PC" "petit Free qui devient grand, gêne les requins blancs"
In article (Dans l'article) <d53s74$jgr$1@biggoron.nerim.net>,
Nicolas George <nicolas$george@salle-s.org> wrote (écrivait) :
Emmanuel Dreyfus wrote in message
<1gvwqjg.fm9aqcxv1e52N%manu@netbsd.org>:
A ma connaissance, SSH ne sait faire suivre que du TCP.
Il n'y aurait aucune impossibilité à ajouter des homologues aux options -R
et -L de ssh pour de l'UDP, ou, encore plus simple,
à écrire un petit
programme auxiliaire qui utiliserait un tunnel TCP pour y faire passer ses
données.
c'est ca que je compte faire :-)
Sauf que, comme je l'ai expliqué un message plus haut, il n'est pas possible
d'obtenir un fonctionnement correct et générique pour une telle option -- ce
qui explique certainement que ça n'ait pas été fait.
merci pour toutes les explications :-)
je connais pas le protocole, mais il y a 1 seul client en tout, deja :-)
(pendant que j'y suis, y aurais personne ici qui connaitrait le "module
adam-4570" par hasard ?
--
si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE
(seulement dans le 1/4 h où mon ordi est mis en veille,
donc je vous invite à réclamer à free : l'acces à arp -s,
ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )
"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"
In article (Dans l'article) <d53s74$jgr$, Nicolas George <nicolas$ wrote (écrivait) :
Emmanuel Dreyfus wrote in message <1gvwqjg.fm9aqcxv1e52N%:
A ma connaissance, SSH ne sait faire suivre que du TCP.
Il n'y aurait aucune impossibilité à ajouter des homologues aux options -R et -L de ssh pour de l'UDP, ou, encore plus simple,
à écrire un petit programme auxiliaire qui utiliserait un tunnel TCP pour y faire passer ses données.
c'est ca que je compte faire :-)
Sauf que, comme je l'ai expliqué un message plus haut, il n'est pas possible d'obtenir un fonctionnement correct et générique pour une telle option -- ce qui explique certainement que ça n'ait pas été fait.
merci pour toutes les explications :-) je connais pas le protocole, mais il y a 1 seul client en tout, deja :-)
(pendant que j'y suis, y aurais personne ici qui connaitrait le "module adam-4570" par hasard ?
-- si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE (seulement dans le 1/4 h où mon ordi est mis en veille, donc je vous invite à réclamer à free : l'acces à arp -s, ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )
"don't put your PC out of the window, put windows out of your PC" "petit Free qui devient grand, gêne les requins blancs"
Nicolas George
Thomas wrote in message :
je connais pas le protocole, mais il y a 1 seul client en tout, deja :-)
Ah, dans ce cas, ça devrait être une simple formalité à écrire. Bon courage.
Thomas wrote in message
<fantome.forums.tDeContes-7DFBB7.22144502052005@news16-e.proxad.net>:
je connais pas le protocole, mais il y a 1 seul client en tout, deja :-)
Ah, dans ce cas, ça devrait être une simple formalité à écrire. Bon courage.
