net.i2p.router.networkdb.kademlia

## 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

       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 and Description
    --- | ---
    `(package private) static int` | `MAX_CLOSEST` only send the closest "dont 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

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

      `_facade, _log, MIN_TIMEOUT`

  - ### Constructor Summary

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

  - ### Method Summary

    Methods
    Modifier and Type | Method and Description
    --- | ---
    `protected DatabaseLookupMessage` | `buildMessage(TunnelId replyTunnelId, Hash replyGateway, long expiration)` Build the database search message, but unlike the normal searches, we're more explicit in what we /dont/ 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, 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 Detail

    - #### MAX_CLOSEST

          static final int MAX_CLOSEST

      only 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:
        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 Detail

    - #### ExploreJob

          public ExploreJob(RouterContext context,
                    KademliaNetworkDatabaseFacade facade,
                    Hash key)

      Create a new search for the routingKey specified

  - ### Method Detail

    - #### buildMessage

          protected DatabaseLookupMessage buildMessage(TunnelId replyTunnelId,
                                           Hash replyGateway,
                                           long expiration)

      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 class `SearchJob`
      Parameters:
        `replyTunnelId` - tunnel to receive replies through
        `replyGateway` - gateway for the reply tunnel
        `expiration` - when the search should stop

    - #### 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`