Re: problèmes généraux avec les sockets et les threads

trunks Ven 14 Nov 2008 - 12:16

Pour moi, c'est un thread indépendant qui ne sert qu'à déclencher un traitement à l'échéance. Le reste du traitement est fait ailleurs indépendamment (dans un autre thread).

Le reste du traitement est fait ailleurs? d'accord mais il faut quand même pouvoir arrêter l'autre thread dont tu parles (pour le reste du traitement) quand le temps sera arrivé à échéance et je ne vois pas trop comment faire ça. Sois plus explicité stp ou biduille moi un truc pour être plus clair.

Instructions qui font quoi ? Il ne peut pas y avoir 2 fonctions bloquantes dans le même thread...

la réponse de l'autre plus haut suffira prce que c'est la même question dite d'une autre manière.

-ed- Ven 14 Nov 2008 - 12:26

trunks a écrit:Le reste du traitement est fait ailleurs? d'accord mais il faut quand même pouvoir arrêter l'autre thread dont tu parles (pour le reste du traitement) quand le temps sera arrivé à échéance et je ne vois pas trop comment faire ça. Sois plus explicité stp ou biduille moi un truc pour être plus clair.

On peut communiquer entre les threads par des données partagées.

Instructions qui font quoi ? Il ne peut pas y avoir 2 fonctions bloquantes dans le même thread...

la réponse de l'autre plus haut suffira prce que c'est la même question dite d'une autre manière.

Ce que j'ai compris, c'est qu'il y a un thread sur le serveur qui envoie une trame 'temps restant' une fois par seconde :

Code:: echeance := TIME + delai temps := delai DO send (client, temps) DEC temps WAIT 1000 ms WHILE TIME < echeance

trunks Lun 17 Nov 2008 - 21:36

SAlut Emdel,
il a fallu que je disparaisse un temps pour pouvoir remettre de l'ordre dans mes codes. tellement je ne me retrouve plus mais là tout va mieux. J'aurai plus tard d'autres questions à te poser sur le module REC de ta lib (CLIB) que tu me conseilles d'utiliser. Avant ça j'ai une autre inquiétude.

Comment puis je faire pour vérifier si un login est déjà connecté au serveur? Supposons qu'il ya un client qui se connecte avec son login au serveur. Au cas où ce login est déjà connecté, il va falloir lui dire(au second client). J'ai essayé quelques algos de mon côté mais je ne parviens pas. j'ai utilisé les liste chainées ... mais...
Bonne soirée

-ed- Mar 18 Nov 2008 - 2:02

trunks a écrit:il a fallu que je disparaisse un temps pour pouvoir remettre de l'ordre dans mes codes. tellement je ne me retrouve plus mais là tout va mieux. J'aurai plus tard d'autres questions à te poser sur le module REC de ta lib (CLIB) que tu me conseilles d'utiliser. Avant ça j'ai une autre inquiétude.

Je t'ai montré son existence, surtout pour que tu essayes de voir comment ça fonctionne.

Comment puis je faire pour vérifier si un login est déjà connecté au serveur? Supposons qu'il ya un client qui se connecte avec son login au serveur. Au cas où ce login est déjà connecté, il va falloir lui dire(au second client). J'ai essayé quelques algos de mon côté mais je ne parviens pas.

Attention à ne pas se tromper de niveau...

Une connexion TCP/IP est une chose (niveau 4/3), mais une session avec login/mot de passe, c'est du niveau 6. Ca n'a rien à voir et ça se traite à des niveaux différents. On peut très bien avoir une session active alors qu'on est pas connecté (prévoir quand même un timeout). On peut aussi se connecter sans que la session soit ouverte (heureusement...).

Il faut imaginer des scénarios de connexion et de session. Par exemple :

La session est fermée par défaut.
Un client se connecte.
Le serveur enregistre l'adresse IP du client et envoi une demande de login et de mot de passe.
Le login permet au serveur de chercher le mot de passe dans le fichier client et de le vérifier. Si le client est inconnu, une demande d'inscription est envoyée.
Une fois le client identifié, et le mot de passe vérifié, la session est ouverte.
etc.

C'est un protocole, et ça nécessite un gros travail de spécification...

trunks Mer 19 Nov 2008 - 11:38

Attention à ne pas se tromper de niveau...

Une connexion TCP/IP est une chose (niveau 4/3), mais une session avec login/mot de passe, c'est du niveau 6. Ca n'a rien à voir et ça se traite à des niveaux différents. On peut très bien avoir une session active alors qu'on est pas connecté (prévoir quand même un timeout). On peut aussi se connecter sans que la session soit ouverte (heureusement...).

Slt! d'accord! je verrai si c'est si nécessaire que ça. si oui je vais l'apprendre et m'en servir pour les prochaines versions de mon logiciel mais pour l'instant j'ai trouvé une astuce qui me permet de faire ça.
Regarde ce que ça donne:

-Après que le client ait envoyé son login et son password, je lance une requête pour voir si ce login existe déjà dans une table connected (que j'ai créé juste pour l'occasion). Si elle existe alors ça veut dire ce login est déjà connecté (donc le serveur envoie un message "DEJA CONNECTE" au client qui essaie de se reconnecter avec ce login)

- si le login n'a pas été trouvé dans la table connected alors elle l'insère à l'intérieur.

- Quand le client sera déconnecté ou quand le temps sera égal à 0(temps terminé) alors nettoyer de cette table connected ce login et ce mot de passe.

Voilà! ça m'est venu comme ça, j'ai essayé et ça marche. tant mieux pour moi. t'en penses quoi ;-)

bien! je reviendrai pour mes questions. Bonne journée.
Au fait, je te ferai voir après dans quoi ont servi touts tes conseils et j'en suis sûr tu vas adorer. A+ ;)

-ed- Mer 19 Nov 2008 - 11:48

trunks a écrit:Voilà! ça m'est venu comme ça, j'ai essayé et ça marche. tant mieux pour moi. t'en penses quoi

Rien de choquant apparemment, mais il est difficile de voir tous les cas sur le papier. Quand ça devient complexe, je fais une maquette et je fais vivre un peu la chose pour voir si des détails ne m'ont pas échappé.

trunks Sam 22 Nov 2008 - 20:49

Salut emdel, en forme? de retour avec mes eternels petards avec les sockets. le probleme suivant est assez etrange.

pour renforcer mes tests, j'ai decide de faire ceci:
- si par exemple le serveur se ferme brusquement sans prevenir, le client affiche une boite de dialogue et affiche un message du genre "serveur deconnecte" et se ferme
-bien! le bleme est que quand ce meme client qui etait actif avant cet incident tente de se reconnecter au serveur, ca ne marche plus. plus rien ne se passe(plus de decompte de temps, je me demande meme si le thread est cree...) ce client(le login) est condamne.

Voila!
NB: desole pour le manque d' accents dans mon texte, j'ai ecris le message avec un clavier anglais.

-ed- Sam 22 Nov 2008 - 21:14

trunks a écrit:- si par exemple le serveur se ferme brusquement sans prevenir, le client affiche une boite de dialogue et affiche un message du genre "serveur deconnecte" et se ferme
-bien! le bleme est que quand ce meme client qui etait actif avant cet incident tente de se reconnecter au serveur, ca ne marche plus. plus rien ne se passe(plus de decompte de temps, je me demande meme si le thread est cree...) ce client(le login) est condamne.

Suite à la déconnexion par le serveur, il faut que le client, lui aussi, fasse une déconnexion propre (closesocket()) avant de quitter.

trunks Sam 29 Nov 2008 - 21:40

SAlut Emdel,
juste une question en passant! quel est le port le plus adapté pour utiliser les socket? comme dans le cas de mon appli. certains prennent 23, d'autres 3113... Que peux tu me dire sur ça? sur le port conseillé? MErci

-ed- Sam 29 Nov 2008 - 21:50

trunks a écrit:SAlut Emdel,
juste une question en passant! quel est le port le plus adapté pour utiliser les socket? comme dans le cas de mon appli. certains prennent 23, d'autres 3113... Que peux tu me dire sur ça? sur le port conseillé? MErci

Certains ports sont réservés à des applications spécifiques (23 : Telnet)

D'autre part, sur certains systèmes, et pour des raisons de sécurité, on ne peut lancer un serveur sur un port < 1024 que si on est root (administrateur).

Il existe une plage de ports (dans les numéros supérieurs) qui est réservée aux utilisateurs ou aux essais (c'est pas très clair).

http://www.frameip.com/liste-des-ports-tcp-udp/

Contenu sponsorisé