Class ExploreJob
java.lang.Object
net.i2p.router.JobImpl
net.i2p.router.networkdb.kademlia.SearchJob
net.i2p.router.networkdb.kademlia.ExploreJob
- All Implemented Interfaces:
Job
Search for a particular key iteratively until we either find a value, we run
out of peers, or the bucket the key belongs in has sufficient values in it.
Well, we're skipping the 'bucket gets filled up' test for now, since it'll never
get used (at least for a while).
-
Nested Class Summary
Nested classes/interfaces inherited from class net.i2p.router.networkdb.kademlia.SearchJob
SearchJob.FailedJob
-
Field Summary
Modifier and TypeFieldDescription(package private) static final int
only send the closest "dont tell me about" refs...(package private) static final int
Override to make this shorter, since we don't sort out the unresponsive ff peers like we do in FloodOnlySearchJobFields inherited from class net.i2p.router.networkdb.kademlia.SearchJob
_facade, _log, MIN_TIMEOUT
-
Constructor Summary
ConstructorDescriptionExploreJob
(RouterContext context, KademliaNetworkDatabaseFacade facade, Hash key, boolean isRealExplore) Create a new search for the routingKey specified -
Method Summary
Modifier and TypeMethodDescriptionprotected I2NPMessage
buildMessage
(TunnelId replyTunnelId, Hash replyGateway, long expiration, RouterInfo peer) Build the database search message, but unlike the normal searches, we're more explicit in what we /dont/ want.protected int
max # of concurrent searchesgetName()
Descriptive name of the taskprotected void
newPeersFound
(int numNewPeers) We've gotten a search reply that contained the specified number of peers that we didn't know about before.Methods inherited from class net.i2p.router.networkdb.kademlia.SearchJob
add, addDeferred, continueSearch, decrementOutstandingFloodfillSearches, fail, getExpiration, getFacade, getPerPeerTimeoutMs, getPerPeerTimeoutMs, getState, getTimeoutMs, onlyQueryFloodfillPeers, replyFound, runJob, searchNext, sendLeaseSearch, sendRouterSearch, sendSearch, timeoutMs, toString, wasAttempted
Methods inherited from class net.i2p.router.JobImpl
dropped, getAddedBy, getContext, getJobId, getMadeReadyOn, getTiming, madeReady, madeReady, requeue
-
Field Details
-
MAX_CLOSEST
static final int MAX_CLOSESTonly send the closest "dont tell me about" refs... Override to make this bigger because we want to include both the floodfills and the previously-queried peers- See Also:
-
PER_FLOODFILL_PEER_TIMEOUT
static final int PER_FLOODFILL_PEER_TIMEOUTOverride to make this shorter, since we don't sort out the unresponsive ff peers like we do in FloodOnlySearchJob- See Also:
-
-
Constructor Details
-
ExploreJob
public ExploreJob(RouterContext context, KademliaNetworkDatabaseFacade facade, Hash key, boolean isRealExplore) Create a new search for the routingKey specified- Parameters:
isRealExplore
- if true, a standard exploration (no floodfills will be returned) if false, a standard lookup (floodfills will be returned, use if low on floodfills)
-
-
Method Details
-
buildMessage
protected I2NPMessage buildMessage(TunnelId replyTunnelId, Hash replyGateway, long expiration, RouterInfo peer) Build the database search message, but unlike the normal searches, we're more explicit in what we /dont/ want. We don't just ask them to ignore the peers we've already searched on, but to ignore a number of the peers we already know about (in the target key's bucket) as well. Perhaps we may want to ignore other keys too, such as the ones in nearby buckets, but we probably don't want the dontIncludePeers set to get too massive (aka sending the entire routing table as 'dont tell me about these guys'). but maybe we do. dunno. lots of implications. FloodfillPeerSelector would add only the floodfill peers, and PeerSelector doesn't include the floodfill peers, so we add the ff peers ourselves and then use the regular PeerSelector.- Overrides:
buildMessage
in classSearchJob
- Parameters:
replyTunnelId
- tunnel to receive replies through, or our router hash if replyGateway is nullreplyGateway
- gateway for the reply tunnel, if null, we are sending direct, do not encryptexpiration
- when the search should stoppeer
- the peer to send it to- Returns:
- a DatabaseLookupMessage or GarlicMessage or null on error
-
getBredth
protected int getBredth()max # of concurrent searches -
newPeersFound
protected void newPeersFound(int numNewPeers) We've gotten a search reply that contained the specified number of peers that we didn't know about before.- Overrides:
newPeersFound
in classSearchJob
-
getName
Description copied from interface:Job
Descriptive name of the task
-