A voir également:
- Transmission synchrone et asynchrone pdf
- Lire le coran en français pdf - Télécharger - Histoire & Religion
- Save as pdf - Télécharger - Bureautique
- Comment faire un pdf - Guide
- Comment modifier un pdf - Guide
- Comment réduire la taille d'un pdf - Guide
3 réponses
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 655
10 avril 2003 à 14:13
10 avril 2003 à 14:13
Une constatation: dans la majorité des cas, le facteur limitant dans les applications client/serveur n'est pas la puissance du CPU, mais les débits réseau.
C'est partant de cette constatation que les sockets asynchrones ont été inventés.
En asynchrone, tu ne perd absolument aucun paquet !
Chaque flux est bufferisé.
Les sockets asynchrone permettent de gérer plusieurs connexions simultanément dans un seul process, un seul thread.
Il n'y a pas besoin de créer de nouveau process ou de nouveau thread.
Démarrer un process est très lent, et très couteux pour le système d'exploitation.
Développer avec des threads est moins coûteux, mais couteux quand même, et surtout c'est très difficile à débuguer.
En utilisant des sockets asynchrone, tu as un seul programme.
C'est beaucoup plus facile à gérer.
Et ça permet de gérer un grand nombre de connexions rapidement.
Et ça permet d'avoir une persistence des objets (connexions base de données, etc.). Bigrement pratique.
Et les serveurs asynchrones sont pratiquement immunisés contre les attaques de type DOS (Denial Of Service) (alors que ce type d'attaque écroule tous les serveurs web comme Apache, IIS, etc.)
Petit exemple pratique:
Attaques sur différents types de serveurs HTTP:
http://www.acme.com/software/thttpd/serverperf.gif
Tu remarquera que les serveurs web comme Apache (ou autre) s'écroulent au délà de 50 requêtes simultanées, alors que le serveur asynchrone thttpd tient la route.
Mais attention: les sockets asynchrone ne sont intéressant que si les traitements CPU sont faibles par rapport aux échanges réseau.
(Mais c'est valable dans la majorité des cas... :-)
--------------------
Je n'utilise pas les sockets synchrones, sauf pour de toutes petites applications.
Parcequ'un serveur synchrone ne peut servir qu'une connexion TCP à la fois, ce qui est horriblement lent.
C'est partant de cette constatation que les sockets asynchrones ont été inventés.
En asynchrone, tu ne perd absolument aucun paquet !
Chaque flux est bufferisé.
Les sockets asynchrone permettent de gérer plusieurs connexions simultanément dans un seul process, un seul thread.
Il n'y a pas besoin de créer de nouveau process ou de nouveau thread.
Démarrer un process est très lent, et très couteux pour le système d'exploitation.
Développer avec des threads est moins coûteux, mais couteux quand même, et surtout c'est très difficile à débuguer.
En utilisant des sockets asynchrone, tu as un seul programme.
C'est beaucoup plus facile à gérer.
Et ça permet de gérer un grand nombre de connexions rapidement.
Et ça permet d'avoir une persistence des objets (connexions base de données, etc.). Bigrement pratique.
Et les serveurs asynchrones sont pratiquement immunisés contre les attaques de type DOS (Denial Of Service) (alors que ce type d'attaque écroule tous les serveurs web comme Apache, IIS, etc.)
Petit exemple pratique:
Attaques sur différents types de serveurs HTTP:
http://www.acme.com/software/thttpd/serverperf.gif
Tu remarquera que les serveurs web comme Apache (ou autre) s'écroulent au délà de 50 requêtes simultanées, alors que le serveur asynchrone thttpd tient la route.
Mais attention: les sockets asynchrone ne sont intéressant que si les traitements CPU sont faibles par rapport aux échanges réseau.
(Mais c'est valable dans la majorité des cas... :-)
--------------------
Je n'utilise pas les sockets synchrones, sauf pour de toutes petites applications.
Parcequ'un serveur synchrone ne peut servir qu'une connexion TCP à la fois, ce qui est horriblement lent.
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 655
10 avril 2003 à 12:17
10 avril 2003 à 12:17
Salut !
Ah oui, j'aime beaucoup les sockets asynchrones.
ça permet d'avoir d'excellentes performances sans faire de mutli-threading.
Je les utilise en Python, mais c'est la même chose en C++.
Tu trouvera une explication très claire sur les sockets asynchrones là:
http://squirl.nightmare.com/medusa/async_sockets.html
Ah oui, j'aime beaucoup les sockets asynchrones.
ça permet d'avoir d'excellentes performances sans faire de mutli-threading.
Je les utilise en Python, mais c'est la même chose en C++.
Tu trouvera une explication très claire sur les sockets asynchrones là:
http://squirl.nightmare.com/medusa/async_sockets.html
ok merci,
cependant je comprend pas la difference, enfin il me semblait que si le prog est lent, que ton buffer est plein alors tu perd des paquet.
Je suis peut etre à la rue ou mon anglais me fais défaut. J'arrive pas à savoir sur koi partir.
Pourrez tu m'expliquer pourkoi tu utilise asynchrone et pas synchrone
merci
ben
cependant je comprend pas la difference, enfin il me semblait que si le prog est lent, que ton buffer est plein alors tu perd des paquet.
Je suis peut etre à la rue ou mon anglais me fais défaut. J'arrive pas à savoir sur koi partir.
Pourrez tu m'expliquer pourkoi tu utilise asynchrone et pas synchrone
merci
ben
10 avril 2003 à 15:28
en fait l'asynchrone c kan on utilise le "select" sur plusieur connexion ou je me trompe?
Y a t'il un rapport entre synchrone et receive bloquant et asynchrone et receive non bloquant?
enfin derniere question, c du coté serveur qu'on précise si asynchrone ou pas pour la socket? Comment faire si on considere le canal en full duplex, cad le client et aussi en écoute permanente ?
désolé pour toute mes question
et merci pour tes réponse
ben
2 juil. 2011 à 03:29