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.
Comment synchroniser un mp3 avec itunes
