J'ai créé un serveur de com avec INDY 10. Mon soucis est que je ne vois pas comment identifier une ou plusieurs applications clientes qui se connectent même si elles sont exécutées sur le même poste et plusieurs fois.
Je ne sais pas si je suis très clair ..
Merci à vous deux mais ce n'est pas ce que je recherche. J'aurais besoin de savoir dés la connexion(TServerTCP.ServerConnect(AContext: TIdContext)), qui se connecte. Je sais récupérer l'adresse IP avec "AContext.Binding.PeerIP" mais je souhaiterais pouvoir en plus identifier l'application qui se connecte car je peux avoir plusieurs app clientes différentes qui auront donc la même adresse IP.
Ca n'a aucun sens, une adresse IP est par définition unique. Si tu veux qu'il y ait plusieurs connexions TCP par poste, alors il faut que les connexions TCP fournissent un attribut de connexion matérialisé par un nombre (genre "1" pour telle chose, "2" pour une autre, ...). Mais en règle générale, une application bien construite ne doit pas gérer plusieurs connexions venant d'un même poste !! Peux-tu détailler ton projet afin de voir s'il ne peut pas se simplifier ?
- 1 appli "serveur de com" qui dialogue avec une dizaine d'automates
- 1 appli "CONTROLE" qui gère l'ensemble des flux
- des appli "SAISIE" qui permettent l'entrée des produits
Sur la machine principale, tournent "serveur de com" + "CONTROLE" et parfois "SAISIE". Dans ce cas, j'ai besoin d'identifier(je pourrais le faire dans mon protocole mais par curiosité...)l'application qui se connecte au serveur de com autrement que par l'adresse IP qui est forcément identique.
Eh bien, tu peux accepter la connexio, demander à l'application d'envoyer un "flag d'identification" (partie du protocole), le traiter, et décider quoi faire après ... et chaque flag aurait une valeur unique pour chaque application ?
C'est la question que je me posais justement, peut-on passer un paramètre à la connexion ? Je ne sais pas ... peut-être dans certains protocoles spécialisés ?
Je n'ai peut-être rien compris, mais il ne me semble pas logique de confier au serveur des gestions qui peuvent très bien se faire au niveau client... Ce n'est pas logique et surtout pas performant.
Maintenant, si ce n'est qu'une question de curiosité, c'est un autre problème... ^^