Pb avec TSocketServer

Bonjour

Delphi 2010 :
J'ai 1 PC (serveur) qui doit communiquer avec 2 autres par socket.
Ne pouvant pas modifier les softs des 'Clients' (sous Android), je souhaite utiliser un port spécifique pour chacun d'eux, afin de ne pas mélanger les messages.

Quand j'implémente un seul composant TServerSocket sur le PC serveur, tout se passe bien, mais je ne peux forcément dialoguer que sur un port unique.
Si je tente d'implémenter un second TServerSocket (écoutant un port différent), il ne fonctionne pas. Seul le premier créé fonctionne !
La seconde demande de connexion n'est même pas repérée...

Est-ce normal, ou bien je m'y prends comme un manche ? :?

Merci d'avance
Amicalement, Champy

Pour en avoir utiliser 6 en même temps en D6, je peux te dire que cela fonctionnait très bien à l'époque
Tu as du mal configurer quelque choses !
Le Firewall ?
Tu as mis les gestionnaires Accept et Read

Citation:

---

Envoyé par Champy_33

, je souhaite utiliser un port spécifique pour chacun d'eux, afin de ne pas mélanger les messages.

---

Si c'est le client qui émet une requête et le serveur qui répond
Pense que si tu codes bien ton TServerSocket, tu peux associer un message avec le Handle du Socket qui a émis le message, et te servir de celui-ci pour émettre la réponse


Si le serveur prend l'initiative du dialogue, c'est difficile de savoir à qui envoyer un message

Citation:

---

Envoyé par ShaiLeTroll

Si le serveur prend l'initiative du dialogue, c'est difficile de savoir à qui envoyer un message

---

Et même plus, si le serveur prend l'initiative du dialogue, c'est que c'est un client (du moins pour cette partie du protocole) .

Merci beaucoup

Je me doute que ça devrait marcher. Mais malheureusement, c'est 'niet' :cry:

Les Firewall sont stoppés sur les 3 PC.
Les 2 TServerSocket sont implémentés exactement de la même manière, mis à part le numéro de port écouté, et c'est le même code pour les deux (je fais le distingo dans les procédures en me servant du 'Sender').
Les procédures marchent impeccable quand il n'y a qu'un seul SocketServer. Le problème doit donc logiquement se situer ailleurs.

