Discussion :

[Roger_Rabbit]

Bonjour,

je ne sais pas si je me pose la bonne question par rapport à mon problème, mais je pense qu'ici est le bon endroit pour obtenir une réponse ou la bonne question.

J'ai développé une application Client/Serveur TCP/IP sur des machines équipées d'OS différents (MacOs / WinXP), le Serveur étant hébergé sur la machine Windows et développé autour de l'API CAsyncSocket.
Je n'ai pas (ou plus) de problème de communication, et mes échanges se passent sans problème.

J'en viens au point qui m'intéresse, et qui concerne la connection/reconnection du client :

Le fonctionnement de la connection de chaque client se passe ainsi :
1 - Je mets mon Serveur à l'écoute
2 - Mon client demande à se connecter
3 - CAsyncSocket::OnAccept() est déclenchée
4 - et ensuite...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
   if (IDYES ==AfxMessageBox ("Do you want to accept the incoming connection", MB_YESNO))
{
		Accept(*m_Client);
		CString tmpStr;
		UINT tmpPort;	
		m_Client->GetPeerName(tmpStr,tmpPort);

//(...) (utilisation de ces infos)

}

Ici, je connais l'adresse du client une fois que sa demande de connection a été acceptée... Or, je shouhaiterais, une fois que la connection a été établie une première fois, sauvegarder cette adresse afin de la comparer ultérieurement en cas de renouvellement de connection (si la connection a été interrompue entre temps), et ce AVANT de faire le accept.
Or, si je fais GetPeerName() sur mon serveur avant le Accept(...), je reçois une chaîne vide...
Je suppose que d'une façon ou une autre, l'adresse du client qui demande la connection est forcément disponible... mais je ne sais pas comment accéder à cette information.

Est-ce que vous avez une idée?

PS : la seule idée qui me venait à l'esprit était de faire le Accept, puis de vérifier, et de faire un close() directement derrière après comparaison des IPs.
Mais ça ne me semble pas une solution "propre"...

[nouknouk]

Salut,

ceci pourra peut-être t'aider sous windows.

Sinon, tu as toujours la possibilité de te programmer quelque chose pour appliquer dynamiquement des règles à ton firewall.

Mais sinon, je vois peu de raisons pour éviter de faire un accept et un close juste après. Si c'est par exemple, pour prévenir une attaque par DoS, il me semble plus pertinent de fermer automatiquement la socket d'écoute pendant quelques temps et la réouvrir ensuite.

[Roger_Rabbit]

Merci de ta réponse, nouknouk.

sur la page que tu m'as indiquée, tout semble dire "ne m'utilisez pas".... Je vais quand même y jeter un oeil plus approfondi même je suis assez sceptique sur cette option car elle semble destinée à des applications très pointues (qui prennent en charge à la place du protocole réseau l'ensemble de la sécurité).

La raison pour laquelle je voulais confirmation avant d'accepter était plutôt dûe au fait que des clients différents pouvaient demander la connection, que l'admin du Serveur (qui n'est pas complètement automtique comme vous avez pu le constater) peut décider à sa guise d'accepter ou rejeter . Comme c'est conditionné par l'humeur de l'administrateur, je ne peux pas bloquer au niveau du firewall (peut-être que je me trompe sur ce point car je n'en suis pas du tout expert) et souhaite donc le faire au cas par cas au niveau du programme.

[nouknouk]

re,

sur la page que tu m'as indiquée, tout semble dire "ne m'utilisez pas"

Probablement parce qu'en règle générale, on fait l'accept et on vérifie ensuite, quitte à clore la connexion si on la refuse finalement

Dans ton cas, pourquoi ne pas faire un accept et mettre la socket tout juste créée en "quarantaine" (ie. tout ce qui est reçu par elle n'est pas pris en compte) le temps de décider si on finit par autoriser la connexion ou pas.
Si c'est ok, on la sort de la zone de quarantaine pour l'utiliser ; sinon on la déconnecte.

[Roger_Rabbit]

C'est ce que je fais actuellement, en effet (messages désactivés tant que l'admin n'a pas validé la connection).
Je pensais la solution "sale", mais il semble en effet que ça soit la façon de faire car tu n'es pas le seul à me l'avoir suggérée.
Je crois donc que je vais conserver cette option.

Je te remercie beaucoup pour ton aide.