Je bute assez souvent sur les termes de serveur et client.
Dans ce qui suit, j'essaie de peser mes mots, car je crois que de nombreux
textes sont assez approximatifs sur ces sujets.
Un numéro de port est un point d'accès à un processus qui utilise
directement la couche transport pour transmettre ses données. Le processus
est encore appelé service utilisateur (dans le sens utilisateur de la couche
transport).
Point (1) : le service peut être de couche applicative (cas le plus
courant), mais pas seulement : il peut être aussi de couche transport (TPKT
pour le transport de couches ISO sur TCP, RTP pour le transport de données
temps réel sur UDP), et aussi de maintenance de couche transport (écho,
discard, traceroute, etc...).
(2) Le service peut être une application cliente ou une application serveur
(avez-vous remarquer que l'on dit plus difficilement application serveuse,
avec le féminin). J'entends parfois aussi parler de service client et,
pourtant, il sonnerait mal à l'oreille de parler de service serveur.
(3) Une application serveur (par ex. FTP serveur) peut être exécutée sur une
machine cliente.
(4) La traduction française de RFC793 (spécification TCP), traduit assez
souvent le terme "user" par "application". Ceci m'apparait être une faute
car il me semble que l'anglais suppose "user service" et, comme indiqué plus
haut, le service peut être de niveau applicatif ou de niveau transport.
Que vous suggère tout cela ?
A vos plumes !
Angelot
POur moi un processus serveur (ou un programme) est un processus a l'ecoute
permanente de requetes parvenant sur un "port" specifique ... a contrario un comportement "client" consiste a envoyer des requetes vers un numero de
port en vue d'obtenir des reponses ou une action quelquonque.
Vous confortez notre point de vue.
Que l'origine de l'action soit humaine ou le resultat d'un comportement de daemon (machine) ne change rien au concept client/serveur a mon avis.
Le sujet n'était pas tout à fait cela. D'ailleurs l'origine de l'activation du daemon a forcément été, à un moment ou à un autre, de main d'homme (je parle bien de l'origine). Néanmoins ce ne sera pas cet homme qui remplira les charges utiles des segments TCP ou des datagrammes UDP, mais un processus utilisateur de TCP ou de UDP (retour à notre sujet).
Oui le modele tcp/ip comporte 5 couches .. et le modele OSI 7 ca n'arrange rien ds le modele tcp/ip la couche graphique est melangee a la couche applicative.
Cette déclaration n'est pas correcte. Le logiciel graphique, s'il n'a pas pour objectif de transmettre des données (par ex. Word, Powerpoint) n'est pas un constituant télécom et, à ce titre, ne peut pas recevoir l'appellation couche (sous-entendu de transmission télécom). L'aspect graphique est lié à l'OS et à la machine, il est complètement indépendant du fonctionnement de la couche applicative qui, par nature, se veut indépendant de l'OS et de la machine.
Le logiciel propriétaire "manager SNMP" du LMDS de l'A7390 d'Alcatel (qui tourne sous Windows) utilise la couche application SNMP décrite par exemple dans RFC1157.
La notion client/serveur peut a mon avis ne pas se cantonner au comportement
des services de base tcp/ip mais s'etendre aux logiciels applicatifs par exemple : apache est un serveur web bien connu et mozilla un browser web bien connu aussi mais comme "client". Les deux memttent en oeuvre les protocoles http serveur et httpclient respectivement.
Oui, et le 1er niveau TCP/IP à être alerté de la relation client/serveur est la couche transport qui doit être mise au courant de l'existence du port.
Cordialement, Angelot
Bonjour Patrick,
POur moi un processus serveur (ou un programme) est un processus a
l'ecoute
permanente de requetes parvenant sur un "port" specifique ... a contrario
un comportement "client" consiste a envoyer des requetes vers un numero
de
port en vue d'obtenir des reponses ou une action quelquonque.
Vous confortez notre point de vue.
Que l'origine de l'action soit humaine ou le resultat d'un comportement de
daemon (machine) ne change rien au concept client/serveur a mon avis.
Le sujet n'était pas tout à fait cela. D'ailleurs l'origine de l'activation
du daemon a forcément été, à un moment ou à un autre, de main d'homme (je
parle bien de l'origine). Néanmoins ce ne sera pas cet homme qui remplira
les charges utiles des segments TCP ou des datagrammes UDP, mais un
processus utilisateur de TCP ou de UDP (retour à notre sujet).
Oui le modele tcp/ip comporte 5 couches .. et le modele OSI 7 ca n'arrange
rien ds le modele tcp/ip la couche graphique est melangee a la couche
applicative.
Cette déclaration n'est pas correcte. Le logiciel graphique, s'il n'a pas
pour objectif de transmettre des données (par ex. Word, Powerpoint) n'est
pas un constituant télécom et, à ce titre, ne peut pas recevoir
l'appellation couche (sous-entendu de transmission télécom). L'aspect
graphique est lié à l'OS et à la machine, il est complètement indépendant du
fonctionnement de la couche applicative qui, par nature, se veut indépendant
de l'OS et de la machine.
Le logiciel propriétaire "manager SNMP" du LMDS de l'A7390 d'Alcatel (qui
tourne sous Windows) utilise la couche application SNMP décrite par exemple
dans RFC1157.
La notion client/serveur peut a mon avis ne pas se cantonner au
comportement
des services de base tcp/ip mais s'etendre aux logiciels applicatifs par
exemple : apache est un serveur web bien connu et mozilla un browser web
bien connu aussi mais comme "client". Les deux memttent en oeuvre les
protocoles http serveur et httpclient respectivement.
Oui, et le 1er niveau TCP/IP à être alerté de la relation client/serveur est
la couche transport qui doit être mise au courant de l'existence du port.
POur moi un processus serveur (ou un programme) est un processus a l'ecoute
permanente de requetes parvenant sur un "port" specifique ... a contrario un comportement "client" consiste a envoyer des requetes vers un numero de
port en vue d'obtenir des reponses ou une action quelquonque.
Vous confortez notre point de vue.
Que l'origine de l'action soit humaine ou le resultat d'un comportement de daemon (machine) ne change rien au concept client/serveur a mon avis.
Le sujet n'était pas tout à fait cela. D'ailleurs l'origine de l'activation du daemon a forcément été, à un moment ou à un autre, de main d'homme (je parle bien de l'origine). Néanmoins ce ne sera pas cet homme qui remplira les charges utiles des segments TCP ou des datagrammes UDP, mais un processus utilisateur de TCP ou de UDP (retour à notre sujet).
Oui le modele tcp/ip comporte 5 couches .. et le modele OSI 7 ca n'arrange rien ds le modele tcp/ip la couche graphique est melangee a la couche applicative.
Cette déclaration n'est pas correcte. Le logiciel graphique, s'il n'a pas pour objectif de transmettre des données (par ex. Word, Powerpoint) n'est pas un constituant télécom et, à ce titre, ne peut pas recevoir l'appellation couche (sous-entendu de transmission télécom). L'aspect graphique est lié à l'OS et à la machine, il est complètement indépendant du fonctionnement de la couche applicative qui, par nature, se veut indépendant de l'OS et de la machine.
Le logiciel propriétaire "manager SNMP" du LMDS de l'A7390 d'Alcatel (qui tourne sous Windows) utilise la couche application SNMP décrite par exemple dans RFC1157.
La notion client/serveur peut a mon avis ne pas se cantonner au comportement
des services de base tcp/ip mais s'etendre aux logiciels applicatifs par exemple : apache est un serveur web bien connu et mozilla un browser web bien connu aussi mais comme "client". Les deux memttent en oeuvre les protocoles http serveur et httpclient respectivement.
Oui, et le 1er niveau TCP/IP à être alerté de la relation client/serveur est la couche transport qui doit être mise au courant de l'existence du port.
Cordialement, Angelot
Angelot
Bonjour Sèb,
je visualise "processus" instantanément dans un Os, alors que toi, provenant
des couches basses, tu penses instantanément à ATM.
euh ! je pense surtout avec mes propres cellules grises, et pas avec celles d'ATM qui peuvent être de remplissage.
Vis à vis d'une couche transport TCP/IP, le service peut être de couche applicative TCP/IP, de couche transport TCP/IP ou d'une couche d'un autre
modèle que TCP/IP, par exemple IPX de Novell Netware.
Tout le monde est au service de toutle monde.
Alors, il faut être plus précis sur le terme service, et je réécris la phrase : les numéros de port dans une unité de transport (TCP ou UDP) permettent d'échanger des données (lorsqu'ils sont ouverts) avec un service de couche applicative TCP/IP, de couche transport TCP/IP ou d'une couche d'un autre modèle que TCP/IP, par exemple IPX de Novell Netware, OSI.
J'en reviens au fait que tout le monde est au service de tous. Icmp est un protocole, mais traceroute et ping sont des applicatifs que nous, les humains ou opérateurs comme tu le dis, utilisons.
Hep ! je causais du traceroute sur TCP, numéro de port enregistré 33434. Et pas de l'outil tracert qui utilise les échos ICMP.
J'en reviens à ma question de base, tu disais : "Point (1) : le service peut
être de couche applicative (cas le plus courant), mais pas seulement" Alors sommes nous d'accord pour dire le service est forcement applicatif ?
Désolé... Par exemple, Ethernet fournit un service de protocole de niveau liaison.
Si je prends le même style de réponse (bondir de sous sujets en sous sujets), cela dépend si c'est d'un point de vue résultat technique ou commerciale. Et surtout c'est variable en fonction du facteur humain qui est
le client, ils sont tous différents et le plus important est de les comprendre pour répondrent à leurs attentes.
C'est sentimental. Mais pardon, j'ai dérivé, c'est un autre sujet dans lequel intervient le temps, les capacités, le budget, la qualité, l'expression de besoin, le cahier des charges, la MOE et MOA...
... sommes nous donc relativement et absulement d'accord ?
Oui, Sèb !
Cordialement, Angelot
Bonjour Sèb,
je visualise "processus" instantanément dans un Os, alors que toi,
provenant
des couches basses, tu penses instantanément à ATM.
euh ! je pense surtout avec mes propres cellules grises, et pas avec celles
d'ATM qui peuvent être de remplissage.
Vis à vis d'une couche transport TCP/IP, le service peut être de couche
applicative TCP/IP, de couche transport TCP/IP ou d'une couche d'un
autre
modèle que TCP/IP, par exemple IPX de Novell Netware.
Tout le monde est au service de toutle monde.
Alors, il faut être plus précis sur le terme service, et je réécris la
phrase :
les numéros de port dans une unité de transport (TCP ou UDP) permettent
d'échanger des données (lorsqu'ils sont ouverts) avec un service de couche
applicative TCP/IP, de couche transport TCP/IP ou d'une couche d'un autre
modèle que TCP/IP, par exemple IPX de Novell Netware, OSI.
J'en reviens au fait que tout le monde est au service de tous.
Icmp est un protocole, mais traceroute et ping sont des applicatifs que
nous, les humains ou opérateurs comme tu le dis, utilisons.
Hep ! je causais du traceroute sur TCP, numéro de port enregistré 33434. Et
pas de l'outil tracert qui utilise les échos ICMP.
J'en reviens à ma question de base, tu disais : "Point (1) : le service
peut
être de couche applicative (cas le plus
courant), mais pas seulement" Alors sommes nous d'accord pour dire le
service est forcement applicatif ?
Désolé... Par exemple, Ethernet fournit un service de protocole de niveau
liaison.
Si je prends le même style de réponse (bondir de sous sujets en sous
sujets), cela dépend si c'est d'un point de vue résultat technique ou
commerciale. Et surtout c'est variable en fonction du facteur humain qui
est
le client, ils sont tous différents et le plus important est de les
comprendre pour répondrent à leurs attentes.
C'est sentimental. Mais pardon, j'ai dérivé, c'est un autre sujet dans
lequel intervient le temps, les capacités, le budget, la qualité,
l'expression de besoin, le cahier des charges, la MOE et MOA...
... sommes nous donc relativement et absulement d'accord ?
je visualise "processus" instantanément dans un Os, alors que toi, provenant
des couches basses, tu penses instantanément à ATM.
euh ! je pense surtout avec mes propres cellules grises, et pas avec celles d'ATM qui peuvent être de remplissage.
Vis à vis d'une couche transport TCP/IP, le service peut être de couche applicative TCP/IP, de couche transport TCP/IP ou d'une couche d'un autre
modèle que TCP/IP, par exemple IPX de Novell Netware.
Tout le monde est au service de toutle monde.
Alors, il faut être plus précis sur le terme service, et je réécris la phrase : les numéros de port dans une unité de transport (TCP ou UDP) permettent d'échanger des données (lorsqu'ils sont ouverts) avec un service de couche applicative TCP/IP, de couche transport TCP/IP ou d'une couche d'un autre modèle que TCP/IP, par exemple IPX de Novell Netware, OSI.
J'en reviens au fait que tout le monde est au service de tous. Icmp est un protocole, mais traceroute et ping sont des applicatifs que nous, les humains ou opérateurs comme tu le dis, utilisons.
Hep ! je causais du traceroute sur TCP, numéro de port enregistré 33434. Et pas de l'outil tracert qui utilise les échos ICMP.
J'en reviens à ma question de base, tu disais : "Point (1) : le service peut
être de couche applicative (cas le plus courant), mais pas seulement" Alors sommes nous d'accord pour dire le service est forcement applicatif ?
Désolé... Par exemple, Ethernet fournit un service de protocole de niveau liaison.
Si je prends le même style de réponse (bondir de sous sujets en sous sujets), cela dépend si c'est d'un point de vue résultat technique ou commerciale. Et surtout c'est variable en fonction du facteur humain qui est
le client, ils sont tous différents et le plus important est de les comprendre pour répondrent à leurs attentes.
C'est sentimental. Mais pardon, j'ai dérivé, c'est un autre sujet dans lequel intervient le temps, les capacités, le budget, la qualité, l'expression de besoin, le cahier des charges, la MOE et MOA...
... sommes nous donc relativement et absulement d'accord ?
