Class 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).
  • Field Details

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