70bca1f350
To prevent flapping peers from endlessly dos-ing us with online and offline events, we rate limit the number of events we will store per period using their flap rate to determine how often we will add their events to our in memory list of online events. Since we are tracking online events, we need to track the aggregate change over the rate limited period, otherwise we will lose track of a peer's current state. For example, if we store an online event, then do not store the subsequent offline event, we will believe that the peer is online when they actually aren't. To address this, we "stage" a single event which keeps track of all the events that occurred while we were rate limiting the peer. At the end of the rate limting period, we will store the last state for that peer, thereby ensureing that we maintain our record of their most recent state. |
||
---|---|---|
.. | ||
chanevent_test.go | ||
chanevent.go | ||
chaneventstore_test.go | ||
chaneventstore_testctx_test.go | ||
chaneventstore.go | ||
interface.go | ||
log.go | ||
rate_limit_test.go | ||
rate_limit.go |