Discussion :

[Valmond]

Bonjour !

Je me tâte de recoder une partie de mon serveur multijoueur notamment
la partie "un thread par connection" en quelque chose comme "une liste de
sockets asynchrones" et faire du polling dessus pour voir si il y a des messages entrants.

Ceci dans le but de ne pas avoir des milliers de threads en parallèle car ça deviens trop couteux en temps CPU.

Alors je suis tombé sur le bibliothèque Asio et j'ai lue qu'on peut l'utiliser
d'un façon asynchrone mais j'ai pas pu trouver si Asio crée quand même un thread pendant l'utilisation du socket.

Si c'est le cas ça ne marchera pas pour moi vue que les sockets sont utilisés
en permanence et du coup Asio utiliserait quand même un thread par socket...


Donc est ce que quelqu'un sait si Asio peut gérer
plusieurs sockets (actifs simultanément) avec qu'un Thread ?


Merci !

Valmond

[Alp]

Salut,

Ceci devrait t'intéresser : http://gwenael-dunand.developpez.com...pp/boost/asio/
En particulier la partie sur le chat : http://gwenael-dunand.developpez.com...ost/asio/#LVII (ça reste le même principe, sauf que les données envoyées ont une signification différente)

Par ailleurs : II-B

Sur certaines plateformes, l'implémentation de Boost.Asio peut éventuellement utiliser des threads en interne pour émuler l'asynchronicité. Ces threads restent invisibles pour l'utilisateur et la bibliothèque s'utilise comme si toutes les opérations étaient lancées dans un thread unique. Tant que le programme ne possède qu'un seul io_service, la boucle de traitement des événements est traité de manière strictement séquentielle. Le développeur n'a donc pas à gérer les accès concurrents.

[Valmond]

Merci pour ta réponse (j'ai lu ce site http://think-async.com/Asio/asio-1.3.1/doc/ qui explique pas mal Asio) et c'est justement cette ligne là:

Sur certaines plateformes, l'implémentation de Boost.Asio peut éventuellement utiliser des threads en interne pour émuler l'asynchronicité. Ces threads restent invisibles pour l'utilisateur et ...

qui me fais penser que "peut-être" Asio va invoquer mille threads pour mille connections et même si c'est
transparent pour l'utilisateur, mille threads va quoi qu'il se passe mettre une charge considérable sur le CPU

Pour le moment je suis sur Windows mais je vais probablement migrer le serveur sur FreeBSD donc si quelqu'un
connait les implémentations différents sur (surtout) FreeBSD ou Windows je suis preneur

J'ai aussi cherché un forum ou 'trainent' les créateurs mais j'ai rien trouvé pour l'instant.

[Goten]

Cherche pas un forum, poste sur la ML. (boost-users)

[Alp]

A mon avis, il va éventuellement lancer un thread que sur un async_* (async_read, async_write, async_accept, ...), le temps que la fonction en question (celle qui gère la lecture, celle qui gère l'envoi, ...) retourne, et tu n'aurais plus de thread. Il ne va pas faire un thread par connexion. Mais sinon, lis la doc concernant le io_service, tu verras, ça devrait répondre à pas mal de tes interrogations.

PS : si tu as des questions très très pointues sur Boost, et que tu n'obtiens pas de réponse ici, alors c'est sur les mailing lists de Boost qu'il faut se pencher. Mais a priori tu devrais avoir ce qu'il faut ici pour une grande majorité de tes questions.

[Valmond]

>le temps que la fonction en question (celle qui gère la lecture, celle qui gère
>l'envoi, ...) retourne, et tu n'aurais plus de thread.

Chaque socket envoi des donnes constamment (constant polling alors type chaque 50/100msec) donc créer un thread pour chaque envoi pose d'autres problèmes...

Merci pour le ML mais j'ai réussi à trouver des gens sur leur IRC et il semble que, enfin voila :

[13:51] <Zao> Valmond: It will use IOCP and other clever algorithms.
[13:51] <Zao> Valmond: As for spawning threads, at most one or so, I think.
[13:52] <Zao> As for handlers, they will be executed in any thread that run the io_service run.
[13:53] <Zao> On hippie systems, it'll be using kqueue, epoll and other neato stuff.

Ce qui me réconforte dans l'idée que le "un thread par socket" s'applique pas, je vais quand même garder
l'ancien structure dans mon serveur et développer la nouvelle en parallèle au cas ou...

et merci pour l'aide !

++

/Valmond

[3DArchi]

Salut,
A la lecture de ces lignes :
// io_service.hpp

Code :

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

1
2
3
4
 
class io_service{
//...
typedef detail::task_io_service<detail::select_reactor<false> > impl_type;

// io_service.hpp

Code :

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

1
2
3
4
 
class io_service{
//...
typedef detail::task_io_service<detail::select_reactor<false> > impl_type;

io_service.ipp

Code :

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

1
2
3
4
5
6
7
inline std::size_t io_service::run()
{
  boost::system::error_code ec;
  std::size_t s = impl_.run(ec);
  boost::asio::detail::throw_error(ec);
  return s;
}

et
select_reactor.hpp

Code :

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

1
2
template <bool Own_Thread>
class select_reactor

(tous les fichiers sont de Boost.Asio).
J'aurais tendance à penser qu'il utilise le thread courant avec un select.

[3DArchi]

En fait, en lisant tout simplement les détails d'implémentation de Boost.Asio, il me semble comprendre que dans le pire des cas un seul thread supplémentaire est créé par instance de io_service et non par socket.

[Mac LAK]

C'est certes un peu botter en touche, mais as-tu regardé RakNet ?

[Valmond]

@3DArchi

Merci, ça me conforte encore dans l'idée que Asio est le choix pour l'avenir, même si j'ai pas la réponse "100%" Asio semble faire au mieux dans ce domaine.

@Mac LAK

RakNet semble un peu une usine (à gaze ou pas je sais pas mais une usine quand même) et comme j'ai déjà un serveur qui fonctionne plutôt bien je pense que ça serait comme tu dis, un peu botter en touche


Merci pour tout ces réponses, ça fais vraiment plaisir !

[Mac LAK]

RakNet semble un peu une usine (à gaze ou pas je sais pas mais une usine quand même) et comme j'ai déjà un serveur qui fonctionne plutôt bien je pense que ça serait comme tu dis, un peu botter en touche

Pas si complexe que ça en fait, disons plutôt que c'est à mettre derrière l'oreille "au cas où"... Ou pour un autre développement de jeu en réseau.