Discussion :

[arkhamon]

Bonjour à tous,

je suis en train de plancher sur une truc et je cale un peu sur certains choix. Explication de ce que je veux faire :

un process va recevoir un certain nombre de messages (notifications) de la part d'un certain nombre de sources.
Ce process va devoir réémettre chacun de ces messages à un certain nombre de postes clients, éparpillés sur un WAN

Le serveur devra potentiellement servir plusieurs centaines de postes. Le nombre de messages à transmettre n'est pas forcément important au début, mais opurrait augmenter si le système devient populaire...


J'ai pensé à plusieurs solutions :

• Multicast, mais il faut passer par des clients lourd (genre RDV) et je ne peux pas choisir cette solution.
• TCP en mode connecté. Le problème c'est le nombre de connexions...
• UDP : il risque d'y avoir des pertes, et du coup ça oblige à gérer des réémissions zet ça complique...
• flux RSS et chaque client s'abonne
• le serveur met à disposition un fichier, et le client va le lire (un fichier par client)

Voila comme c'est aps trop mon domaine au départ (la programmation réseau) je suis un peu paumé...

[ShaiLeTroll]

Pour le TCP, un serveur comme TServerSocket peut gérer 2000 connexions !
En FMX, tu utiliserais surement TIdTCPServer ou TTCPServer (onglet internet, il est cross-plateforme)

On a parlé de cette limite dans un autre sujet, cela peut s'augmenter dans Windows
Ensuite, tu peux penser en répartition de charge !
un client se connecte sur le serveur (juste un frontal), celui-ci lui indique l'IP et le Port d'un autre Serveur
Ainsi, tu dépasse la limite sans problème en "routant\dispatchant" les connexions !
les serveurs répartis discute entre-eux pour qu'un client 1 sur le serveur A puisse notifier le client 2 sur le serveur B



Si tes clients sont accessibles de l'extérieur, tu peux inverser client et serveur !
Le Serveur a une liste d'abonné (IP, URL, en WAN je ne me repère pas trop bien), il se connecte sur chacun, envoie l'info puis se déconnecte
C'est ce que fait VNC ou PC Anywhere, en fait ce que l'on appelle l’Élève est un serveur en attente de connexion du client (le maître)

[arkhamon]

Les postes clients sont dans la même entreprise, masi disséminés un peu partout dans le monde via un WAN.

En fait il y a de fortes chances pour que le serveur soit hébergé sur une machine UNIX. Donc on va dire que la problématique est plus théorique... Un serveur est-il capable de gérer plusieurs miliers de connexions TCP en même temps ?

Ca gène au niveau réseau d'avoir un serveur qui a plus de 2000 connexions ouvertes ? Sachant qu'il est probable que il soit obligé d'émettre un message vers tous ses clients à la fois (j'utilise ça pour un système d'informations en temsp réel sur l'état d'une business chain) ?

Pour le client ca sera beaucoup plus simple : il commencera par ouvrir une connexion TCP avec son serveur, et ensuite il reçoit les messages. L'ordre de réception n'importe pas.

[ShaiLeTroll]

le serveur soit hébergé sur une machine UNIX.

Donc tu vas le coder en autre chose que Delphi !
Pour le TCP, je suppose qu'UNIX a aussi des limites par défaut, peut-être 2000 peut-être 10000, surement configurable dans un fichier .conf

Pour avoir un peu pratiqué Fedora (Linux) et surtout Apache en fait, tu as des options partout, limite de Mo par thread, limite seconde par request ... idem MySQL, Mo par SQL, Mo par BLOB ...
tu dois bien avoir limite Con par IP, Con par Port, Con par seconde ... au niveau de l'OS, faut aimer fouiller !

Ca gène au niveau réseau d'avoir un serveur qui a plus de 2000 connexions ouvertes ?

Ben non, à un moment, ton serveur n'aura plus assez de RAM ou Thread disponibles, il faudra forcément déléguer à un autre serveur les connexions en trop (on en revient à un frontal qui réparti)

Sachant qu'il est probable que il soit obligé d'émettre un message vers tous ses clients à la fois ?

Aucun soucis, même dans un modèle réparti, il suffit de notifier aux serveurs d'envoyer à tous leurs clients, le frontal lui est un chef d'orchestre, les serveurs répartis sont connectés sur lui (ou inversement) !
Le Web c'est fait comme ça, des frontaux et des millions de serveurs, d'ailleurs si le frontal tombe, un serveur peut prendre sa place si éligible à ce rôle ...

[arkhamon]

Donc tu vas le coder en autre chose que Delphi !
Pour le TCP, je suppose qu'UNIX a aussi des limites par défaut, peut-être 2000 peut-être 10000, surement configurable dans un fichier .conf

Pour avoir un peu pratiqué Fedora (Linux) et surtout Apache en fait, tu as des options partout, limite de Mo par thread, limite seconde par request ... idem MySQL, Mo par SQL, Mo par BLOB ...
tu dois bien avoir limite Con par IP, Con par Port, Con par seconde ... au niveau de l'OS, faut aimer fouiller !

effectivement la partie serveur sera probablement codée en autre chose que Delphi si c'est sous Unix.

Ben non, à un moment, ton serveur n'aura plus assez de RAM ou Thread disponibles, il faudra forcément déléguer à un autre serveur les connexions en trop (on en revient à un frontal qui réparti)

Et on peut envisager une ouverture de connexion vers un poste, puis l'envoi, la fermeture de la cx et ainsi de suite sur plusierus milliers de postes ? a mon avis ça va ramer serieusement non ? En fait, j'ai pas forcément besoin de garder la connexion ouverte entre deux envois. Surtout que les envois peuvent très bien ne pas être réguliers...

Aucun soucis, même dans un modèle réparti, il suffit de notifier aux serveurs d'envoyer à tous leurs clients, le frontal lui est un chef d'orchestre, les serveurs répartis sont connectés sur lui (ou inversement) !
Le Web c'est fait comme ça, des frontaux et des millions de serveurs, d'ailleurs si le frontal tombe, un serveur peut prendre sa place si éligible à ce rôle ...

ouais mais là il s'agit pour un serveur d'émettre vers plusieurs miliers de postes le même message et si possible assez rapidement...

[ShaiLeTroll]

Et on peut envisager une ouverture de connexion vers un poste, puis l'envoi, la fermeture de la cx et ainsi de suite sur plusierus milliers de postes ?

Cela suppose que les postes soient accessibles de l'extérieur, cela inverse le rôle ton programme UNIX dans ce cas serait un client se connectant sur une multitude de serveur

Dans ce cas, c'est plus un multicast qu'il faudrait faire !
Je n'ai aucune connaissance à ce sujet !