Discussion :

[Invité]

Bonjour,

J'ai besoin de développer un service Windows, un serveur TCP. Je vais utiliser le composant TServerSocket pour gérer les connexions.
Le service doit pouvoir gérer 100.000 clients TCP, des produits qui viendront se connecter de temps en temps pour échanger des infos. Donc des milliers potentiels, mais des centaines en simultané...

Ma question est : dois-je utiliser des threads pour gérer chaque connexion, comme je vois sur certains exemples, ou puis-je m'en passer?
Sachant que dans un exemple, j'ai une gestion par thread avec Timeout, et je ne veux pas de timeout!!

Alors thread ou pas thread? Telle est la question...

Merci pour vos avis, réflexions...

[ShaiLeTroll]

Beaucoup vont te dire que TServerSocket est obselète, il faut utiliser le TTCPServer (Delphi 7), TIdTPCServer (Indy) ou ICS !

Maintenant 100 000 Clients ! Faut vraiment qu'il ne soit pas simultanés !
Une Centaine ça va, pour un millier, mieux vaut avoir un OS Server !
Ensuite Windows, j'ignore ses limites mais autant ne pas pousser trop loin inutilement !

Ma question est : dois-je utiliser des threads pour gérer chaque connexion, comme je vois sur certains exemples, ou puis-je m'en passer?

Surtout pas !
En Delphi 5, dépasse 32 threads, le Memory Manager fait la Gueule !
Avec FastMM, tu peux monter à presque 2000 !
Mais ton OS passe plus de temps à changer de Thread qu'a executer les threads !
FastMM est inclu à Delphi dans la version 2007 (il me semble)

Regarde les Pools de Thread, tu lance un thread par connexion cliente, une fois 20 thread donc 20 connexions, tu repars avec le 1er thread, le 1er client et le 21eme partegeront leur execution !
A chaque nouvelle connexion, tu cherches le thread le moins occupé
Tu définis qu'un Thread ne peut pas se partager pour plus de 10 clients, ton algo va donc prévoir la création d'un nouveau thread ... que deviendra le moins occupé !
20 est une valeur totalement arbitraire !

Pense qu'il y a aussi la gestion du TCP\IP mais si tu utilises une BDD derrière, idem, tu pourrais gérer un pool de thread pour envoyer le SQL, idem, tu recherches les moins occupés pour empiler tes requêtes en FIFO ...

Le TimeOut est souvent utile, ou alors un fonctionnement totalement asynchrone, tu envoie une requete cliente TCP\IP, le server répond ACK et renvoi un ticket (jeton), pendant de temps le serveur traitement et emet la réponse avec le numéro de ticket (le client lui faisait autre chose pendant ce temps !)

Lit le sujet "Delphi 5 et threads en nombre" où j'évoquaiss un système de répartiteur de charge

[Invité]

Je sais que TServerSocket est obsolète, mais j'utilise Delphi 6 qui n'est pas tout jeune non plus... J'ai vu que TTCPServer avait moins de paramètres (et moins d'exemples) que son ancêtre, alors je préfère le vieux.

Le service est destiné à être installé sur un serveur Web, le but est de communiquer d'un côté avec le site web via une BD MySQL et d'un autre côté de gérer les connexions des clients et le transfert des données avec ces derniers.
Je pense et j'espère qu'il doit avoir les ressources suffisantes...

Il risque, à terme, d'y avoir pas mal de monde à gérer... mais pas forcément en mm temps.
Je peux gérer les données de chaque connexion l'une après l'autre, car les clients seront connectés en permanence mais le volume et la fréquence des données échangées seront faibles.
C'est pour ça que je me posais la question de l’utilité des threads par connexion, dans mon cas.

Je ne sais pas comment on peut faire une "recherche du thread le moins occupé", ça à l'air compliqué, non?
Je pense utiliser 2 ou 3 threads:
- pour gérer toutes les connexions
- le traitement des données entre un client et la base
- et un autre pour le transfert des données de la base vers les clients.

