Uses of Class
net.i2p.data.Hash

Lookup a Destination by Hash.

Extract the hash of the payload of an I2P repliable datagram (previously loaded with the loadI2PDatagram() method), verifying the datagram signature.

Called by the message handler on reception of DestReplyMessage This will never happen, as the dest reply message does not contain a session ID.

Blocking.

Blocking.

Reverse lookup a hash.

Checks individual count only.

Calculate the hash and cache the result.

Nonstandard.

Pull from cache or return new

A common interface to the Hash of the two subclasses.

Throws IllegalStateException if keys and cert are not initialized, as of 0.9.12.

Get the routing key for the structure using the current modifier in the RoutingKeyGenerator.

Set this on creation if known

Also sets receivedAsReply to true

Contains the router who requested this lookup

Defines the key in the network database being stored

Defines the key being searched for

Read the next hop from the record.

Encrypt the record to the specified peer.

Replace the dontInclude set with this set.

Populate this instance with data.

Generate a modified (yet consistent) hash from the origKey by generating the SHA256 of the targetKey with the current modData appended to it This makes Sybil's job a lot harder, as she needs to essentially take over the whole keyspace.

Generate a modified (yet consistent) hash from the origKey by generating the SHA256 of the targetKey with the current modData appended to it This makes Sybil's job a lot harder, as she needs to essentially take over the whole keyspace.

Get a regular or SSL socket depending on config.

if this is a client tunnel, what destination is it for?

Retrieve the destination to which this message is directed.

For convenience

retrieve the peer at the given hop.

Other destinations that use the same tunnel (or null if exploratory) Modifiable, concurrent, not a copy

For BanlistRenderer in router console.

for TunnelRenderer in router console

Should we accept the netDb lookup message, replying either with the value or some closer peers, or should we simply drop it due to overload?

Add a new message to the pool.

ick have to put the reasonCode in the front to avoid ambiguity

Note that there was some sort of communication error talking with the peer

Note that the peer was unable to reply to a db lookup - either with data or with a lookupReply redirecting the user elsewhere

Note that the peer replied to a db lookup with a redirect to other routers, where the list of redirected users included newPeers routers that the local router didn't know about, oldPeers routers that the local router already knew about, the given invalid routers that were invalid in some way, and the duplicate number of routers that we explicitly asked them not to send us, but they did anyway

Note that we were unable to confirm a successful send of db data to the peer, at least not within our timeout period

Note that we've confirmed a successful send of db data to the peer (though we haven't necessarily requested it again from them, so they /might/ be lying)

We don't know about the given tunnel, so we are dropping a message sent to us by the given router

Tell the comm system to disconnect from this peer.

client

Note that the local router received a reference to the given peer, either through an explicit dbStore or in a dbLookupReply

Does the peer's IP address appear in the blocklist? If so, and it isn't banlisted, banlist it forever...

Is it permanently negative cached?

Lookup using the client's tunnels Succeeds even if LS validation fails due to unsupported sig type

Unconditionally lookup using the client's tunnels.

Not for use without validation

Note that the router failed to send a message to the peer over any transport

Note that the router received a message from the given peer on the specified transport.

Retrieve a snapshot of the statistics that should be published.

We just received a message from the peer

Pick the inbound exploratory tunnel with the gateway closest to the given hash.

Pick the inbound tunnel with the gateway closest to the given hash from the given destination's pool.

Pick a random outbound tunnel from the given destination's pool

We just sent a message to the peer

Note that the peer is participating in a tunnel that pushed the given amount of data over the last minute.

Note that the peer participated in a tunnel that failed.

Note that we were able to push the given amount of data through a tunnel that the peer is participating in

The peer did not accept the tunnel join for the given reason

The peer did not accept the tunnel join for the given reason (this may be because of a timeout or an explicit refusal).

Note that a router timed out joining a tunnel

Return the hash for the given ID

Return the client's current manager or null if not connected

Data for the current leaseRequest, or null if there is no active leaseSet request.

Subsession aware.

Determine if the destination specified is managed locally.

Call after destinationEstablished(), when an encrypted leaseset is created, so we know it's local.

Request that a particular client authorize the Leases contained in the LeaseSet, after which the onCreateJob is queued up.

Request that a particular client authorize the Leases contained in the LeaseSet.

Remove the hash for the encrypted LS.

We send messages between comms as bytes so that we strip any router-local info.

Allow the app to specify the data clove directly, which enables OutboundClientMessage to resend the same payload (including expiration and unique id) in different garlics (down different tunnels) This is called from OCMOSJ

ELGAMAL_2048 only.

The hash to lookup for a SPK known to be blinded.

The hash to lookup for a dest.

get the hashes for all known routers

getFailed

See above for description List will not include our own hash Returns new list, may be modified.

List will not include our own hash.

UNUSED - See FloodfillPeerSelector override Search through the kbucket set to find the most reliable peers close to the given key, skipping all of the ones already checked List will not include our own hash.

