IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Web & réseau Delphi Discussion :

Notifications entre machines


Sujet :

Web & réseau Delphi

  1. #1
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : janvier 2006
    Messages : 621
    Points : 1 259
    Points
    1 259
    Par défaut Notifications entre machines
    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é...
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  2. #2
    Expert éminent sénior
    Avatar de ShaiLeTroll
    Homme Profil pro
    Développeur C++\Delphi
    Inscrit en
    juillet 2006
    Messages
    12 087
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Développeur C++\Delphi
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2006
    Messages : 12 087
    Points : 21 258
    Points
    21 258
    Par défaut
    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)
    Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
    Attention Troll Méchant !
    "Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
    Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
    L'ignorance n'excuse pas la médiocrité !

    L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
    Il faut avoir le courage de se tromper et d'apprendre de ses erreurs

  3. #3
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : janvier 2006
    Messages : 621
    Points : 1 259
    Points
    1 259
    Par défaut
    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.
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  4. #4
    Expert éminent sénior
    Avatar de ShaiLeTroll
    Homme Profil pro
    Développeur C++\Delphi
    Inscrit en
    juillet 2006
    Messages
    12 087
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Développeur C++\Delphi
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2006
    Messages : 12 087
    Points : 21 258
    Points
    21 258
    Par défaut
    Citation Envoyé par arkhamon Voir le message
    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 !

    Citation Envoyé par arkhamon Voir le message
    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)

    Citation Envoyé par arkhamon Voir le message
    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 ...
    Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
    Attention Troll Méchant !
    "Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
    Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
    L'ignorance n'excuse pas la médiocrité !

    L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
    Il faut avoir le courage de se tromper et d'apprendre de ses erreurs

  5. #5
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : janvier 2006
    Messages : 621
    Points : 1 259
    Points
    1 259
    Par défaut
    Citation Envoyé par ShaiLeTroll Voir le message
    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.


    Citation Envoyé par ShaiLeTroll Voir le message
    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...

    Citation Envoyé par ShaiLeTroll Voir le message
    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...
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  6. #6
    Expert éminent sénior
    Avatar de ShaiLeTroll
    Homme Profil pro
    Développeur C++\Delphi
    Inscrit en
    juillet 2006
    Messages
    12 087
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Développeur C++\Delphi
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2006
    Messages : 12 087
    Points : 21 258
    Points
    21 258
    Par défaut
    Citation Envoyé par arkhamon Voir le message
    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 !
    Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
    Attention Troll Méchant !
    "Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
    Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
    L'ignorance n'excuse pas la médiocrité !

    L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
    Il faut avoir le courage de se tromper et d'apprendre de ses erreurs

  7. #7
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : janvier 2006
    Messages : 621
    Points : 1 259
    Points
    1 259
    Par défaut
    Citation Envoyé par ShaiLeTroll Voir le message
    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
    Ah ouais j'avais pas pensé à ça... Ca transformerait mon "installation " en 1 client et 2000 serveurs... Oublions...


    Citation Envoyé par ShaiLeTroll Voir le message
    Dans ce cas, c'est plus un multicast qu'il faudrait faire !
    Je n'ai aucune connaissance à ce sujet !
    Ca je connais mieux. Le soucis du multicast, c'est que c'est pas sécurisé comme TCP : il peut y avoir perte de paquets en cas de congestion du réseau. Et moi je peux pas me permettre de perdre des paquets, ni qu'ils arrivent incomplets. Et puis niveau gestion c'est un peu plus touchy...
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  8. #8
    Expert éminent sénior
    Avatar de ShaiLeTroll
    Homme Profil pro
    Développeur C++\Delphi
    Inscrit en
    juillet 2006
    Messages
    12 087
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Développeur C++\Delphi
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2006
    Messages : 12 087
    Points : 21 258
    Points
    21 258
    Par défaut
    Ton WAN n'est pas en VPN, tu as plusieurs sites sans aucun rapport les uns des autres ?
    Un multi-cast en WAN, ça doit faire du bruit non ?
    Comment le serveur retrouve tes "abonnés" ?
    Car si c'est de l'UDP en gros n'importe qui peu "écouter" ce qui ce dit ?

    Je ne pratique que le TCP, j'ai vraiment du mal avec les modes non connectés.

    Tu oublies en plus le multi-thread, tu peux ouvrir plusieurs connexions en même temps et envoyer un message à plusieurs socket en même temps depuis le serveur

    Un Cloud par exemple utilise une archi réparti, tu n'as pas un seul serveur mais des milliers qui collaborent !

    Pense que seuls ceux qui auront lancé ton programme seront connectés !
    Rien n'empêche que ton programme au lieu d'utiliser une connexion permanente, se connecte toutes les minutes sur le serveur pour voir si il y a des messages qui lui sont destinés (un sorte de boite aux lettres)

    Tu peux aussi faire des serveurs intermédiaires, un programme serveur qui tourne à Paris, Londres, Nouillorque...
    Ces serveurs intermédiaires gèrent un pool de client sur un LAN d'un site
    Tu as un serveur global WAN qui lui ne reçoit les connexions que des serveurs intermédiaires
    Ainsi le nombre de connexion reste raisonnable et cela peut rester en TCP pour garantir la réception !

    En fait, ces "serveurs intermédiaires" ne seraient que ni plus ni moins des "routeurs" !

    Sinon, je pense que des logiciels de notification d'entreprise de ce genre doivent déjà exister comme MIR3 Intelligent Notification , MIR3 Mass Notification for Manufacturing and Supply Chain, Honeywell Mass Notification
    Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
    Attention Troll Méchant !
    "Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
    Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
    L'ignorance n'excuse pas la médiocrité !

    L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
    Il faut avoir le courage de se tromper et d'apprendre de ses erreurs

  9. #9
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : janvier 2006
    Messages : 621
    Points : 1 259
    Points
    1 259
    Par défaut
    Citation Envoyé par ShaiLeTroll Voir le message
    Ton WAN n'est pas en VPN, tu as plusieurs sites sans aucun rapport les uns des autres ?
    Je pourrais te le dire, mais après je serais obligé de te tuer...
    En fait, y a plusieurs sites reliés entre par de l'intersite genre LS... Donc on peut considérer que c'est un super grand LAN avec des gros routeurs...

    Citation Envoyé par ShaiLeTroll Voir le message
    Un multi-cast en WAN, ça doit faire du bruit non ?
    Non pas forcément. Tout se passe dans le silence feutré des salles informatiques... Désolé... Non en fait car le routeur connait ses abonnés, donc il n'envoie que vers les ports abonnés.

    Citation Envoyé par ShaiLeTroll Voir le message
    Comment le serveur retrouve tes "abonnés" ?
    En général, il ne les connait pas justement. Dans certains cas il les connait mais la "normalité" est qu'il ne les connait pas. C'est les routeurs qui font le boulot via un protocole IGMP : quand un poste s'abonne a un sujet, il envoie une demande d'inscription sur une adresse multicast 224.x.x.x et plus et le routeur enregistre ca dans ses tables. Ensuite, il envoie les bonnes infos vers les bons ports physiques. En théorie, car souvent la demande d'abonnement à un sujet passe par une autorisation d'un serveur. Ca permet de sécuriser et de s'assurer de qui peut lire les infos ou pas.

    Citation Envoyé par ShaiLeTroll Voir le message
    Car si c'est de l'UDP en gros n'importe qui peu "écouter" ce qui ce dit ?
    non justement on ne peut pas écouter car on ne reçoit pas : le routeur n'envoie une trame multicast que vers les postes abonnés. C'est comme ça que fonctionne la télé à la demande.

    Citation Envoyé par ShaiLeTroll Voir le message
    Je ne pratique que le TCP, j'ai vraiment du mal avec les modes non connectés.
    Si ça peut te rassurer, moi aussi...
    Citation Envoyé par ShaiLeTroll Voir le message
    Pense que seuls ceux qui auront lancé ton programme seront connectés !
    Rien n'empêche que ton programme au lieu d'utiliser une connexion permanente, se connecte toutes les minutes sur le serveur pour voir si il y a des messages qui lui sont destinés (un sorte de boite aux lettres)
    Non ça je peux pas faire, j'ai besoin que les notifs déboulent en temps réel.

    Citation Envoyé par ShaiLeTroll Voir le message
    Sinon, je pense que des logiciels de notification d'entreprise de ce genre doivent déjà exister comme MIR3 Intelligent Notification , MIR3 Mass Notification for Manufacturing and Supply Chain, Honeywell Mass Notification
    Trop cher mon fils...
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

Discussions similaires

  1. Types des reseaux entre machines linux ?
    Par donkeyquote dans le forum Réseau
    Réponses: 15
    Dernier message: 20/11/2008, 12h24
  2. Réponses: 7
    Dernier message: 13/05/2008, 09h36
  3. Partager dossiers entre machines GNU/Linux
    Par Thrystan dans le forum Réseau
    Réponses: 7
    Dernier message: 21/08/2006, 08h33
  4. Réponses: 1
    Dernier message: 02/05/2006, 21h33
  5. [ netstat ] surveillance entre machines pour demon mysql
    Par gogozep001 dans le forum Développement
    Réponses: 2
    Dernier message: 28/08/2003, 11h05

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo