net.i2p.router.networkdb.kademlia.ExploreJob

All Implemented Interfaces:: Job

class ExploreJob
extends SearchJob

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

Fields
Modifier and Type	Field	Description
`(package private) static int`	`MAX_CLOSEST`	Only send the closest "don't tell me about" refs...
`(package private) static int`	`PER_FLOODFILL_PEER_TIMEOUT`	Override to make this shorter, since we don't sort out the unresponsive ff peers like we do in FloodOnlySearchJob
`(package private) static String`	`PROP_EXPLORE_BREDTH`	how many peers to explore through concurrently

Fields inherited from class net.i2p.router.networkdb.kademlia.SearchJob

_facade, _log, MIN_TIMEOUT

Fields inherited from class net.i2p.router.JobImpl

_id

Constructor Summary

Constructors
Constructor	Description
`ExploreJob(RouterContext context, KademliaNetworkDatabaseFacade facade, Hash key, boolean isRealExplore)`	Create a new search for the routingKey specified

Method Summary

Modifier and Type	Method	Description
`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 /don't/ want.
`protected int`	`getBredth()`	max # of concurrent searches
`String`	`getName()`	Descriptive name of the task
`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.

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, requeue

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait

Field Details
- PROP_EXPLORE_BREDTH
  
  static final String PROP_EXPLORE_BREDTH
  
  how many peers to explore through concurrently
  
  See Also:
  
  Constant Field Values
- MAX_CLOSEST
  
  static final int MAX_CLOSEST
  
  Only send the closest "don't tell me about" refs... Override to make this bigger because we want to include both the floodfills and the previously-queried peers
  
  See Also:
  
  Constant Field Values
- PER_FLOODFILL_PEER_TIMEOUT
  
  static final int PER_FLOODFILL_PEER_TIMEOUT
  
  Override to make this shorter, since we don't sort out the unresponsive ff peers like we do in FloodOnlySearchJob
  
  See Also:
  
  Constant Field Values
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 /don't/ 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 'don't 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 class SearchJob
  
  Parameters:
  
  replyTunnelId - tunnel to receive replies through, or our router hash if replyGateway is null
  
  replyGateway - gateway for the reply tunnel, if null, we are sending direct, do not encrypt
  
  expiration - when the search should stop
  
  peer - the peer to send it to
  
  Returns:
  
  a DatabaseLookupMessage or GarlicMessage or null on error
- getBredth
  
  protected int getBredth()
  
  max # of concurrent searches
  
  Overrides:
  
  getBredth in class SearchJob
- 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 class SearchJob
- getName
  
  public String getName()
  
  Description copied from interface: Job
  
  Descriptive name of the task
  
  Specified by:
  
  getName in interface Job
  
  Overrides:
  
  getName in class SearchJob

Class ExploreJob

Nested Class Summary

Nested classes/interfaces inherited from class net.i2p.router.networkdb.kademlia.SearchJob