Le , e-t172 <e-t...@akegroup.org> a écrit :
e-t172 wrote:
Bon c'est assez simpliste, et ça ne couvre pas le cas de HTTP parce que en pratique, HTTP serait considéré comme du batch. J'imagine qu'il serait mieux de faire des statistiques sur une conversation (stateful donc), auquel cas, comme la connexion HTTP serait inutilisée la plupart du temps (vu que l'utilisateur ne change pas tout le temps de page), elle serait priorisée par rapport au Bittorrent par exemple qui lui utilise toute la capacité tout le temps. Par contre ça va scaler beaucoup moins bien évidemment.
Faudrait que j'expérimente là dessus, mais j'imagine que quelqu'un ya déjà pensé avant ?
Après réflexion, je me rend compte que c'est exactement ce que fait SFQ (Stochastic Fair Queuing) sous Linux : il fait en sorte que chaque conversation ait une part égale de la capacité. Or, comme une conversation interactive débite peu, avec SFQ elle aura logiquement une priorité plus haute que celles qui consomment beaucoup.
Une connexion bittorrent et une connexion http seront d'égal à égal avec SFQ, mais 1000 connexions bittorent vs 1 http, ta connexion http va peiner :) vu que SFQ classe par flux au sens de socket udp/tcp. SFQ c'est sympa mais pour ce cas de figure c'est totalement inadapté :)
JY
