Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## 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
`(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
`ExploreJob(RouterContext context, KademliaNetworkDatabaseFacade facade, Hash key)` Create a new search for the routingKey specified

Method Summary
`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`

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD