Discussion :

[zephyre]

Bonjour,

Je vais résumer ce que j'ai compris rapidement (ça prendra pas beaucoup de temps) ci dessous.

Dans un modèle client serveur :
Le client est l émetteur (dans le sens il émet une requête, on part de lui) et le serveur reçois cette requête.
Le port dit entrant est le port d écoute du serveur, c'est à dire la "porte" par laquelle le serveur est attaqué par le client.
Le port dit sortant est le port de réception du client (sur l'ordinateur local).

Prenons un exemple comme on peut le voir dans certaines syntaxe = 80:80.
Le premier 80 est le port entrant celui sur lequel le client va attaquer le serveur.
Le second 80 est le port de ordinateur local ou est envoyé la réponse du serveur vers le client ?

En tout cas c est ce que j ai compris.

Quelques questions :
Dans un modèle client serveur, sur un port entrant on ne peut faire tourner qu'une et une seule application à l'instant t ? Oui/Non

Le modèle peer to peer :
C'est pareil que le modèle client serveur, sauf que les nœuds ou encore périphériques de terminaisons peuvent jouer tanto le rôle de client et tanto le role de serveur.

Ce sont les 2 modèles d'environnement (je sais pas si c'est le terme exact) que je connaisse maintenant.
J'aimerai savoir s'il en existe d'autres ?

Dernière question supposons que je sois un administrateur réseau :
Dans mon architecture j'ai les éléments suivant :
- Un et un seul serveur bases de données
- Un et un seul serveur applicatif
Y a t'il un moyen d'augmenter sa vitesse/débit pour répondre à la charge du réseau.

Personnellement je ne vois qu'un seul moyen, c'est d'augmenter le nombre de socket réseau, je vois que ça. Ci vous avez d'autres idées ? Moi personnellement je ne vois pas.
Qui exécute les sockets réseau au niveau du hardware ? le CPU (microprocesseur) ?
Qui manage/gère les sockets réseaux (leur nombre) au niveau du software ? L'Os probablement mais c'est un peu vaste tout de même


Merci pour vos réponses.

Cordialement

[becket]

Dans un modèle client serveur :
Le client est l émetteur (dans le sens il émet une requête, on part de lui) et le serveur reçois cette requête.

C'est souvent comme cela mais pas toujours

Le port dit entrant est le port d écoute du serveur, c'est à dire la "porte" par laquelle le serveur est attaqué par le client.
Le port dit sortant est le port de réception du client (sur l'ordinateur local).

Prenons un exemple comme on peut le voir dans certaines syntaxe = 80:80.
Le premier 80 est le port entrant celui sur lequel le client va attaquer le serveur.
Le second 80 est le port de ordinateur local ou est envoyé la réponse du serveur vers le client ?

Oui mais la plupart du temps, c'est le client qui fixe le port de facon dynamique lorsqu'il initie la communication

Quelques questions :
Dans un modèle client serveur, sur un port entrant on ne peut faire tourner qu'une et une seule application à l'instant t ? Oui/Non

On ne fait tourner qu'une application mais plusieurs instances peuvent y tourner.

Le modèle peer to peer :
C'est pareil que le modèle client serveur, sauf que les nœuds ou encore périphériques de terminaisons peuvent jouer tanto le rôle de client et tanto le role de serveur.

C'est effectivement une facon de voir les choses

Dernière question supposons que je sois un administrateur réseau :
Dans mon architecture j'ai les éléments suivant :
- Un et un seul serveur bases de données
- Un et un seul serveur applicatif
Y a t'il un moyen d'augmenter sa vitesse/débit pour répondre à la charge du réseau.

Tu peux :

- Augmenter la taille du tuyau
- Augmenter le nombre d'instances simultanées ( et la puissance du matériel )
- Tu peux faire de la qualité de service ( QOS )

[zephyre]

Tout est clair pour moi.

Juste un truc :

- Augmenter la taille du tuyau
- Augmenter le nombre d'instances simultanées ( et la puissance du matériel )
- Tu peux faire de la qualité de service ( QOS )

Oui je me doutais de tout ceci mais le problème c'est que tout ce que tu dis ce joue au niveau directement du hardware.
Ainsi c'est très "chiant" et "couteux" à mettre en œuvre car on touche directement à l'infrastructure physique.
La seule solution purement software, c'est d'augmenter le nombre de sockets réseaux, sinon es ce que vous voyez d'autre(s) solution(s) ?

[becket]

Tout est clair pour moi.

Juste un truc :



Oui je me doutais de tout ceci mais le problème c'est que tout ce que tu dis ce joue au niveau directement du hardware.
Ainsi c'est très "chiant" et "couteux" à mettre en œuvre car on touche directement à l'infrastructure physique.
La seule solution purement software, c'est d'augmenter le nombre de sockets réseaux, sinon es ce que vous voyez d'autre(s) solution(s) ?

Est encore une de ces questions à la recherche d'une baguette magique voulant améliorer x,y ou z en évitant de toucher à quoi que ce soit et bien sur sans que cela coûte absolument rien ?

Bon changer le nombre d'instance, c'est purement logiciel ... tout comme faire du QOS
Augmenter la taille du tuyau, cela va dépendre évidemment ...

[chrtophe]

Je rajouterais qu'augmenter le tuyau n'est pas forcément la solution au problème, exemple : si tu fais un accès à un serveur de base de données, le goulot d'étranglement ne sera pas forcément le réseau mais la puissance du traitement du serveur, idem pour des traitements sur de gros fichiers, la vitesse des disques pourra être plus significative que la vitesse du réseau.

Avec le QoS, tu pourras améliorer la performance sur certains protocoles, mais c'est au sacrifice du reste du réseau. Ça peut être transparent mais ça peut être aussi sacrifier la vitesse de navigation Internet au profil de l'accès à la base de données.

[zephyre]

Merci les gars,
C'est claire pour moi.
Je clos le sujet.