UNUSED - See FloodfillPeerSelector override Generic KBucket filtering to find the hashes close to a key, regardless of other considerations.

Pick out peers with the floodfill capacity set, returning them first, but then after they're complete, sort via kademlia.

UNUSED - See FloodfillPeerSelector override Ignore KBucket ordering and do the XOR explicitly per key.

Build the database search message, but unlike the normal searches, we're more explicit in what we /don't/ want.

Calculate the xor with the current object and the specified hash, caching values where possible.

Note that we heard from the peer

Final remove for a leaseset.

Get the routers closest to that key in response to a remote lookup Only used by ../HDLMJ Set MAY INCLUDE our own router - add to peersToIgnore if you don't want

Get an unsupported but cached Destination

todo: does this need more tuning?

Is it permanently negative cached?

Search for a newer router info, drop it from the db if the search fails, unless just started up or have bigger problems.

Lookup using the client's tunnels Succeeds even if LS validation and store fails due to unsupported sig type, expired, etc.

Increment in the negative lookup cache

Lookup using exploratory tunnels.

Use lookupDestination() if you don't need the LS or don't need it validated.

Unconditionally lookup using the client's tunnels.

Not for use without validation

This will return immediately with the result or null.

we didn't actually want to add this peer as part of the pending list...

how long did it take to get the reply, or -1 if we dont know

public long confirmedExploratory(Hash peer) { long rv = -1; synchronized (_pendingPeers) { _pendingPeers.remove(peer); Long when = _pendingPeerTimes.remove(peer); if (when != null) rv = _context.clock().now() - when.longValue(); } synchronized (_successfulExploratoryPeers) { _successfulExploratoryPeers.add(peer); } return rv; }

Lookup using the client's tunnels.

Unused - see FNDF

See above for description List will not include our own hash Returns new list, may be modified.

Pick out peers with the floodfill capacity set, returning them first, but then after they're complete, sort via kademlia.

Floodfill peers only.

Ignore KBucket ordering and do the XOR explicitly per key.

Pick out peers with the floodfill capacity set, returning them first, but then after they're complete, sort via kademlia.

We extend this here to send our routerInfo back as well, if we are not floodfill.

unused (overridden in FNDF)

increments before checking

Increments and tests.

Store the leaseSet.

Store the routerInfo.

Did we send a request to this peer?

See above for description List will not include our own hash Returns new list, may be modified.

Sort the floodfills.

Pick out peers with the floodfill capacity set, returning them first, but then after they're complete, sort via kademlia.

UNUSED - See FloodfillPeerSelector override Search through the kbucket set to find the most reliable peers close to the given key, skipping all of the ones already checked List will not include our own hash.

Floodfill peers only.

UNUSED - See FloodfillPeerSelector override Generic KBucket filtering to find the hashes close to a key, regardless of other considerations.

Ignore KBucket ordering and do the XOR explicitly per key.

Pick out peers with the floodfill capacity set, returning them first, but then after they're complete, sort via kademlia.

Pick out peers with the floodfill capacity set, returning them first, but then after they're complete, sort via kademlia.

UNUSED - See FloodfillPeerSelector override Ignore KBucket ordering and do the XOR explicitly per key.

We extend this here to send our routerInfo back as well, if we are not floodfill.

unused (overridden in FNDF)

Send a data structure to the floodfills

Delay a few seconds, then start the verify

Lookup using exploratory tunnels

Get the peers the transport layer thinks are unreachable and peers requiring introducers.

Note that the peer was unable to reply to a db lookup - either with data or with a lookupReply redirecting the user elsewhere This will force creation of DB stats Non-blocking.

Note that the peer replied to a db lookup with a redirect to other routers, where the list of redirected users included newPeers routers that the local router didn't know about, oldPeers routers that the local router already knew about, the given invalid routers that were invalid in some way, and the duplicate number of routers that we explicitly asked them not to send us, but they did anyway Non-blocking.

Note that we were unable to confirm a successful send of db data to the peer, at least not within our timeout period This will force creation of DB stats

Note that we've confirmed a successful send of db data to the peer (though we haven't necessarily requested it again from them, so they /might/ be lying) This is not really interesting, since they could be lying, so we do not increment any DB stats at all.

Retrieve the profile for the given peer, if one exists (else null).

Note that the local router received a reference to the given peer, either through an explicit dbStore or in a dbLookupReply Non-blocking.

Deprecated for now, always false

Note that the router failed to send a message to the peer over the transport specified.

Note that it took msToSend to send a message of size bytesSent to the peer over the transport.

Non-blocking.

Note that the router agreed to participate in a tunnel

Note that a router explicitly rejected joining a tunnel.

Note that a router did not respond to a tunnel join.

Return a set of Hashes for peers that are not failing.

Return a set of Hashes for peers that are both fast and reliable.

Return a set of Hashes for peers that are both fast and reliable.

Deprecated.

Load the analysis for a certain date.

All the routers, not including us