C'est un intérêt purement technique, genre le gros challenge de geek, parce qu'en réalité... c'est supra compliqué à faire en réalité, et en pratique (c'est d'ailleurs pour ça que personne ne le fait...).
Et ce que j'ai mis presque un an à développer en Delphi (pourtant c'est bien plus facile que le C) (je ne compte même plus les BSOD sous 2000), je l'ai réalisé en 1 mois sous Linux (alors que je n'y connaissais absolument rien à la programmation C sous Linux).
Tiens pour infos regarde juste cette fonction sur le site de Microsoft :
WSARcv() . Lis bien les trucs : tu dois en pratique définir des allocations que tu dois gérer de manière globale parce que tu ne sais jamais quand l'événement va être appelé... gestion des ressources, gestion des accès mémoire concurrentiels, c'est à toi de faire les bons malloc() et de les libérer quand il faut, de créer des objets mémoire "globaux", de gérer par messages lorsque qu'une socket est fermée de manière inattendue, etc etc et tout ça, tiens toi bien, tout ça dans une seule et unique fonction :
WSARcv().
Tu dois allouer tes propres piles de buffer WSABUF, dedans des sous structures via malloc() enfin non, des allocations système particulières, tes propres structures WSAOVERLAPPED, et regarde juste la valeur de retour dans le lien : un évenement particulier à gérer à chaque fois, et le pire dans tout ça c'est que comme c'est pas bloquant = utilisation 100% du coeur de Windows, tu sais jamais quand ça va arriver... je te parle pas des fois où tu reçois un WSAECONNABORTED, puis un WSAECONNRESET, ou des WSAEDISCON et des WSAESHUTDOWN qui se ressemblent mais
pas complètement.
:arf:
Ma conclusion est que pour les serveurs hautes performances - j'insiste =
uniquement dans le cadre particulier où on veut gérer plusieurs milliers de sockets à la fois - ma conclusion donc c'est qu'en gros c'est possible de faire quelque chose d'aussi puissant sous Windows que sous Linux, mais c'est tellement
complexe et
pas maintenable....
...qu'il n'y a pas à hésiter : Linux, Linux, Linux.