A good post,
John.
Quote:
Originally posted by JohnDoe345
I forgot to mention that when I get a 56k user downloading from me all I do is just open another slot so that others can use my available bandwidth. So basically I start out with 2. If I get 2 broadband users then I leave it at that. If one or both slots get taken up by 56k users then I add more slots appropriately. I just wish that this process can be automated by the p2p program. I believe this would be a fair way to satisfy both the 56k users and broadband users.
|
The procedure above would be a good, well-defined program for a more intelligent bandwidth control system. WinMX's queue and bandwidth controls are versatile but dumb - they require plenty of human intelligence and interception to handle the complex p2p environment in a decent way. As
assorted pointed out, we would actually need separate shares targeted to separate subcommunities, each under its own bandwidth and queue controls. We would probably also want these controls linked together under a master bandwidth control from where it would be easy to throttle the bandwidth economy of the entire application. This kind of arrangement should provide us a pleasant simultaneous existence in two different (albeit overlapping) subcommunities living on the same network.
Quote:
Originally posted by JohnDoe345
Like TG's description of a fair leech control system mentioned awhile back, there needs to be a fair bandwidth control system. A system that can redistribute the available bandwidth depending on who is downloading from you so that no one is discriminated against. I've uploaded to many 56k users and will continue to do so. What I have described in my last post is only if I have a new popular movie which I would like to be spread quickly so that everyone can enjoy.
|
Leech control as I
sketched it out would of course be part of the general bandwidth control system, contributing to the sense of fairness regarding our sharing. But as John's examples show, there is much more to it than leech control. Leeches are just the negative part of the community; its positive social attraction is in the good content and in the good people sharing it. To them we want to give back as much as we can - and as smoothly and efficiently as possible. This creates a need for preferential and rewarding bandwidth tools to complement the 'negative' leech control set. As John's example shows there is a need to classify peers according to their technical (bandwidth) and social (sharing behaviour) qualities and allocate bandwidth and slots accordingly. Most of it could (and should) be done automatically but we would also like to have means to shape our social p2p environment manually so that we could give a preferential treatment to our best contacts. There is nothing wrong in preferential sharing if it co-operates smoothly with the more public sharing. We will favor our friends anyway with some other communication software if our p2p client does not support it.
- tg
