Multithread sans threads.

Est-ce qu'un serveur peut gerer plusieurs client sans creer un thread par client ?

Comment faisait-on quand les OS n'etaient pas encore multitaches ?

Le multithreading ca marche bien mais j'ai l'impression qu'au niveau performance c'est pas terrible quand il faut gerer plusieurs centaines de connections.

tu ne vas pas faire un thread par client sinon badaboum systeme. Tu en fais un pour la reception et empilage, un pour traitement et autres si besoins mais sur que moins il y en aura mieux sera. Difficile de dire le meilleur compromis, dependra de l'appli et des capacites physiques du serveur.
BruNews, ciao...


-------------------------------
Réponse au message :
-------------------------------

> Est-ce qu'un serveur peut gerer plusieurs client sans creer un thread par client ?
>
> Comment faisait-on quand les OS n'etaient pas encore multitaches ?
>
> Le multithreading ca marche bien mais j'ai l'impression qu'au niveau performance c'est pas terrible quand il faut gerer plusieurs centaines de connections.

Salut,
Oui on peut faire un serveur qui gere plusieurs clientsdans un seur thread.
Mais bon pour gerer plusieurs centaines de client je pense que faire un thread/client est le mieux.



-------------------------------
Réponse au message :
-------------------------------

> Est-ce qu'un serveur peut gerer plusieurs client sans creer un thread par client ?
>
> Comment faisait-on quand les OS n'etaient pas encore multitaches ?
>
> Le multithreading ca marche bien mais j'ai l'impression qu'au niveau performance c'est pas terrible quand il faut gerer plusieurs centaines de connections.

Bonjour, désolé de m'incruster mais j'en profite puisque vous parlez de clients/serveur :)

Mon clients/serveur n'a pas de pile de message, j'ai prévu (ce n'est pas encore fait donc j'en profite) qu'il traite les requêtes des clients directement dans la thread d'écoute, en quoi est-ce pénalysant hormis le fait que ceux qui ceux connectent doivent attendre un peu s'ils arrivent pendant l'exécution d'une requête ?
Est-ce que les piles des sockets sont suffisament larges pour entasser quelques requêtes ? Est-ce que les paquets disparaissent au bout d'un certain timing ?

A force de me poser ces questions je me dis que faire une pile de message est presque obligatoire... en plus c'est un petit peu plus long à faire et à force de déborder du planning ma marge va sauter :/

-------------------------------
Réponse au message :
-------------------------------

> tu ne vas pas faire un thread par client sinon badaboum systeme. Tu en fais un pour la reception et empilage, un pour traitement et autres si besoins mais sur que moins il y en aura mieux sera. Difficile de dire le meilleur compromis, dependra de l'appli et des capacites physiques du serveur.
> BruNews, ciao...

Pas de prob d'incruste au contraire, acceptons tous les avis bien formules.
Tu les dis toi meme, sans thread ceux qui se connectent doivent attendre. Si tu as un thread d'ecoute qui empile les requetes pour au moins un autre qui traite, le client peut au moins recevoir quasi instantane sa notification de position dans la liste, un peu dans le genre edonkey et autres.
BruNews, ciao...


-------------------------------
Réponse au message :
-------------------------------

> Bonjour, désolé de m'incruster mais j'en profite puisque vous parlez de clients/serveur :)
>
> Mon clients/serveur n'a pas de pile de message, j'ai prévu (ce n'est pas encore fait donc j'en profite) qu'il traite les requêtes des clients directement dans la thread d'écoute, en quoi est-ce pénalysant hormis le fait que ceux qui ceux connectent doivent attendre un peu s'ils arrivent pendant l'exécution d'une requête ?
> Est-ce que les piles des sockets sont suffisament larges pour entasser quelques requêtes ? Est-ce que les paquets disparaissent au bout d'un certain timing ?
>
> A force de me poser ces questions je me dis que faire une pile de message est presque obligatoire... en plus c'est un petit peu plus long à faire et à force de déborder du planning ma marge va sauter :/
>
> -------------------------------
> Réponse au message :
> -------------------------------
>
> > tu ne vas pas faire un thread par client sinon badaboum systeme. Tu en fais un pour la reception et empilage, un pour traitement et autres si besoins mais sur que moins il y en aura mieux sera. Difficile de dire le meilleur compromis, dependra de l'appli et des capacites physiques du serveur.
> > BruNews, ciao...

(dsl pour la faute "ceux" -> "se" dans mon message précédent)

:)

Je pense me diriger vers une pile de requête, j'ai encore un peu de mal avec cette idée alors je ne suis pas tout à fait sûr du choix, à première vu ça ne semble pas poser de problème particulier donc je fais mon choix :) comme tu le dis ça apporte quelques plus alors autant ne pas s'en priver.

