Discussion :

[m29poff]

Bonjour,

je suis en train d'écrire un programme sous linux qui doit gérer un nombre important de connections tcp.

je souhaiterais, lors d'un évènement sur une socket, pouvoir accéder à un tableau dont l'indice est le numéro de socket concerné par l'évènement.

Exemple: un évènement se produit sur la socket dont le descripteur est 1515.

j'aurais besoin d'accéder à l'élément tableau[1515].

jusque là ... c'est simple ... me direz vous. Le problème réside dans la taille du tableau à déclarer. Le descripteur de socket est un int. En conséquence, si on souhaite couvrir toutes les valeurs possible du descripteur de socket, il faut déclarer un tableau ayant 2.147.483.647 (valeur de INT_MAX dans limits.h) entrées. C’est bien entendu impossible.

quelqu’un aurait-il une solution à m’apporter qui me permettrait de conserver un accès direct très rapide par un tableau ou suis-je condamné à mettre en place un arbre ou une liste chainée ?

Merci d’avance pour tous vos conseils.

[imperio]

Tu peux toujours créer un tableau que tu ré-alloueras au besoin, mais une liste chaînée me semble être la meilleure solution.

[ram-0000]

Tu peux toujours créer un tableau que tu ré-alloueras au besoin, mais une liste chaînée me semble être la meilleure solution.

+1 pour la liste chainée.

Sinon, au lieu d'utiliser le numéro de socket, tu peux utiliser le numéro de port local (c'est très facile à récupérer, c'est getsockname()), il n'y a que 65536 ports pour TCP et 65536 pour UDP.

Je viens de faire passer ton tableau de 4 milliard potentiel à 2 X 65536, c'est un beau gain

[m29poff]

Bonjour,

Je trouve l'idée d'utiliser le numéro de port local très intéressante. Cependant, cela ne peut fonctionner que pour les connexions sortantes.

Il se trouve que mon programme accepte aussi des connexions tcp (mode serveur).

Dans ce cas, le port local est forcément toujours le même. De plus, on ne peut pas prendre le port source du client comme indice car 2 clients peuvent très bien utiliser 2 ports sources identiques.

En guise de pis-aller j'utiliserai la liste chainée.

Quoiqu'il en soit, je vous remercie pour le coup de main.

[Obsidian]

Avant d'envisager d'allouer 2 milliards de connexions, tu peux déjà te renseigner sur le nombre total de descripteurs de fichiers que le système lui-même est capable d'allouer. Sur un Linux récent, tu trouves cela dans « /proc/sys/fs/file-max ». Sur ma machine, c'est un peu moins de 400.000, ce qui est déjà plus raisonnable. Et évidemment, « ulimit -n » qui te donne la limite imposée par défaut à un processus donné.

Ensuite, plutôt qu'un immense tableau ou une liste chaînée un peu lourde à mettre en place et à parcourir, tu peux opter pour une structure entre les deux. Le mieux, je pense, consiste à allouer plusieurs plages de taille arbitraire, reliées entre elles par une hash table. L'idée étant de pouvoir jouer sur le compromis entre complexité de calcul et mémoire occupée.

En outre, ce n'est pas la peine de prévoir la place pour plus de connexions que tu pourras en gérer : à raison de 1000 connexions par secondes, ce qui est énorme, il te faudrait 24 jours pour recevoir deux milliards de connexions. À titre indicatif, Developpez.com|net reçoit jusqu'à 220.000 visites par jour, ce qui fait une moyenne de… 2,5 connexions par seconde.

À ce stade, l'indice le plus pertinent est la durée moyenne d'une de tes connexions. Si c'est du FTP, elle peuvent perdurer pendant des dizaines de minutes. Si c'est du web, une durée de vie de 2 à 3 secondes maximum suffit. À toi de multiplier ce chiffre par le nombre de connexions par seconde + une marge de sécurité pour définir une taille maximale à ton tableau, quitte à la ré-évaluer en changeant la configuration en cas de besoin.

[Bktero]

Il se trouve que mon programme accepte aussi des connexions tcp (mode serveur). Dans ce cas, le port local est forcément toujours le même.

Si je ne dis pas de bêtise, ceci n'est pas vrai. Tu as un socket serveur à l'écoute sur un port donné et toutes les connexions entrantes passent par ce port. C'est le rôle de la fonction accept(), qui renvoie un nouveau descripteur de socket quand une connexion entrante a lieu. Ce socket utilise alors un port différent du port du socket serveur. Tu peux donc différencier les connexions entrantes via le port du socket de communication. C'est d'ailleurs bien pour ça que tu peux avoir des connexions entrantes simultanées sans qu'elles ne se marchent sur les pieds.

Edit : j'ai dit des bêtises