Package 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	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	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 /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, 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 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,
                  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 Detail

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