there is no provision to control transmission priority from the receiver.
to limit upload bandwidth, rather than using denyRequestedObject(), i recommend delaying the writeObject() call for a time to achieve a desired average upload rate. by calling denyRequestedObject(), the wanting peer will immediately ask someone else. if there is nobody else to ask, it'll ask you again immediately. so you still might end up using a lot of bandwidth just for the request/deny messages even though no useful work is happening.
Thank you for your response.. that's sad
About the upload management, actually if i can't respond to a request immediately i place the request in a queue. I've set a maximum time for being in the queue of 5 sec, after this 5secs, i call denyrequestobject because i don't want the other peer to wait forever. do you think this time of 5sec is okay or should i change it ?
Moreover, you say flash will make a new request immediately after receiving a denyrequestobject but it will ask for the exact same piece ? if i have other pieces in wantobjects, it won't try an other first?
And is it possible inside only one group to prioritize some chunks against others? or to mix 2 replication strategies? because i want to favorise lowest_first but i want rarest pieces to be downloaded too when enough bw is available ...
What i was planning to do is to join two groups, one in rarest and the other in lowest and control pieces demanding, but since it's not possible according to my first approach described in my first post...
Additional question :
How many pieces in the same time flash requests ?? (it seems 5, am i right ?)
And is it 5 in total or 5 for each groups we are in?
Is it possible to modify it's parameter?