TServerSocket : Limiter la création de Thread ssi adresse IP valide
donrolando
Messages postés2Date d'inscriptionvendredi 13 octobre 2006StatutMembreDernière intervention22 novembre 2006
-
21 nov. 2006 à 15:31
Utilisateur anonyme -
22 nov. 2006 à 17:12
Bonjour,
Je cherche à savoir comment on peux empécher le composant TServerSocket en mode threadblocking de crée un thread TserverClientThread, par exemple, si l'adresse du client n'est pas dans notre liste d'adresse autorisée !
J'ai essayé en mettant SocketThread=nil ou même SocketThread.Free mais ça ne fonctionne apparamment pas ?
A moins qu'il ne faille le faire dans un autre évènement de TServerSocket ??
Quelqu'un aurait-il une piste ???
Voici le code de l'évènement OnGetThread
Procedure TForm1.ServerSocketGetThread(Sender: TObject;
ClientSocket: TServerClientWinSocket;
Var SocketThread: TServerClientThread);
var
mIP:String;
ER:TER;
i:Integer;
Begin
mIP:=ClientSocket.RemoteAddress;
//Parcours d'une liste d'objet Clients IP (balises)
For i:=0 to mERList.Count-1 do begin
ER:=(mERList.Items[i] as TER);
if ER<>nil then begin
if ER.IP=mIP then begin
LOG('Balise déclarée '+mIP);
//Adresse IP trouvé dans la liste => Création du thread (TERServerThread descendant de TServerClientThread)
SocketThread := TERServerThread.Create(ClientSocket,MenuFile,ListBox1.Handle);
Exit;
end;
end;
end;
//IP non trouvée dans la liste, QUE FAIRE pour ne pas créer de thread ????
LOG('Cette balise n'est pas déclarée !!!');
SocketThread:=nil; //Ne fonctionne pas !(L'évènement OnThreadStart a lieu !!)
OU
SocketThread.Free; //Ne fonctionne pas !(L'évènement OnThreadStart a lieu !!)
OU
UNE IDEE S'IL VOUS PLAIT !!!!
"Je cherche à savoir comment on peux empécher TServerSocket en mode threadblocking de crée un threadsi l'adresse du client n'est pas dans notre liste d'adresse autorisée !".
Je cite : "
Comment le serveur gère t-il les threads clients ?
Les serveurs Indy basés sur TCP ont à peu près tous le même fonctionnement. Par défaut, un thread d'écoute (« Listenner Thread ») est crée et attend les connexions clientes. Dès qu'un client est accepté, le thread d'écoute créé un nouveau thread qui « accueillera » la connexion cliente. C'est dans le contexte de ce thread que sont déclenchés tous les évènements du serveur. Les évènements serveur s'exécutent donc dans des threads différents que le principal thread du programme. Une fois le client déconnecté, le thread client est supprimé par le thread d'écoute."
Ca me semble clair non ? . Il suffit de faire une liste d'adresses IP. Quand une connection est établit, le serveur récupère l'IP du client. Si cette IP n'appartient pas à la liste, tu coupes la connection et le thread est automatiquement supprimé.
donrolando
Messages postés2Date d'inscriptionvendredi 13 octobre 2006StatutMembreDernière intervention22 novembre 2006 22 nov. 2006 à 17:01
Merci pour ton idée Francky mais il ne s'agit pas d'Indy ! (Je sais que Borland déprécie les TServerSocket mais je doit faire avec !)
Mais je vais tester cette piste, celle de créer le thread quand même et de fermer la connection si l'adresse n'appartient pas à la liste !
Style :
(TERServerThread descendant de TServerClientThread)
<hr />
procedure TERServerThread.ClientExecute;
begin
if ClientSocket.RemoteAddress <> monIP then ClientSocket.Close;
sleep(1); //Pour être sur que le socket soit fermé !
while not Terminated and ClientSocket.Connected do
begin
{Code de mon thread}
end;
end;
<hr />
Ce qui m'embète dans cette technique , c'est que la liste d'adresse IP doit être visible du thread.
Peut on VRAIMENT EMPECHER LA CREATION du thread plutôt que de le laisser se créer pour finalement le tuer immédiatement ??
Par contre Indy est en Open Source. Tu devrais télécharger les sources et regarder comment ils ont codé ca ;).
Ce qui m'embète dans cette technique , c'est que la liste d'adresse IP doit être visible du thread. Ben tu peux faire comme Indy : tu créer un thread d'écoute puis en fonction de l'adresse IP tu en crée un autre ou pas.
Par contre tu dis que tu n'as pas le choix que d'utiliser TSocket : Pourquoi ? Meme si le traitement serveur->client est délicat, en terme de possibilité Indy propose les memes possibilités. C'est juste moins facile à coder