Est-ce une archi raisonnable?

[ShaiLeTroll]

Serveur Web !

Dans ce cas Apache ou IIS se chargeront de la gestion des connexions et des threads !
Tu vas faire soit un ISAPI soit un module d'Extension Apache !

Pour cette approche, j'aurais évoqué COM+ mais je crois que c'est obselète ! non ?

Je ne vois pas où se glisse ton programme, tu as une application Web dans un autre langage ?

"recherche du thread le moins occupé", cela peut se comprendre de différente façon, soit tout simplement celui avec le moins de connexion, soit celui avec le plus petit temps processeur (j'ignore les API pour récupérer le temps processeur au niveau d'un thread, faudra fouiller)

Tu peux découper comme tu l'as proposé, c'est une archi raisonnable !
J'ignore par contre le comportement d'un TServerSocket gérant 1000 connexions, à tester en mode ctBlocking (Thread) et ctNonBlocking (OnRead Event)

[Invité]

J'ai oublié de préciser que les "clients" ne seront pas des gens devant un PC qui cliquent... c'est sans doute pour ça que tu me parles de ISAPI ou COM+...

Mais dans mon cas, ce sont des machines, des cartes électroniques (oui je fais de l'embarqué à la base) qui se connectent en IP sur un serveur et qui doivent échanger des infos.
Donc la solution de service Windows est plus appropriée, je pense. A moins que je fasse fausse route...

Je travaille déjà sur un système équivalent, avec des services windows + BD MySQL + cartes électroniques. Mais là je ne peux pas réutiliser les mêmes composants (DLL...) car ils sont spécifiques.

Je vais essayer le principe que j'ai décrit, en espérant comme tu dis, que TServerSocket pourra gérer des milliers de connexions...

[ShaiLeTroll]

Pour moi, un Server Web, c'est pour le HTTP (ou protocol Web)
Peu importe humain ou programme, tu peux avoir une application web qui la nuit importe des données par bash et appel des webservices !
C'est toi qui parle de "Serveur Web", j'évoque donc les technologies qui vont avec !

N'utilise pas ce terme de "Serveur Web" si c'est si pour une communication TCP\IP avec du Hardware !
Je fais aussi du Hardware en TCPIP, RS232 et RS422, je comprends ta problèmatique

Ce n'est pas parce qu'une application lourde et Application Web partage le même Base MySQL que l'on peut dire que les deux applications communiquent !
Pour moi, c'est juste deux clients de la DB qui vont alimenter chacun la partie métier qui les concerne (partie pouvant se recouper)
Ton application Hardware n'est qu'un Batch d'alimentation de la DB, rien de plus !
C'est la même chose si c'était des imports de fichier automatisé en masse provenant de logiciels tiers !

Passons, le problème c'est donc juste "la concentration de données provenant d'un grand nombre de client TCP\IP sur une Base MySQL"
Pas besoins de considérer plus de choses pour le moment !

Tu évoques déjà une autre solution similaire existante, le nombre de client était moins important ?

Un Service Windows semble tout à fait approprié !

Je suis un plein développement d'une gestion générique du Hardware par des DLL contenant des Interfaces (une partie commune concernant la déclaration\recensement d'un hardware et une partie spécifique à l'utilisation même du hardware).
Les implémentations sont évidement différentes pour chaque type de hardware, et même pour un type donné, pour chaque marque et pour chaque modèle, j'ai prévu des factory pour fournir l'implémentation adéquate !

Attention au spécifique, on doit toujours tout refaire !
Rien n'est plus standard qu'un echange TCP\IP, en général, tu n'as pas grand à savoir !
- Qui traite une Demande (une Pattern strategy utilisant des DLL permet de switcher le traitement facilement)
- Où doit aller une Demande (idem, une strategy, on sait d'où ça vient et qui l'a traité, donc on sait on cela devra aller)

J'ai déjà vu une application de pilotage de machine qui n'était composé que de modules indépendants communiquant entre eux avec des APIs Communes, lors de l'installation, il fallait monter les briques entre elles pour modèliser le process, et tu pouvais développer tes propres extensions en implémentant ces fameuses API !


Je peux te dire qu'avec le TServerSocket, je suis monté à 96 connexions simultanés sur Win98 (après ça puait), cela échangeait un numéro de trame + TimeStamp.
Sous Windows 2000 stable jusqu'à 512 (j'ai pas tenté plus loin), c'était juste pour le fun !
Et le tout en mode stNonBlocking !