Le composant TServerSocket étant un peu ancien (il me semble qu'il date de Delphi 3 -1997...), n'y aurait-il pas une incompatibilité avec Win 7, ou bien avec Delphi 2010 ?

Malheureusement, je n'ai plus Delphi 7, pour faire un essai...

Pour préciser le but, le PC 'Serveur' gère une animation OpenGL qui varie en fonction des messages transmis par les 2 clients. Il renvoie aussi des valeurs aux clients.
C'est un peu comme un jeu en ligne qui s'adapte aux demandes des joueurs (sauf que c'est plutôt un 'serious game' dans mon cas :mrgreen:).

Je vais tenter le coup avec un Server 'Indi'. Ca lèvera peut-être le doute.

Allez, on verra ça lundi prochain...

Bon WE et encore merci.
Amicalement, Champy

Citation:

---

Envoyé par ram-0000

Et même plus, si le serveur prend l'initiative du dialogue, c'est que c'est un client (du moins pour cette partie du protocole) .

---

quand je parlais de prendre "l'initiative du dialogue", j'ai peut-être mal choisi mon terme
Je voulais dire que le serveur décide d'envoyer une trame à tous ses clients connectés et non qu'il décide lui même de se connecter !

J'opposais un GET\RESPONSE typique d'un dialogue client\serveur
à un KeepAlive ou à une émission cyclique d'état par exemple,
le serveur tous les n secondes émets une trame de sa propre initiative !

Pour ma part, j'ai eu cette situation, comme j'avais plusieurs clients, seuls une partie souhaitais s'abonner à un event, lors de la connexion, le client émettait une trame d'identification et d'abonnement

ce qui donnait un dialogue de la forme, IDT->\ABON->\<-CONFIRM\<-EVENT\<-EVENT\<-EVENT....
client->server
server<-client

Citation:

---

Envoyé par Champy_33

(je fais le distingo dans les procédures en me servant du 'Sender')

---

Si tu arrives à bien gérer Sender + SocketHandle, oublie les 2 ports !
Tu ne peux pas ouvrir autant de port que tu as de clients !

Je ne vois pas ce qui te pose problème avec un seul TServerSocket

Par contre, TServerSocket a été déprécié un moment,
aujourd’hui, c'est moins clair et il a en plus été migré en Unicode !

Alors que peut-être, il n'apprécie pas Win7 !

Tes deux TServerSocket sont bien en NonBlocking ?
Tu n'as pas oublié le Active à true :roll: ?

Re

En réalité, chaque client se connecte au serveur pour ouvrir sa session.
Le serveur peut distinguer chaque client (ne serait-ce qu'avec l'IP d'emission) afin de les 'trier les patates'. ;).

En revanche, le serveur doit répondre individuellement à chaque client (en fonction du contexte) sans que les autres clients ne reçoivent ce message.

C'est finalement ça que je ne sais pas faire en n'utilisant qu'un seul port.

Merci
Amicalement, Champy

Bon moi pour des manips similaires j'utilises les composants ICS. Tu as des exemple de serveur TCP lequel crée une instance à chaque client connecté, tous se connectent sur le même port.

Bonsoir et merci Philnext.

Ah oui, je me souviens...
ICS, c'était une collection de composants éditée par un certain M Pètre (ou un nom un peu comme ça) il y a déjà une quinzaine d'années. De mémoire, ce monsieur était belge, particulièrement doué et très convivial.
Il me semble qu'il proposait de partager ses composants en échange d'une simple carte postale !
Avec la conjoncture actuelle, ça a peut-être changé...

Je ne sais pas si cette collection existe encore et, surtout, si elle est compatible avec Win 7 et Delphi 2010.
Je vais chercher, parce que mon boss commence à bouillir (il doit faire une importante démo le 15 août en Australie, aboutissant normalement à quelques contrats, et la pression monte doucement :mouarf:).

Bon, la fonctionnalité que je recherche n'est pas primordiale, mais elle fait partie du cahier des charges et il vaudrait mieux que ça marche, ne serait-ce que pour mon humble avenir... :ccool:

Bref. Dans tous les cas, merci pour ton conseil.

@+
Amicalement, Champy

ICS c'est toujours, une bibliothèque crée et maintenue par F Piette, compatible avec la majorité des versions de Delphi, avec l'avantage d'être livrée avec tous les exemples classiques de serveurs et clients.
En 5 mn tu installes la bibliothèque et tu crées un serveur TCP multiclients fonctionnel, que tu trouves dans :
..\OverbyteIcsV7\Delphi\Internet\OverbyteIcsSrvDemo.dpr

Pour les conditions elles n'ont pas changé...

Citation:

---

ICS is freeware. You can use it without paying anything except the registration
postcard (see "register" below). But of course donations are welcome.

---

La suite ici : http://www.overbyte.be/

Ouiiii !

J'ai trouvé le lien qui gaze.
Je teste ça dès lundi...

Encore merci
Amicalement, Champy

Dénouement un dimanche.

Ca ne me ressemble pas, mais bon, il fait tellement chaud dehors que j'en ai profité pour faire quelques tests à la maison.

Ne vous cassez plus la tête. J'ai ré-implémenté une appli 'Serveur/Client' toute simple et il n'y a aucun problème pour ouvrir plusieurs TServerSocket avec un port différent pour chacun.
Donc, comme prévu, ça marche, et ça me simplifie énormément la tache.

Il doit y avoir un 'sac' quelque part dans le code de mon appli (en réalité, un plugin pour UcWinRoad). Je vais faire son autopsie dès demain.

Pour les plus curieux, voici un lien sur sa présentation (2 ans de boulot...) :
http://www.youtube.com/watch?feature...&v=rFBfSaHXaD4

Un des buts de la future version est de contrôler certaines fonctionnalités en temps réel avec de vulgaires tablettes tactiles (sous Android).

Je ne sais pas comment on déclare ce sujet comme résolu, et j'invite un modo à le faire pour moi.

Merci pour tout et @ la prochaine
Amicalement, Champy

Citation:

---

Envoyé par Champy_33

Dénouement un dimanche.

Ca ne me ressemble pas, mais bon, il fait tellement chaud dehors que j'en ai profité pour faire quelques tests à la maison.

Ne vous cassez plus la tête. J'ai ré-implémenté une appli 'Serveur/Client' toute simple et il n'y a aucun problème pour ouvrir plusieurs TServerSocket avec un port différent pour chacun.
Donc, comme prévu, ça marche, et ça me simplifie énormément la tache.

Il doit y avoir un 'sac' quelque part dans le code de mon appli (en réalité, un plugin pour UcWinRoad). Je vais faire son autopsie dès demain.

Pour les plus curieux, voici un lien sur sa présentation (2 ans de boulot...) :
http://www.youtube.com/watch?feature...&v=rFBfSaHXaD4

Un des buts de la future version est de contrôler certaines fonctionnalités en temps réel avec de vulgaires tablettes tactiles (sous Android).

Je ne sais pas comment on déclare ce sujet comme résolu, et j'invite un modo à le faire pour moi.

Merci pour tout et @ la prochaine
Amicalement, Champy

---

sympa ce produit, ça doit être motivant de bosser sur ce genre de choses :)

Ouaip, le produit est sympa, mais la programmation de ce plugin est loin de l'être, sachant que je n'ai pas le code source de l'appli principale, que le SDK est très 'opaque' et qu'il n'est pratiquement pas documenté (sinon en japonais .!.)

Bon, après moult galères, le résultat tient maintenant relativement bien la route. Mon boss l'a vendu en France, Australie et Japon, en attendant quelques commandes du Canada, Irlande et Nouvelle Zélande.

Ce n'est pas encore la référence en terme de 'tunnel safety', mais ça progresse dans ce sens.
Quelques récompenses :
http://www.bmia.fr/bmia_presse.php )

Nous ne sommes que 7 dans cette petite boîte et je bosse maintenant tout seul sur ce projet. Notre seule concurrence est aux USA.
Pour l'instant, elle est bien en dessous de notre produit :mrgreen:
Néanmoins, je suppose que les MacDo vont rapidement réagir.

Il faut donc qu'on garde toujours une longueur d'avance...

Amicalement, Champy

Citation:

---

Envoyé par Champy_33

Ouaip, le produit est sympa, mais la programmation de ce plugin est loin de l'être, sachant que je n'ai pas le code source de l'appli principale, que le SDK est très 'opaque' et qu'il n'est pratiquement pas documenté (sinon en japonais .!.)

Bon, après moult galères, le résultat tient maintenant relativement bien la route. Mon boss l'a vendu en France, Australie et Japon, en attendant quelques commandes du Canada, Irlande et Nouvelle Zélande.

Ce n'est pas encore la référence en terme de 'tunnel safety', mais ça progresse dans ce sens.
Quelques récompenses :
http://www.bmia.fr/bmia_presse.php )

Nous ne sommes que 7 dans cette petite boîte et je bosse maintenant tout seul sur ce projet. Notre seule concurrence est aux USA.
Pour l'instant, elle est bien en dessous de notre produit :mrgreen:
Néanmoins, je suppose que les MacDo vont rapidement réagir.

Il faut donc qu'on garde toujours une longueur d'avance...

Amicalement, Champy

---

il faut sous-traiter ... suivez mon regard ;)

Citation:

---

Envoyé par Champy_33

En revanche, le serveur doit répondre individuellement à chaque client (en fonction du contexte) sans que les autres clients ne reçoivent ce message.

C'est finalement ça que je ne sais pas faire en n'utilisant qu'un seul port.

---

Tu n'as pas lu ce lien que j'ai fourni dès le début : Handle du Socket
Cela fourni un exemple de dispatch de message vers le bon destinataire !
Faut juste faire un peu d'effort, j'ai fait ce code alors que j'étais encore qu'un apprenti, c'est donc largement à ta portée !

Il suffit de boucler sur ServerSocket.Socket.Connections[i] et de retrouver la bonne cible en fonction de l'IP ou du SocketHandle


Mais si tu as procédé autrement 8O , c'est donc :resolu: ?
Le bouton est juste en bas ! :roll:

Merci Shai

La méthode que tu indiques marche bien sûr, mais elle n'est pas adaptée dans ce cas, parce que les clients peuvent s'envoyer des messages entre-eux (en étant sur un port unique).
Ce qui n'est pas souhaitable, vu que la trame des messages n'indique pas 'qui' est destinataire.

@+
Amicalement, Champy

un client NE PEUT PAS envoyer directement de message à un autre client !

un client envoie au serveur et uniquement à lui !

le serveur peut envoyer un message au client qu'il souhaite
le serveur peut donc servir de relais entre deux clients qui souhaitent échanger des messages

Le serveur même sur un seul port à le contrôle de tout ce qui rentre et sort !

Dans un chat par exemple, le client envoie le message au serveur
c'est le serveur qui s'occupe de dispatcher le message vers les clients du #channel concerné et évidemment en retirant le client auteur du message

Le lien entre deux TClientSocket via un TServerSocket n'est pas automatique, c'est au développeur de créer son système de relais si nécessaire !

Soit je ne comprends pas ce que tu écrits
Soit tu supposes des choses qui n'existent pas et qui t'embrouillent la tête


Autre approche :

Si deux clients doivent discuter entre eux SANS serveurs !
Là c'est différents, c'est qu'en réalité le programme embarque :
- un ou plusieurs TClientSocket pour se connecter à chaque autres programmes
- un TServerSocket pour accepter les connexions des autres programmes

Tu peux lancer un TServerSocket sur un Port et lancer des TClientSocket sur le même port connecté sur d'autres IP (il peut même se connecter sur le localhost)


J'ai l'impression que dès le début tu as mal expliqué ta problématique

en effet, tout cela ne semble pas très clair...j'ai rédigé un article sur le sujet.

en résumé, il ne faut pas confondre le numéro de port et le socket.

si j'ai 10 clients qui accèdent au même serveur sur le même numéro de port, ils auront un socket différent au niveau du serveur. Chaque socket recevra les données d'un client sans confusion possible avec les autres. De même le serveur s'adresse à chaque client via son socket spécifique, pour envoyer la même information à tous les clients, il faut l'envoyer une fois sur chaque socket.

Le serveur possède un socket qui est à l'écoute (listen) et à chaque connexion, la fonction accept crée un nouveau socket pour dialoguer avec ce client en particulier.

Merci à vous, chers experts.

Ma phrase d'introduction était donc justifiée : '...ou bien je m'y prends comme un manche.'.

J'ai bien compris vos explications et j'ai trouvé la 'faille' ce matin (une boucle où j'avais stupidement oublié un 'break' :cry:).
Avec 2 TServerSocket gérant chacun un port différent, ça marche 'impec'.
Ca me suffit.
Il existe sûrement des méthodes plus 'académiques', mais je n'ai pas le temps de m'y attarder (l'échéance est pour le 15 août). Il faut que ça marche, et très vite !
De plus, cette fonctionnalité ne concerne qu'1/100ème du cahier des charges...

Donc, encore merci. Je garde la tête dans le guidon pour la suite mais je suis moins inquiet, car c'est une partie que je maitrise bien mieux.

Dans le futur, je n'hésiterai pas à vous demander conseil si besoin, sauf que j'essayerai d'exposer le problème du mieux possible.

En attendant, je change de braquet et c'est reparti :ccool: (heureusement que mon burlingue est climé, becoze on a presque 40° à l'ombre à Bordeaux... Étouffant !)

@+
Amicalement, Champy