A seconde vue (je mets du temps pour écrire ma réponse je fais plusieurs choses en même temps) je vois un petit problème :

Le client peut demander un groupe fichiers (sans savoir à l'avance comment il est composé), le serveur lui renvoie le nombre de fichiers qui vont arriver puis le client lui dit "ok envoie", le serveur envoie alors pour chaque fichier un paquet d'information (avec accusé de réception) suivi du fichier avec accusé de réception sur le dernier paquet du fichier.
Ca c'était avec une seule thread, mais avec une pile de requêtes ça sera différent. Déjà je ne peux pas faire de recv() dans la thread de la pile puisque c'est la thread d'écoute qui gère l'arrivée des paquets pour les mettre dans la pile, donc il faut attendre les paquets dans la pile, heuuuu je dois faire ça avec quelle méthode ?
J'ai beau y réfléchir je ne vois pas trop, faut-il que je ramène mes requêtes à des requêtes plus simples du type 1 requête -> 1 paquet réponse (aïe) ? Ou bien dois-je faire attendre ma thread de pile jusqu'à ce que la réponse arrive dans la pile et qu'elle puisse continuer ?


Merci à vous les gars de partager votre expérience : ))

-------------------------------
Réponse au message :
-------------------------------

> Pas de prob d'incruste au contraire, acceptons tous les avis bien formules.
> Tu le dis toi meme, sans thread ceux qui se connectent doivent attendre. Si tu as un thread d'ecoute qui empile les requetes pour au moins un autre qui traite, le client peut au moins recevoir quasi instantane sa notification de position dans la liste, un peu dans le genre edonkey et autres.
> BruNews, ciao...

> J'ai beau y réfléchir je ne vois pas trop, faut-il que je ramène mes requêtes à des requêtes plus simples du type 1 requête -> 1 paquet réponse (aïe) ?

Je voulais bien sûr dire 1 requête -> 1 suite de paquets réponse (pas forcément un unique paquet, mais 1 suite non coupée par un accusé de réception).

Tu as jete un oeil sur le code de eMule, c'est en opensource, avec du mfc mais juste a traduire, y a de bonnes idees dedans. Tu le trouves par google.
Et le serveur du site qui n'arrete pas de planter... !!!
BruNews, ciao...


-------------------------------
Réponse au message :
-------------------------------

> > J'ai beau y réfléchir je ne vois pas trop, faut-il que je ramène mes requêtes à des requêtes plus simples du type 1 requête -> 1 paquet réponse (aïe) ?
>
> Je voulais bien sûr dire 1 requête -> 1 suite de paquets réponse (pas forcément un unique paquet, mais 1 suite non coupée par un accusé de réception).

Ah non je n'ai pas fait ça j'y roule ! (oui j'ai une souris à boule)

Arg 121 fichiers cpp dans les sources de eMule... il va me falloir du temps pour piger tout ça, bon déjà j'ai trouvé le fichier qui analyse la requête (ils ont oublié les commentaires pour les fonctions dans les .h :-| ).

Bon j'ai jeté mes deux yeux dans le code et c'est bien fait mais en même temps c'est le bordel, on se comprend hein :-), c'est difficile d'en ressortir la gestion globale, à première vue je dirais que 1 requête donne lieu à 1 réponse non interrompue (ce qui me semble bizzare vu que c'est de l'UDP), lorsque la réponse est plusieurs paquets (comme c'est le cas lorsque le client demande une partie d'un fichier) c'est placé dans une pile sur le client lui-même puis c'est envoyé d'un trait.
Les requêtes semblent aussi être découpées au maximum (demande de l'entête de ci par requête, réponse, demande de la suite par requête, réponse, ...etc) (ouiiiin)

Mais il est possible qu'il y ait des subtilités de la gestion des requêtes qui m'aient échappées.

PS : Je suis finalement passé en mfc, passage forcé, trop d'erreurs de librairies dont on arrivait pas à se dépatouiller :/. Ce n'est pas si catastrophique que ça, enfin pas autant que le class wizard qui me jète la classe quand je fais delete sur une de ses méthodes (toujours pas compris pourquoi il fait ça, je me suis rabattu sur mon explication habituelle : microsoft :-)).

-------------------------------
Réponse au message :
-------------------------------

> Tu as jete un oeil sur le code de eMule, c'est en opensource, avec du mfc mais juste a traduire, y a de bonnes idees dedans. Tu le trouves par google.
> Et le serveur du site qui n'arrete pas de planter... !!!
> BruNews, ciao...