Bonjour, dans le cadre de mes études je suis en train de potasser un
bouquin "TCP/IP" (MacMillan).
C'est super intéressant mais il me manque un point d'accroche. J'ai besoin
de déterminer avec précision quelles couches sont concernées (englobées ?)
par certains protocoles.
Par exemple, PPP (et ses dérivés PPPoE, PPPoA, et d'autres surement).
J'ai du mal à déterminer à quel niveau ils se situent.
Ce que je cherche (on y arrive) : un site web expliquant clairement à quel
niveau de la norme ISO se situe tel ou tel protocole.
Idem pour SLIP, CSLIP, PPTP, etc etc... J'ai vraiment du mal à les situer.
Contrairement à des protocoles de "haut niveau" comme ftp,smtp,telnet...
Je pourrais aussi citer ssh... Le forwarding de ports en ssh me trouble.
Dans le cas de ssh, ou se situe-t-il ? Par exemple, on peut imaginer une
session pop3 au travers d'un tunnel ssh... Donc ssh jouerait sur les
couches inférieures (puisque c'est totalement transparent pour le client
pop3)...
Etc etc j'en ai plein d'autres
Je ré-itère (suis confu ce soit, j'ai un peu arrosé un repas ;)) : un site
mettant en relation les protocoles les plus courants et leur position dans
l'architecture OSI.
Elle m'a bien fait sourire votre discussion. En fait, dès que tu encapsules une service, tu peux te recréer un morceaux que pile OSI à côté et recommencer.
C'est un peu pour ca que je parlais je ne sais plus ou de macro-couches contenant chacune un modele OSI pour concilier le point de vue de pierre et le mien.
En fait je me suis un poil planté, ces macro-couches etant imbriquees les unes dans les autres et non pas a la suite.
Et tout de suite, comme ça, je trouve que ça devient plus clair. La couche OSI définit des _services_, pas un modèle d'encapsulation à suivre.
Je n'ai jamais dit le contraire : encapsuler pour encapsuler, ca sert un peu a rien... Le truc c'est que de base OSI contient tous les services dont on a besoin et ne prevoit pas, sauf si je dis vraiment une grosse betise, d'encapsuler des services de couches inferieures dans les couches superieures. Les autres modeles non plus d'ailleurs.
Donc soit on cree un modele concret pour definir formellement ces couches qui se repetent, soient on en reste a des speculations et des arrangements personnalisé du modele OSI ou autre.
Elle m'a bien fait sourire votre discussion.
En fait, dès que tu encapsules une service, tu peux te recréer un
morceaux que pile OSI à côté et recommencer.
C'est un peu pour ca que je parlais je ne sais plus ou de
macro-couches contenant chacune un modele OSI pour concilier le point
de vue de pierre et le mien.
En fait je me suis un poil planté, ces macro-couches etant imbriquees
les unes dans les autres et non pas a la suite.
Et tout de suite, comme ça, je trouve que ça devient plus clair. La
couche OSI définit des _services_, pas un modèle d'encapsulation à
suivre.
Je n'ai jamais dit le contraire : encapsuler pour encapsuler, ca
sert un peu a rien...
Le truc c'est que de base OSI contient tous les services dont on a
besoin et ne prevoit pas, sauf si je dis vraiment une grosse betise,
d'encapsuler des services de couches inferieures dans les couches
superieures. Les autres modeles non plus d'ailleurs.
Donc soit on cree un modele concret pour definir formellement ces
couches qui se repetent, soient on en reste a des speculations et des
arrangements personnalisé du modele OSI ou autre.
Elle m'a bien fait sourire votre discussion. En fait, dès que tu encapsules une service, tu peux te recréer un morceaux que pile OSI à côté et recommencer.
C'est un peu pour ca que je parlais je ne sais plus ou de macro-couches contenant chacune un modele OSI pour concilier le point de vue de pierre et le mien.
En fait je me suis un poil planté, ces macro-couches etant imbriquees les unes dans les autres et non pas a la suite.
Et tout de suite, comme ça, je trouve que ça devient plus clair. La couche OSI définit des _services_, pas un modèle d'encapsulation à suivre.
Je n'ai jamais dit le contraire : encapsuler pour encapsuler, ca sert un peu a rien... Le truc c'est que de base OSI contient tous les services dont on a besoin et ne prevoit pas, sauf si je dis vraiment une grosse betise, d'encapsuler des services de couches inferieures dans les couches superieures. Les autres modeles non plus d'ailleurs.
Donc soit on cree un modele concret pour definir formellement ces couches qui se repetent, soient on en reste a des speculations et des arrangements personnalisé du modele OSI ou autre.
Non ?
Vincent Hiribarren
"Annie D." writes:
Ah ben oui, tiens. J'avais oublié de préciser que la connexion SSH passait aussi par un proxy SOCKS. Quand on y pense, des fois, Usenet, c'est vachement compliqué.
M'en parlez pas. Heureusement que Free permet une connexion par le port 434, mon port 119 me donne acces seulement a un serveur boiteux.
"Annie D." <annie.demur@free.fr> writes:
Ah ben oui, tiens. J'avais oublié de préciser que la connexion SSH
passait aussi par un proxy SOCKS. Quand on y pense, des fois, Usenet,
c'est vachement compliqué.
M'en parlez pas. Heureusement que Free permet une connexion par le
port 434, mon port 119 me donne acces seulement a un serveur boiteux.
Ah ben oui, tiens. J'avais oublié de préciser que la connexion SSH passait aussi par un proxy SOCKS. Quand on y pense, des fois, Usenet, c'est vachement compliqué.
M'en parlez pas. Heureusement que Free permet une connexion par le port 434, mon port 119 me donne acces seulement a un serveur boiteux.
Vincent Hiribarren
"Annie D." writes:
Je vois Ethernet. Je vois IP. Je vois TCP. Je vois SSH.
Alors c'est que vous êtes un câble RJ45, ou une carte ethernet ;o)
Moui. J'aurai mieux du dire : "je deviens ethernet, je deviens..."
SSH est la destination, le paquet est traité par le serveur ou le client car c'est la destination finale du paquet sur un poste informatique apres passage par le reseau. SSH elabore un nouveau paquet a renvoyer sur le reseau, un nouveau cycle recommence.
Non, SSH, comme toute application basée sur TCP ne traite pas de paquets mais un flux d'octets. C'est la couche TCP qui découpe ce flux en paquets.
Ah oui tiens. Mais ca ne change rien a la fin : flux ou pas, on recupere ce paquet, hop dans un buffer, on balance ca a un socket et le tour est joue.
Voyez, par exemple, le cheminement de mes paquets IP entre mon FAI et mon PC:
[Snip]
Oui, mais c'est ce que je disais, ou alors me suis tres mal exprime. Vous disiez qu'un paquet montait ou descendait dans son voyage. Et moi que lorsqu'il arrivait a "destination", un nouveau paquet est issu pour un nouveau periple sur le reseau.
En fait c'est pareil. A un instant t mon paquet ssh n'est rien d'autre qu'un protocole de couche 5-6-7. A partir d'une autre station qui a recu et traite le paquet, c'est devenu un protocole de niveau 4.
Bon maintenant, hein, soit on se place comme vous et moi (si j'ai bien compris) en se mettant d'un point de vue global et alors il faut considerer le service qui contient un service de couche inferieure pour pouvoir donner un numero a cette couche (du ssh sur du tcp ? ssh couche 5-6-7 ; quand il sera traité dans un noeud du reseau on lui donnera un autre numero de couche) ; ou alors on va jusqu'au bout et on dit que la couche 4 contient du 3 qui contient du 4 qui contient du 2 qui contient du... a un instant t.
Et la je trouve qu'on s'y perd.
"Annie D." <annie.demur@free.fr> writes:
Je vois Ethernet.
Je vois IP.
Je vois TCP.
Je vois SSH.
Alors c'est que vous êtes un câble RJ45, ou une carte ethernet ;o)
Moui. J'aurai mieux du dire : "je deviens ethernet, je deviens..."
SSH est la destination, le paquet est traité par le serveur ou le
client car c'est la destination finale du paquet sur un poste
informatique apres passage par le reseau. SSH elabore un nouveau
paquet a renvoyer sur le reseau, un nouveau cycle recommence.
Non, SSH, comme toute application basée sur TCP ne traite pas de paquets
mais un flux d'octets. C'est la couche TCP qui découpe ce flux en
paquets.
Ah oui tiens.
Mais ca ne change rien a la fin : flux ou pas, on recupere ce paquet,
hop dans un buffer, on balance ca a un socket et le tour est joue.
Voyez, par exemple, le cheminement de mes paquets IP entre mon FAI et
mon PC:
[Snip]
Oui, mais c'est ce que je disais, ou alors me suis tres mal exprime.
Vous disiez qu'un paquet montait ou descendait dans son voyage.
Et moi que lorsqu'il arrivait a "destination", un nouveau paquet est
issu pour un nouveau periple sur le reseau.
En fait c'est pareil.
A un instant t mon paquet ssh n'est rien d'autre qu'un protocole de
couche 5-6-7. A partir d'une autre station qui a recu et traite le
paquet, c'est devenu un protocole de niveau 4.
Bon maintenant, hein, soit on se place comme vous et moi (si j'ai bien
compris) en se mettant d'un point de vue global et alors il faut
considerer le service qui contient un service de couche inferieure
pour pouvoir donner un numero a cette couche (du ssh sur du tcp ? ssh
couche 5-6-7 ; quand il sera traité dans un noeud du reseau on lui
donnera un autre numero de couche) ; ou alors on va jusqu'au bout et
on dit que la couche 4 contient du 3 qui contient du 4 qui contient du
2 qui contient du... a un instant t.
Je vois Ethernet. Je vois IP. Je vois TCP. Je vois SSH.
Alors c'est que vous êtes un câble RJ45, ou une carte ethernet ;o)
Moui. J'aurai mieux du dire : "je deviens ethernet, je deviens..."
SSH est la destination, le paquet est traité par le serveur ou le client car c'est la destination finale du paquet sur un poste informatique apres passage par le reseau. SSH elabore un nouveau paquet a renvoyer sur le reseau, un nouveau cycle recommence.
Non, SSH, comme toute application basée sur TCP ne traite pas de paquets mais un flux d'octets. C'est la couche TCP qui découpe ce flux en paquets.
Ah oui tiens. Mais ca ne change rien a la fin : flux ou pas, on recupere ce paquet, hop dans un buffer, on balance ca a un socket et le tour est joue.
Voyez, par exemple, le cheminement de mes paquets IP entre mon FAI et mon PC:
[Snip]
Oui, mais c'est ce que je disais, ou alors me suis tres mal exprime. Vous disiez qu'un paquet montait ou descendait dans son voyage. Et moi que lorsqu'il arrivait a "destination", un nouveau paquet est issu pour un nouveau periple sur le reseau.
En fait c'est pareil. A un instant t mon paquet ssh n'est rien d'autre qu'un protocole de couche 5-6-7. A partir d'une autre station qui a recu et traite le paquet, c'est devenu un protocole de niveau 4.
Bon maintenant, hein, soit on se place comme vous et moi (si j'ai bien compris) en se mettant d'un point de vue global et alors il faut considerer le service qui contient un service de couche inferieure pour pouvoir donner un numero a cette couche (du ssh sur du tcp ? ssh couche 5-6-7 ; quand il sera traité dans un noeud du reseau on lui donnera un autre numero de couche) ; ou alors on va jusqu'au bout et on dit que la couche 4 contient du 3 qui contient du 4 qui contient du 2 qui contient du... a un instant t.
Et la je trouve qu'on s'y perd.
Annie D.
ATM Adaptation Layer 5, donc couche 5
Non non non.
J'ai dit une bêtise ?
AAL5 != couche 5 Alors deja on est dans le modele ATM, couche 3 ATM pour AAL.
On peut utiliser *a la place* de AAL5 du AAL1, AAL2, 3 ou 4. On reparti les protocoles suivant certains criteres, et on utilise un type de couche ou un autre en fonction de ca, mais on a pas du AAL5 sur du AAL4, ca n'a rien a voir.
J'ai dit une bêtise. Merci d'avoir corrigé et expliqué. Je me disais aussi, elles font quoi les 4 couches en-dessous ?
PS: je poste cet article à travers une connexion NNTP sur TCP relayée par SSH passant par un accès ADSL avec PPPoE ;o)
Rah. J'ai que des trames tcp encapsulees dans le protole socks transporte par du tcp/ip sur de l'ethernet. Je me sens tout petit.
Ah ben oui, tiens. J'avais oublié de préciser que la connexion SSH passait aussi par un proxy SOCKS. Quand on y pense, des fois, Usenet, c'est vachement compliqué.
ATM Adaptation Layer 5, donc couche 5
Non non non.
J'ai dit une bêtise ?
AAL5 != couche 5
Alors deja on est dans le modele ATM, couche 3 ATM pour AAL.
On peut utiliser *a la place* de AAL5 du AAL1, AAL2, 3 ou 4.
On reparti les protocoles suivant certains criteres, et on utilise un
type de couche ou un autre en fonction de ca, mais on a pas du AAL5
sur du AAL4, ca n'a rien a voir.
J'ai dit une bêtise. Merci d'avoir corrigé et expliqué. Je me disais
aussi, elles font quoi les 4 couches en-dessous ?
PS: je poste cet article à travers une connexion NNTP sur TCP relayée
par SSH passant par un accès ADSL avec PPPoE ;o)
Rah. J'ai que des trames tcp encapsulees dans le protole socks
transporte par du tcp/ip sur de l'ethernet. Je me sens tout petit.
Ah ben oui, tiens. J'avais oublié de préciser que la connexion SSH
passait aussi par un proxy SOCKS. Quand on y pense, des fois, Usenet,
c'est vachement compliqué.
AAL5 != couche 5 Alors deja on est dans le modele ATM, couche 3 ATM pour AAL.
On peut utiliser *a la place* de AAL5 du AAL1, AAL2, 3 ou 4. On reparti les protocoles suivant certains criteres, et on utilise un type de couche ou un autre en fonction de ca, mais on a pas du AAL5 sur du AAL4, ca n'a rien a voir.
J'ai dit une bêtise. Merci d'avoir corrigé et expliqué. Je me disais aussi, elles font quoi les 4 couches en-dessous ?
PS: je poste cet article à travers une connexion NNTP sur TCP relayée par SSH passant par un accès ADSL avec PPPoE ;o)
Rah. J'ai que des trames tcp encapsulees dans le protole socks transporte par du tcp/ip sur de l'ethernet. Je me sens tout petit.
Ah ben oui, tiens. J'avais oublié de préciser que la connexion SSH passait aussi par un proxy SOCKS. Quand on y pense, des fois, Usenet, c'est vachement compliqué.
Vincent Hiribarren
Pierre LALET writes:
On monte dans les couches. On ne stagne pas.
Hein ? Mais **pourquoi** ? pourquoi le fait qu'au lieu d'avoir une ligne physique, tu aies un protocole réseau d'empêche de voir le reste ? [Snip]
Je repose la même question.
C'est ptet la fatigue mais je ne comprends pas ta question vis a vis de ce que j'ai mis, alors peut-etre que ma reponse faite a Annie (meme enfilade, ma reponse a sa reponse a l'article auquel tu as repondu, flemme chercher le m-id) fera l'affaire, j'espere.
[Snip]
C'est très simple. Tu dois étudier une couche sans regarder ce qu'il y a en dessous, ni au dessus. Simplement ce qu'elle fait, ce qu'elle utilise (de la couche en dessous) et ce qu'elle propose (à la couche au dessus).
'tend, dois y avoir une mesentente du a moi alors. Oui on peut dire que telle couche se rapproche de telles fonctionnalites de telle couche OSI, bien sur. Mais a condition de ne pas essayer ensuite de la caser dans un modele OSI global, avec les autres couches environnants la couche etudiee. On est d'accord ?
Pierre LALET <lalet@enseirb.fr> writes:
On monte dans les couches. On ne stagne pas.
Hein ? Mais **pourquoi** ? pourquoi le fait qu'au lieu d'avoir une
ligne physique, tu aies un protocole réseau d'empêche de voir le reste
?
[Snip]
Je repose la même question.
C'est ptet la fatigue mais je ne comprends pas ta question vis a vis
de ce que j'ai mis, alors peut-etre que ma reponse faite a Annie (meme
enfilade, ma reponse a sa reponse a l'article auquel tu as repondu,
flemme chercher le m-id) fera l'affaire, j'espere.
[Snip]
C'est très simple. Tu dois étudier une couche sans regarder ce qu'il y
a en dessous, ni au dessus. Simplement ce qu'elle fait, ce qu'elle
utilise (de la couche en dessous) et ce qu'elle propose (à la couche
au dessus).
'tend, dois y avoir une mesentente du a moi alors.
Oui on peut dire que telle couche se rapproche de telles
fonctionnalites de telle couche OSI, bien sur.
Mais a condition de ne pas essayer ensuite de la caser dans un modele
OSI global, avec les autres couches environnants la couche etudiee.
On est d'accord ?
Hein ? Mais **pourquoi** ? pourquoi le fait qu'au lieu d'avoir une ligne physique, tu aies un protocole réseau d'empêche de voir le reste ? [Snip]
Je repose la même question.
C'est ptet la fatigue mais je ne comprends pas ta question vis a vis de ce que j'ai mis, alors peut-etre que ma reponse faite a Annie (meme enfilade, ma reponse a sa reponse a l'article auquel tu as repondu, flemme chercher le m-id) fera l'affaire, j'espere.
[Snip]
C'est très simple. Tu dois étudier une couche sans regarder ce qu'il y a en dessous, ni au dessus. Simplement ce qu'elle fait, ce qu'elle utilise (de la couche en dessous) et ce qu'elle propose (à la couche au dessus).
'tend, dois y avoir une mesentente du a moi alors. Oui on peut dire que telle couche se rapproche de telles fonctionnalites de telle couche OSI, bien sur. Mais a condition de ne pas essayer ensuite de la caser dans un modele OSI global, avec les autres couches environnants la couche etudiee. On est d'accord ?
Fontaine.Sebastien
"Pierre LALET" a écrit dans le message de news: bku7io$5fd$
TCP est classiquement considéré comme de couche 4 dans le modèle OSI.
Biensur
Or, ssh 'transporte' le TCP, donc fournit, à mon sens, un service de niveau 3.
Je ne parlais pas de SSH, mais du fowarding de port. Qui, ce trouve non pas en 4 comme le spécifié Vincent mais en 5.
Sebastien Fontaine
"Pierre LALET" <lalet@enseirb.fr> a écrit dans le message de news:
bku7io$5fd$2@news.u-bordeaux.fr...
TCP est classiquement considéré comme de couche 4 dans le modèle OSI.
Biensur
Or, ssh 'transporte' le TCP, donc fournit, à mon sens, un service de
niveau 3.
Je ne parlais pas de SSH, mais du fowarding de port. Qui, ce trouve non pas
en 4 comme le spécifié Vincent mais en 5.
"Vincent Hiribarren" a écrit dans le message de news:
Zouplaz writes:
C'est quasimment ca. Les couches 3 et 4 peuvent aussi etre implantes dans l'espace utilisateur.
Exacte, mais pour une partie seulement de la couche 3, car certaine option reste du monde admin tel que : - Source IP - Checksum - Lenght
Sebastien Fontaine
Cedric Blancher
Dans sa prose, Vincent Hiribarren nous ecrivait :
Je n'ai jamais dit le contraire : encapsuler pour encapsuler, ca sert un peu a rien...
Je ne critique pas ton discours en particulier, mais la discussion en général. Quant à la redirection de port SSH...
Le truc c'est que de base OSI contient tous les services dont on a besoin et ne prevoit pas, sauf si je dis vraiment une grosse betise, d'encapsuler des services de couches inferieures dans les couches superieures.
Surtout parce qu'il n'a pas à le faire. Si on a envie d'encapsuler, c'est parce que les liaisons dont on dispose ne nous ne fournissent pas des services qui sortent du cadre de ce modèle, comme la sécurité (VPN par exemple), ou ne fournissent pas les terminaisons dont on a besoin (tunneling en général). De fait, en encapsulant, on définit à mon sens de nouveaux éléments de topologie qui viendront se caler plus bas de les couches OSI parce que c'est comme cela qu'on va les utiliser.
Chaque lien dont on dispose doit amha être mappé sur une pile OSI propre dans la mesure où les liens peuvent être de nature différente.
Si je définis un lien PPP sur SSL entre deux points, c'est parce qu'il me manque un lien de niveau 2 entre ces deux points, et que je dois le créer de manière logique. Si on considère ce lien comme les autres, il s'intègre parfaitement dans le modèle OSI, mais ne devrait pas être considéré dans la même pile que le lien qui lui sert de support. D'où le schéma précédemment posté.
-- D'abord, on est sur le web, pas sur ce usenet dont on nous rabbache les oreilles et qui n'est qu'une abstraction. -+- JP in http://neuneu.ctw.cc - Neuneu en abstract mode -+-
Dans sa prose, Vincent Hiribarren nous ecrivait :
Je n'ai jamais dit le contraire : encapsuler pour encapsuler, ca sert un
peu a rien...
Je ne critique pas ton discours en particulier, mais la discussion en
général. Quant à la redirection de port SSH...
Le truc c'est que de base OSI contient tous les services dont on a besoin
et ne prevoit pas, sauf si je dis vraiment une grosse betise, d'encapsuler
des services de couches inferieures dans les couches superieures.
Surtout parce qu'il n'a pas à le faire. Si on a envie d'encapsuler, c'est
parce que les liaisons dont on dispose ne nous ne fournissent pas des
services qui sortent du cadre de ce modèle, comme la sécurité (VPN par
exemple), ou ne fournissent pas les terminaisons dont on a besoin
(tunneling en général). De fait, en encapsulant, on définit à mon sens
de nouveaux éléments de topologie qui viendront se caler plus bas de les
couches OSI parce que c'est comme cela qu'on va les utiliser.
Chaque lien dont on dispose doit amha être mappé sur une pile OSI propre
dans la mesure où les liens peuvent être de nature différente.
Si je définis un lien PPP sur SSL entre deux points, c'est parce qu'il me
manque un lien de niveau 2 entre ces deux points, et que je dois le créer
de manière logique. Si on considère ce lien comme les autres, il
s'intègre parfaitement dans le modèle OSI, mais ne devrait pas être
considéré dans la même pile que le lien qui lui sert de support. D'où
le schéma précédemment posté.
--
D'abord, on est sur le web, pas sur ce usenet dont on nous rabbache les
oreilles et qui n'est qu'une abstraction.
-+- JP in http://neuneu.ctw.cc - Neuneu en abstract mode -+-
Je n'ai jamais dit le contraire : encapsuler pour encapsuler, ca sert un peu a rien...
Je ne critique pas ton discours en particulier, mais la discussion en général. Quant à la redirection de port SSH...
Le truc c'est que de base OSI contient tous les services dont on a besoin et ne prevoit pas, sauf si je dis vraiment une grosse betise, d'encapsuler des services de couches inferieures dans les couches superieures.
Surtout parce qu'il n'a pas à le faire. Si on a envie d'encapsuler, c'est parce que les liaisons dont on dispose ne nous ne fournissent pas des services qui sortent du cadre de ce modèle, comme la sécurité (VPN par exemple), ou ne fournissent pas les terminaisons dont on a besoin (tunneling en général). De fait, en encapsulant, on définit à mon sens de nouveaux éléments de topologie qui viendront se caler plus bas de les couches OSI parce que c'est comme cela qu'on va les utiliser.
Chaque lien dont on dispose doit amha être mappé sur une pile OSI propre dans la mesure où les liens peuvent être de nature différente.
Si je définis un lien PPP sur SSL entre deux points, c'est parce qu'il me manque un lien de niveau 2 entre ces deux points, et que je dois le créer de manière logique. Si on considère ce lien comme les autres, il s'intègre parfaitement dans le modèle OSI, mais ne devrait pas être considéré dans la même pile que le lien qui lui sert de support. D'où le schéma précédemment posté.
-- D'abord, on est sur le web, pas sur ce usenet dont on nous rabbache les oreilles et qui n'est qu'une abstraction. -+- JP in http://neuneu.ctw.cc - Neuneu en abstract mode -+-
Pierre LALET
M'en parlez pas. Heureusement que Free permet une connexion par le port 434, mon port 119 me donne acces seulement a un serveur boiteux.
Il est très bien news.u-bordeaux.fr (news.u-bordeaux1.fr maintenant, je crois).
Et puis le filtrage du port 119 vers l'extérieur est mis pour empêcher l'accès aux news extérieurs ; donc ce que tu fais est, bien que possible, mal(tm).
pierre
-- Pierre LALET -- http://www.enseirb.fr/~lalet Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
M'en parlez pas. Heureusement que Free permet une connexion par le
port 434, mon port 119 me donne acces seulement a un serveur boiteux.
Il est très bien news.u-bordeaux.fr (news.u-bordeaux1.fr maintenant, je
crois).
Et puis le filtrage du port 119 vers l'extérieur est mis pour empêcher
l'accès aux news extérieurs ; donc ce que tu fais est, bien que
possible, mal(tm).
pierre
--
Pierre LALET
lalet@enseirb.fr -- http://www.enseirb.fr/~lalet
Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc
Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
M'en parlez pas. Heureusement que Free permet une connexion par le port 434, mon port 119 me donne acces seulement a un serveur boiteux.
Il est très bien news.u-bordeaux.fr (news.u-bordeaux1.fr maintenant, je crois).
Et puis le filtrage du port 119 vers l'extérieur est mis pour empêcher l'accès aux news extérieurs ; donc ce que tu fais est, bien que possible, mal(tm).
pierre
-- Pierre LALET -- http://www.enseirb.fr/~lalet Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
Pierre LALET
La couche 4 du modèle OSI c'est tcp/udp. Dans ma ptite tête j'imagine l'ensemble des couches comme une sorte d'API, chaque couche de bas niveau proposant des fonctions aux couches supérieures. Normalement les couches de bas niveau (2 à 4) sont implémentées dans le système d'exploitation et les 5,6,7 dans l'application.
Normalement... mais pas toujours (cf serveur http de Linux).
pierre
-- Pierre LALET -- http://www.enseirb.fr/~lalet Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
La couche 4 du modèle OSI c'est tcp/udp. Dans ma ptite tête j'imagine
l'ensemble des couches comme une sorte d'API, chaque couche de bas niveau
proposant des fonctions aux couches supérieures. Normalement les couches de
bas niveau (2 à 4) sont implémentées dans le système d'exploitation et les
5,6,7 dans l'application.
Normalement... mais pas toujours (cf serveur http de Linux).
pierre
--
Pierre LALET
lalet@enseirb.fr -- http://www.enseirb.fr/~lalet
Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc
Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
La couche 4 du modèle OSI c'est tcp/udp. Dans ma ptite tête j'imagine l'ensemble des couches comme une sorte d'API, chaque couche de bas niveau proposant des fonctions aux couches supérieures. Normalement les couches de bas niveau (2 à 4) sont implémentées dans le système d'exploitation et les 5,6,7 dans l'application.
Normalement... mais pas toujours (cf serveur http de Linux).
pierre
-- Pierre LALET -- http://www.enseirb.fr/~lalet Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
