Comments (11)
This is a good observation. However, tracking individual block requests and responses would be an overkill. How about increasing default timeout to 2 minutes?
from bt.
However, tracking individual block requests and responses would be an overkill.
But actually it did, but not use.
Just replace
with
long duration = System.currentTimeMillis() - max(started, checked);
and
with
shouldAssign = !timeoutedPeers.containsKey(peer);
and for more accurate timeout tracking
move
bt/bt-core/src/main/java/bt/torrent/messaging/PieceConsumer.java
Lines 117 to 122 in 77315df
to line 64:
bt/bt-core/src/main/java/bt/torrent/messaging/PieceConsumer.java
Lines 60 to 66 in 77315df
and finally
replace
with
this.maxPieceReceivingTime = Duration.ofSeconds(10);
(and rename maxPieceReceivingTime
to more actual name)
PS
all my changes that is related to this issue can be seen in my fork:
ckovorodkin@6252697
from bt.
BTW, is it ok, that during timeoutedAssignmentPeerBanDuration
Have
messages is still sending to peer (also PEX exchange occurs)?
from bt.
On the surface, this looks good. But there might be a problem with time-tracking individual blocks in that the sender will not always send the requested blocks with equal intervals. Like we request several blocks at a time (by sending multiple requests from the request queue), the sender may optimize as well and send all requested blocks at once, and this may happen well after the individual block receival timeout has elapsed. I.e. compare the following timelines of receiving blocks from two peers:
- request B1..4 from peer X -----3sec----> B1 -----3sec----> B2 -----3sec----> B3 -----3sec----> B4
- request B1..4 from peer Y -----12sec----> B1..4
Average download rate is the same for both peers (peer Y may even be slightly faster than peer X by sending the blocks after 11 seconds), but with your changes the second peer (Y) will be considered to timeout.
BTW, is it ok, that during timeoutedAssignmentPeerBanDuration Have messages is still sending to peer (also PEX exchange occurs)?
Yeah, I think it's OK. BEP-3 requires to send Have messages to all connected peers, because the most important thing is to keep the view of the state of the swarm up-to-date for everybody.
from bt.
I think we can just replace the existing option with a new relative metric:
max amount of time to receive one unit of data (e.g. 1 MiB)
Then calculate session-specific timeout for receiving a piece based on the size of a "standard" piece in the torrent
from bt.
Metric : minimum download speed
. for example 1.0 KiB/sec
And use it to calculate inactivity timeout
by calculate equation pending block count * block size / minimum dowdload speed
from bt.
Metric : minimum download speed. for example 1.0 KiB/sec
This is basically the same thing as "max amount of time to receive one unit of data", but differently worded and, when expressed in code directly (for instance, as some Rate
object), harder to serialize/deserialize than a simple number.
And use it to calculate inactivity timeout by calculate equation pending block count * block size / minimum dowdload speed
This is just an approximation, so I don't think it's incredibly useful to constantly perform this recalculation... piece_size * max_data_receive_time
will do just fine (both values should be normalized to the same units, most likely KiBs)
from bt.
It is more optimal to track smaller amount of data, because it makes possible to quickly detect inactivity.
Usually piece size is about 2 MiB, but block size is 8 KiB. Scale is 256:1. When block timeout is 10 sec, than piece timeout is 2560 sec = 42 min. This is too long.
from bt.
It is more optimal to track smaller amount of data, because it makes possible to quickly detect inactivity.
Optimal from what perspective? Is quickly detecting inactivity of one of the many active peers really that important? I'd rather say that the opposite is true: quickly punishing for eventual pauses is detrimental in the longer run
from bt.
Instead of short-term micromanagement we eventually would like to maintain long-term statistics (might even persist those between different sessions) for all encountered peers and prefer to assign pieces to peers that proved to be more responsive and timely (while still having some reasonable but not too punishing cap on the receiving time)
from bt.
Optimal from what perspective? Is quickly detecting inactivity of one of the many active peers really that important?
For real-time streaming applications it is very important. One inactive peer can stop streaming.
On the surface, this looks good. But there might be a problem with time-tracking individual blocks in that the sender will not always send the requested blocks with equal intervals. Like we request several blocks at a time (by sending multiple requests from the request queue), the sender may optimize as well and send all requested blocks at once, and this may happen well after the individual block receival timeout has elapsed.
Just notice: If whole channel bandwidth is utilized by all downloads, than it make sense to download blocks from peer one-by-one. Also, it is preferred behaviour for real-time streaming (while peer get task in block scope, not in piece scope).
Anyway, I plan to implement the simultaneous loading of a piece by several peers in the normal mode (like in endgame, but without random() and duplicates).
from bt.
Related Issues (20)
- [BUG] Many Incoming Encryption fail with InvalidMessage HOT 1
- [BUG] Weird metainfo validation error in CLI HOT 3
- [BUG] springboot use HOT 1
- how to download the file range pieces? HOT 2
- [BUG] Something does not work as it should
- Gradle issues with cling dependency library (upnp module) HOT 3
- Running CliClient.java Locally Reports an Error HOT 1
- java.lang.NoSuchMethodError: No virtual method getAnnotatedSuperclass()Ljava/lang/reflect/AnnotatedType; in class Ljava/lang/Class; or its super classes (declaration of 'java.lang.Class' appears in /apex/com.android.art/javalib/core-oj.jar) HOT 2
- Vulnerable dependencies
- [BUG] Cling 2.2.1 not found in Maven Central HOT 3
- How to access DHT Database at runtime? HOT 1
- Stopping client and stopWhenDownloaded() throws java.lang.RuntimeException HOT 1
- How can I get the info.files[0].filehash info
- [BUG] Something does not work as it should
- Dependency org.yaml:snakeyaml, leading to CVE problem
- Does it support Android?
- [BUG] Android - only maxSimultaneouslyAssignedPieces are downloaded if PieceSelector.getNextPieces supplies subset of all pieces in torrent HOT 3
- [QUESTION] Code affecting the performance HOT 2
- [BUG] Cannot decode torrent due to validation error
- [Request] Implement a getter-interface for events that receives Peer from an event
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bt.