Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
gestion des port !
Salut à tous.
Si j'ai bien compris, quand un client se connecte à un serveur (par ex apache sur le port 80), celui-ci est alors redirigé vers un autre port afin de toujours laisser le port d'ecoute libre.
Il me semble avoir vu un truc pour definir cette plage de port de redirection. cela m'arrangerai bien car j'ai l'impression que sur ma machine il arrive q'un client soit connécté à un certains port dont j'aurai bien besoin pour un autre de mes scripts serveur...
Une piste ?
Merci à vous.
non !
Apache écoute sur le port 80, et se débrouille avec les connections.
Si tu veux qu'apache écoute sur une autre porte que le port 80 : http://apache.org
Jean Christophe
Non je ne parle pas d'apache precesement... J'ai des scripts serveurs en perl/C ou java, mais quand un client s'y connecte, il se retrouve finalement sur un autre port (vu avec netstat).... Du coup il arrive q'un client tombe sur un port que je veux absolument garder libre.
Il faut savoir que ce serveur recois des miliers de conecttions socket.. donc au cours de la journée, il arrive tot ou tard q'un client tombe sur un port que je veux absolument garder libre.
Une idée ?
Non, il reste sur le port 80. Les données sont multipléxés sur ce même port pour tous les clients.
Tu confonds peut-être avec le protocole ftp qui, lui, ouvre un port spécifique par client. C'est d'ailleurs galère à régler sur les firewall à cause de ça.
Salut.
Merci beaucoup pour ta reponse.
Ce que je pige pas, c'est que quand je fais un :
netstat -alpe | grep yspsyche
(yspsyche est le nom de user sur lequel tourne mon script serveur perl) j'ai donc :
on vois bien port 12300 ouvert mais on vois aussi d'autres ports pour chacune des conections ! Ou alors j'ai pas bien pigé ce que me sort le netstat. un idée ?tcp 0 0 nsXXXXX.ovh.net:12300 ABayonne-151-1-38-:2289 ESTABLISHED yspsyche 25483690 -
tcp 0 0 nsXXXXX.ovh.net:12300 modemcable043.126-:1189 ESTABLISHED yspsyche 25366561 1659/perl
tcp 0 0 nsXXXXX.ovh.net:12300 lns-vlq-25-ren-82-:1142 ESTABLISHED yspsyche 21846481 1659/perl
tcp 0 0 nsXXXXX.ovh.net:12300 ARouen-152-1-54-60:4754 ESTABLISHED yspsyche 24606023 1659/perl
tcp 0 244 nsXXXXX.ovh.net:12300 106-114.241.81.ads:1594 ESTABLISHED yspsyche 25230965 1659/perl
tcp 0 0 nsXXXXX.ovh.net:12300 i01v-32-156.d4.clu:1225 ESTABLISHED yspsyche 24398502 1659/perl
Je me suis posé la même question il y a quelques temps.
C'était sur le port 80 (Apache).
J'ai trouvé la réponse.
En fait, Apache crée plusieurs processus fils avec le même port pour plusieurs raisons je pense :
sécurité : étant donné qu'il s'agit de processus différents, la mémoire est complètement inaccessible d'un processus à l'autre. Donc les clients sont bien séparés en mémoire.
Vitesse : ce code est très parallèle, donc très bon pour le multiprocessing et le grid
Sécurité encore : un processus qui plante n'entraine pas les autres.
D'autre part, Apache lance d'entrée plusieurs fils afin de pouvoir accepter plusieurs connexions simultanées.
Au passage, plusieurs processus peuvent écouter sur le même port. les sockets permettent de multiplexer plusieurs connexions TCP sans problème.
J'espère avoir répondu à tes questions.
Oui mais dans mon cas, il n'ya aucun rappot avec apache.
Ce script je l'ai ecrit moi même, il accepte simplement une conection est dispatch les infos à tous les clients connectés.
Dans ce cas, même si je coupe apache, cela fonctionne toujours. Je ne fait pas de multithread ni fork. Ce n'est pas moi qui dit à un client qui se conecte sur mon port 12300 : "ok je t'accepte mais va sur tel port"... Il doit donc y avoir un gestion plus "bas niveau" pour gerer cela. L'ennui c'est que j'ecoute sur les port avec tcp-dump, il arrive donc que je recoive des paquets sur le port d'un script serveur alors que celui-ci est eteind. C'est apres avoir fait un netstat que je me suis rendu compte que les ports sont aleatoirement utilisés par des clients...
C'est pas evident de trouver des infos là dessus sur le web quand on tape port ou socket, on a beaucoup de site mais qui ne parlent pas de cette question.
Non, le port sur le serveur est toujours le port 12300. L'autre port indiqué est le port utilisé par la machine cliente. Le protocole TCP/IP ne prévoit pas de changer de port.
Le problème est donc ailleurs.
Je ne vois pas trop ton problème.
C'est toujurs le port 12300 qui est utilisé coté serveur.
Coté client, il est évidemment normal qu'un client ait un port tiré au hasard au dessus de 1024. Cela n'a d'ailleurs aucune importance.
Yop.
Le prob, c'est que j'ai un sniffer de bande passante par user basé sur le tcpdump.
Pour mon projet, chaque user à droit à 5 ports, je me sers de netstat pour le verifier et killer un process qui ecoute sur un mauvais port.
Mais il arrive que le sniffer detecte un debit sur un port dont le user n'a pas encore lancer de serveur, simplement parceque un autre client, en se conectant, à utilisé ce port... C'est pour cette raison que je voulai definir une plage sur laquelle je suis sur q'aucun user ne peut l'utiliser.
J'ai plus ou moin resolu le prob avec le sniffer en relevant aussi le nom d'hote source.. Mais j'aurai aimé pouvoir le gerer, être capable de le faire et surtout comprendre.
Tu ne peux pas gérer le port TCP du client depuis le serveur.
Ce n'est pas dans le protocole TCP.
Par contre, tu peux très bien créé ton propre protocole de transport avec ce genre de contrainte. Il te suffit d'utiliser le protocole IP (niveau réseau) grâce aux sockets de type "raw".
Les sockets BSD permettent en effet d'utiliser TCP, UDP, ou aucun protocole de niveau transport et donc directement IP.
Cela dit, il y a beaucoup moins de contrôle sur le protocole IP. Celui-ci fonctionne en mode sans connexion, il ne gère pas l'ordre des arrivées, il ne fait pas de contrôle de flux, et pas de correction d'erreur. Mais pour ce dernier point, souvent, les protocoles de niveau liaison (en dessous) le font.
seal3, le port du *serveur* est toujours 12300, le port du *client* est lui choisi au hasard, mais par example admettons que le client ait choisi 1234 comme port pour se connecter, ce port sera toujours disponible sur le serveur.
Imagine ça comme ça : le client et le serveurs ont tout deux 65534 ports disponibles qu'on peut représenter par des prises. Lorsqu'ils veulent communiquer, le client branche sa prise 1234 sur la prise 12300 du serveur ... mais la prise 1234 du serveur reste libre.
Voilà je ne sais pas si j'ai été très clair, n'hésite pas a consulter la doc de base sur le TCP/IP si tu n'as toujours pas compris.
Salut.
oui tu as été tres clair, je te remerci... En effet le port reste dispo côté serveur. Il m'a juste fallu trouver une astuce pour que mon sniffer de bande passante persoive qu'il s'agit du port client et non pas du port serveur.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager