si le multithread donne des bons résultats et que le monothread en donne des moins bons, vous appelez ca comme vous voulez mais pour moi ca commence par "bri" et ca finit par "dage"....
Pas forcement 'bri...dage'.
Le simple fait que qu'un point de la 'route' sature pour une raison x ou y engendre automatiquement ce phénomène de 'répartition équitable' en TCP, c'est le principe même des fonctions d'équilibrage de charge entre toutes les sessions tcp, fonctions introduites dans tous les routeurs (plusieurs 'algorithmes' existent, mais le principe reste le même, faire en sorte que tout le monde ai la même chose globalement en tcp).
Si c'est 'mal fait' (algos basics) et qu'il y a X ip clientes avec au total de tous les X, Y threads tcp à gérer sur un canal disposant de Z en bande passante max, on a Z/Y par thread tcp, peut importe le nombre de X IP clientes. Donc le client qui lance le plus de thread obtient le plus de bp.
Si par contre c'est 'mieux fait' (algos + modernes), on répartira d'abord par IP cliente donc on aura Z/X de bp par IP cliente, et chaque IP cliente aura Z/X/Y bp pour chacun de ses threads.
Dans tout cela il faut retrancher à Z le trafic UDP très mal 'réparti' (se rapporter à un autre sujet sur ce forum, on en parle de la 'régulation' tcp et udp), donc si en plus à ce point de saturation il y a beaucoup de trafic udp, il y a d'autant moins de bp dispo pour tcp.