Croisez les doigts n'est pas une technique valable !
Procède à une mini-Etude de Faisabilité !

Fait un programme Server qui attend la connexion et renvoi un petit message (IP du client + Numéro + TimeStamp par Exemple) à la connexion, et renvoie au client tous messages reçus de sa part plus un compteur

Fait un programme client qui lance un nombre configurable de connexion, disons une centaine simultané, envoie n message au serveur (n étant aléatoire genre de 1 à 5) toutes les x secondes, puis se deconnecte !
Ce Client tu le lances plusieurs fois sur un même poste et même sur plusieurs postes !)

Client et Serveur loggue tous les echanges dans la DB MySQL !

Au pire, tu peux décomposer ton server !
Si tu n'arrives à monter assez haut en connexion sur un TServerSocket, tu en utilise plusieurs sur des ports différents (tes cartes devront être réparti à un port lors de leur installation, si c'est possible)
Si tu ne peux pas changer le port du côte Hardware mais juste l'IP, plusieurs programmes frontaux TCP\IP qui utiliseront la DB MySQL !

[Franck SORIANO]

Je vais utiliser le composant TServerSocket pour gérer les connexions.
Le service doit pouvoir gérer 100.000 clients TCP, des produits qui viendront se connecter de temps en temps pour échanger des infos. Donc des milliers potentiels, mais des centaines en simultané...

Peu importe la façon dont tu écrits ton code, tu ne pourras jamais avoir 100 000 connexion TCP ouverte en même temps sur le serveur, qu'elles soient actives ou non.

Il y a une limitation inérente à l'implémentation de la pile TCP/IP de Windows. A moin d'aller bidouiller la base de registre, tu ne pourras pas avoir plus de 2000 connexions ouverte sur la machine.
Plus exactement, la pile TCP/IP n'alloue pas plus de 2000 TCBs (TCP Control Blocks). Et chaque connexion nécessite au moin un TCB (voir peut-être plus selon les opérations en cours).
Lorsque tous les TCB disponibles auront été utilisé, le serveur ne poura plus accepter de nouvelles connexions entrantes.

De plus 100 000 connexions, c'est totalement sur-réaliste. Surtout si en plus tu ne veux pas avoir de time-out pour fermer automatiquement les connexions mortes.

Pourquoi garder les clients connectés en permanence ?
D'après ce que je comprends, il y aura un grand nombre de clients sur le réseau, mais ils n'auront besoin du serveur que très rarement.
Il serait préférable que ces derniers n'ouvrent la connexion au serveur que lorsqu'ils ont réellement quelque chose à demander et qu'ils se déconnectent le reste du temps.

[Invité]

Merci Franck pour ces précisions importantes, je ne connaissais pas cette limitation de Windows.
Cette valeur théorique de 100 000 connexions ne sera certainement jamais atteinte, en nombre de clients. Les 2000 connexions ne seront peut-être pas atteints avant plusieurs années... Donc on verra à ce moment là s'il faut installer un autre serveur... ou revoir l'architecture...

Les connexions doivent rester ouverte pour pouvoir transmettre des données du serveur vers les clients, à n'importe quel moment. La connexion étant à l'initiative du client, il doit être là au cas où on aurait qqch à lui dire...