Package net.i2p.router.peermanager
Class ProfileManagerImpl
java.lang.Object
net.i2p.router.peermanager.ProfileManagerImpl
- All Implemented Interfaces:
ProfileManager
Methods to update profiles.
Unless otherwise noted, methods are blocking on the reorganize lock.
-
Constructor Summary
-
Method Summary
Modifier and TypeMethodDescriptionvoid
commErrorOccurred
(Hash peer) Note that there was some sort of communication error talking with the peervoid
dbLookupFailed
(Hash peer) 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.void
dbLookupReceived
(Hash peer) Note that the local router received a db lookup from the given peer Non-blocking.void
dbLookupReply
(Hash peer, int newPeers, int oldPeers, int invalid, int duplicate, long responseTimeMs) 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.void
dbLookupSuccessful
(Hash peer, long responseTimeMs) Note that the peer was able to return the valid data for a db lookup This will force creation of DB stats Non-blocking.void
dbStoreFailed
(Hash peer) 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 statsvoid
dbStoreReceived
(Hash peer, boolean wasNewKey) Note that the local router received an unprompted db store from the given peer Non-blocking.void
dbStoreSent
(Hash peer, long responseTimeMs) 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) As of 0.9.53 we update the DbResponseTime.void
dbStoreSuccessful
(Hash peer) Note that we've verified a successful send of db data to the floodfill peer by querying another floodfill.void
heardAbout
(Hash peer) Note that the local router received a reference to the given peer, either through an explicit dbStore or in a dbLookupReply Non-blocking.void
heardAbout
(Hash peer, long when) Note that the local router received a reference to the given peer at a certain time.void
messageFailed
(Hash peer) Note that the router failed to send a message to the peer over any transport.void
messageFailed
(Hash peer, String transport) Note that the router failed to send a message to the peer over the transport specified.void
messageReceived
(Hash peer, String style, long msToReceive, int bytesRead) Note that the router received a message from the given peer on the specified transport.void
messageSent
(Hash peer, String transport, long msToSend, long bytesSent) Note that it took msToSend to send a message of size bytesSent to the peer over the transport.void
tunnelDataPushed
(Hash peer, long rtt, int size) Non-blocking.void
tunnelDataPushed1m
(Hash peer, int size) Non-blocking.void
tunnelFailed
(Hash peer, int pct) Note that the peer participated in a tunnel that failed.void
tunnelJoined
(Hash peer, long responseTimeMs) Note that the router agreed to participate in a tunnelvoid
tunnelLifetimePushed
(Hash peer, long lifetime, long size) Non-blocking.void
tunnelRejected
(Hash peer, long responseTimeMs, int severity) Note that a router explicitly rejected joining a tunnel.void
tunnelTestSucceeded
(Hash peer, long responseTimeMs) Deprecated.disabledvoid
tunnelTimedOut
(Hash peer) Note that a router did not respond to a tunnel join.
-
Constructor Details
-
ProfileManagerImpl
-
-
Method Details
-
messageSent
Note that it took msToSend to send a message of size bytesSent to the peer over the transport. This should only be called if the transport considered the send successful. Non-blocking. Will not update the profile if we can't get the lock.- Specified by:
messageSent
in interfaceProfileManager
-
messageFailed
Note that the router failed to send a message to the peer over the transport specified. Non-blocking. Will not update the profile if we can't get the lock.- Specified by:
messageFailed
in interfaceProfileManager
-
messageFailed
Note that the router failed to send a message to the peer over any transport. Non-blocking. Will not update the profile if we can't get the lock.- Specified by:
messageFailed
in interfaceProfileManager
-
commErrorOccurred
Note that there was some sort of communication error talking with the peer- Specified by:
commErrorOccurred
in interfaceProfileManager
-
tunnelJoined
Note that the router agreed to participate in a tunnel- Specified by:
tunnelJoined
in interfaceProfileManager
-
tunnelRejected
Note that a router explicitly rejected joining a tunnel.- Specified by:
tunnelRejected
in interfaceProfileManager
- Parameters:
peer
- who rejected usresponseTimeMs
- ignoredseverity
- how much the peer doesnt want to participate in the tunnel (large == more severe)
-
tunnelTimedOut
Note that a router did not respond to a tunnel join. Since TunnelHistory doesn't have a timeout stat, pretend we were rejected for bandwidth reasons.- Specified by:
tunnelTimedOut
in interfaceProfileManager
- Parameters:
peer
- who rejected us
-
tunnelTestSucceeded
Deprecated.disabledNote that a tunnel that the router is participating in was successfully tested with the given round trip latency Non-blocking. Will not update the profile if we can't get the lock.- Specified by:
tunnelTestSucceeded
in interfaceProfileManager
-
tunnelDataPushed
Non-blocking. Will not update the profile if we can't get the lock.- Specified by:
tunnelDataPushed
in interfaceProfileManager
-
tunnelDataPushed1m
Non-blocking. Will not update the profile if we can't get the lock.- Specified by:
tunnelDataPushed1m
in interfaceProfileManager
-
tunnelLifetimePushed
Non-blocking. Will not update the profile if we can't get the lock.- Specified by:
tunnelLifetimePushed
in interfaceProfileManager
-
tunnelFailed
Note that the peer participated in a tunnel that failed. Its failure may not have been the peer's fault however. Blame the peer with a probability of pct/100.- Specified by:
tunnelFailed
in interfaceProfileManager
-
dbLookupSuccessful
Note that the peer was able to return the valid data for a db lookup This will force creation of DB stats Non-blocking. Will not update the profile if we can't get the lock.- Specified by:
dbLookupSuccessful
in interfaceProfileManager
-
dbLookupFailed
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. Will not update the profile if we can't get the lock.- Specified by:
dbLookupFailed
in interfaceProfileManager
-
dbLookupReply
public void dbLookupReply(Hash peer, int newPeers, int oldPeers, int invalid, int duplicate, long responseTimeMs) 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. Will not update the profile if we can't get the lock.- Specified by:
dbLookupReply
in interfaceProfileManager
-
dbLookupReceived
Note that the local router received a db lookup from the given peer Non-blocking. Will not update the profile if we can't get the lock.- Specified by:
dbLookupReceived
in interfaceProfileManager
-
dbStoreReceived
Note that the local router received an unprompted db store from the given peer Non-blocking. Will not update the profile if we can't get the lock.- Specified by:
dbStoreReceived
in interfaceProfileManager
-
dbStoreSent
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) As of 0.9.53 we update the DbResponseTime. This will force creation of DB stats- Specified by:
dbStoreSent
in interfaceProfileManager
- Parameters:
responseTimeMs
- duration
-
dbStoreSuccessful
Note that we've verified a successful send of db data to the floodfill peer by querying another floodfill. This will force creation of DB stats- Specified by:
dbStoreSuccessful
in interfaceProfileManager
-
dbStoreFailed
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- Specified by:
dbStoreFailed
in interfaceProfileManager
-
heardAbout
Note that the local router received a reference to the given peer, either through an explicit dbStore or in a dbLookupReply Non-blocking. Will not update the profile if we can't get the lock.- Specified by:
heardAbout
in interfaceProfileManager
-
heardAbout
Note that the local router received a reference to the given peer at a certain time. Only update the time if newer. Non-blocking. Will not update the profile if we can't get the lock.- Specified by:
heardAbout
in interfaceProfileManager
-
messageReceived
Note that the router received a message from the given peer on the specified transport. Messages received without any "from" information aren't recorded through this metric. If msToReceive is negative, there was no timing information available. Non-blocking. Will not update the profile if we can't get the lock.- Specified by:
messageReceived
in interfaceProfileManager
-