Idées d'architectures pour la partie réseau

Introduction

Voici des idées d'architectures pour la partie réseau.

Fortement threadé

(Thorrent Threads hoho)

L'idée de base, on thread tout, on se retrouverais alors avec :

• Un thread pour la partie interface (RPC)
• Un thread pour le gestionnaire bitorrent qui chaperonne tout.
• Un thread par .torrent en téléchargement/seed.
• Un thread par client qui télécharge un chunk.
• Un thread par téléchargement de chunk chez un peer.

Au final, ça fait beaucoup trop de threads, et on risque de pourrir les perfs de notre application.

Mélange thread-asynchrone.

Faire du full asynchrone est pas facile, et je ne suis pas sûr que ce soit génial niveau perfs. Une autre idée serait de mélanger les deux, on se retrouverais ainsi avec :

• Un thread pour la partie interface (RPC)
• Un thread pour le gestionnaire bitorrent qui chaperonne tout.
• Un thread par .torrent en téléchargement/seed.
• Un thread pour l'ensemble des téléchargements de chuck des clients par .torrent, le tout étant géré en async.
• Un thread pour l'ensemble des téléchargements de chunks chez les seeds pour un .torrent.

Le nombre de threads est nettement plus raisonnable, mais il y a surement de meilleures solutions.

Thread-workers polyvalents

L'idée est d'utiliser un pool de threads effectuant des tâches de manière polyvalentes. Les tâches peuvent être : gérer le téléchargement d'un chunk d'un client, gérer le téléchargement d'un chunk depuis un peer... On possède ensuite une queue dans laquelle on place les tâches à effectuer, le pool de torrent va vider la queue.

L'avantage c'est que l'on peut moduler les perfs, selon le nombre de threads dans le pool, et qu'on a une quantité de threads fixe.