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 !

[Invité]

N'utilise pas ce terme de "Serveur Web" si c'est si pour une communication TCP\IP avec du Hardware !
...
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 !

Désolé, j'ai parlé de Serveur Web pour décrire le contexte global du projet. Effectivement, c'est un abus de langage que de dire que les applications communiquent via la BD. On va dire que des clients se connectent à un serveur qui va lire et écrire dans une base MySQL...

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

Oui, sur l'autre système le nombre théorique max de clients est de 255. Mais dans la pratique, on atteindra jamais cette valeur (qq dizaines en réalité...).
C'est pas le nombre de clients qui est important dans cette solution, mais le protocole de communication qui est propre à ce système. Je ne peux pas reprendre les DLL pour les utiliser dans ma nouvelle application. C'est un produit que j'ai pris en main en arrivant dans cette société, que j'ai modifié, fait évolué... mais dont je ne suis pas l'auteur.

Là c'est un service qui va gérer des connexions TCP/IP de manière standard, alors je cherche la meilleure manière de faire avec les outils dont je dispose (Delphi 6, composants standards).

Merci pour la description de méthode, je vais tenter de mettre tout ça en pratique via des petites applis de tests...

Et le tout en mode stNonBlocking !

Voilà qui soulève une autre question importante, la gestion des sockets, plutôt en mode bloquantes ou non bloquantes? Dans mon cas, je dirais "stNonBlocking" aussi sinon je risque d'avoir un process qui reste bloqué sur une connexion, sans pouvoir aller surveiller les autres...?

[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...

[Invité]

Fait un programme client qui lance un nombre configurable de connexion, disons une centaine simultané, envoie n message au serveur...

Je suis en train de faire une appli de test "client", mais je ne vois pas comment faire pour ouvrir plusieurs connexions dans un client...?
Surtout avec un seul composant "TClientSocket", est-ce faisable? Si tu en parles, c'est que ça doit l'être...
Je ne peux pas mettre une centaine de boite "TClientSocket" dans ma Form? Sinon j'ai pas fini...

[ShaiLeTroll]

TClientSocket est extrêmement bien documenté !

Description

TClientSocket gère des connexions socket pour un client TCP/IP.

Un Client par Composant donc si plusieurs Clients donc plusieurs Composants !
Il faut créer les composants à la volée via Create() !
Sans passer par l'IDE !

Je ne peux pas mettre une centaine de boite "TClientSocket" dans ma Form? Sinon j'ai pas fini...

Je ne sais même pas comment l'idée a pu te traverser l'esprit !
Delphi n'est qu'un pas Clicodrome !

Si tu débutes en Delphi, tu devrais lire les tutoriels sur l'instanciation dynamique des objets en Delphi (appeler manuellement le constructor sans passer par une Form ou un DataModule)
Ainsi que t’intéresser à l'affectation d'un Gestionnaire d’Événement à la volée en RunTime

[Invité]

Effectivement, tu auras remarqué que je ne suis pas un expert en Delphi.

Y vaut mieux pas que je dise ce que j'étais en train de faire alors...

Donc je vais regarder du côté des instanciations dynamiques, je pense que je vais apprendre bcp de choses.
Faut dire que quand tu as presque tout à porté de click, c'est tentant... Plutôt que de coder tout soit même...

Merci encore.

[ShaiLeTroll]

Ne dit rien !

Surtout qu'il faudra tenter d'atteindre les 2000 sockets pour voir l'erreur que provoque Windows !
Ton programme doit être robuste aux erreurs, ne pas hésiter à le stresser au maximum !

Dans un logiciel que j'ai brièvement maintenu, je n'ai jamais atteind les 2000 (Socket et chacun son Thread grace à FastMM), je remercie Franck SORIANO pour sa remarque sur les 2000 TCBs (TCP Control Blocks), je pensais que c'était l'abus de thread le problème mais semble que le nombre de socket l'était aussi (je crois que le plus gros clients ne dépassait jamais 850 connexions simultanés et le programme pouvait monter à 1800 mais après ça commençait à merder ...)

J'ai fait des programmes de Pilotage de Trieuse en utilisant des TServerSocket, j'étais encore étudiant pour le 1er projet, ce n'est pas le plus compliqué, couplé à 2-3 TThreadList contenant un ensemble de record^ servant tout au long d'un traitement avec le message d'origine, des flags, et le message de retour passant à chaque étape de thread en thread, tu devrais y arriver sans trop de difficulté !

Une fois Create, Free, New et Dispose bien maitrisé, le reste ça ira tout seul !
Pour te dire à l'époque, j'ai tout codé en procédural et le programme a tourné sans intervention pendant plus de 5 ans !
Juste le BDE\Paradox qui fatiguait au bout de 10 000 000 de SQL ou Edit\Insert\Post, ça tenait environ 25h non-stop ou 3 journées de 8h après Ecran Bleu et fichier Index Corrompu (avec le reboot auto de Win2K)

[Invité]

Si tu débutes en Delphi, tu devrais lire les tutoriels sur l'instanciation dynamique des objets en Delphi (appeler manuellement le constructor sans passer par une Form ou un DataModule)
Ainsi que t’intéresser à l'affectation d'un Gestionnaire d’Événement à la volée en RunTime

Je suis en train de lire qq tuto sur le sujet, mais je ne suis pas très familié (une grosse quiche en fait...) avec la POO (Prog. orienté objet). D'où ma préférence pour la sélection de composant sur la palette de l'IDE, qui me simplifie grandement la tâche. Je m'en rends encore plus compte maintenant...
Les docs parlent de création de composant, alors que moi je veux juste appeler un composant existant. Ça devrait être moins compliqué normalement non?

Bref, je voudrais un petit exemple de code qui "appelle" un composant existant, de la même manière que si on avait ajouté le bloc dans la Form, sans vouloir modifier de propriété, ou ajouter des fonctions... Je veux juste utiliser l'existant, mais pouvoir aussi l'instancier des centaines de fois...

[ShaiLeTroll]

Tu dois absolument maitrise cela pour aller plus loin !
Lorsque tu devrais manipuler les Threads, les ThreadList et les pointeurs, cela se bien pire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
var
  Socket: TClientSocket;
begin
  Socket := TClientSocket.Create(Self); // Free par la Form si tu mets cela dans un code d'une fenêtre,
  Socket.Address := '123.045.067.089';
  Socket.Port := 12345;
  Socket.OnRead := SocketReadEventHandler; // déclarer une fonction privée respectant le prototype de TSocketNotifyEvent
  Socket.Open();
end;

Ce code dans une boucle For et tu peux l'invoquer 100 fois !
Tu pourrais utiliser un "array[1..100] of TClientSocket" pour stocker tes objets !
En réalité, une TObjectList est plus souple mais nécessite du transtypage !

[Invité]

Pour conclure la question, j'ai fait 2 applis (1 serveur et un client) pour tester la limite maximum du nombre de sockets pouvant être géré par un serveur.

Je suis monté à 2000 sockets, mais passé les 1450, le compteur "Server.Socket.ActiveConnections" n'est plus très fiable. En testant l'écriture sur ces sockets, il y a des erreurs sur quelques sockets dans les dernières centaines. Donc au final, il y a plusieurs dizaines de sockets qui sont défecteuses...
Alors je me suis donné une limite de 1500 sockets pouvant être gérées par le serveur, en mode non-bloquant et sans thread. Si un jour on a besoin de plus, on montra un autre serveur...
Je vais utiliser uniquement un thread ou 2, pour gérer les lectures / écritures côté base de données MySQL.
Je continue les tests, bien sur, mais cette solution à l'air de convenir...