feat(transport): add rate limiting for messages and connections #776
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add sliding window rate limiting to protect against flooding attacks: - Message rate limiting: 100 messages/second per peer (configurable) - Connection attempt rate limiting: 10 attempts/minute per peer (configurable) Implementation: - Add SlidingWindowRateLimiter class with automatic pruning - Add maxMessagesPerSecond and maxConnectionAttemptsPerMinute options - Integrate rate checks in sendRemoteMessage before sending - Integrate connection rate checks before dialing new connections - Clean up rate limiter state when peers become stale or transport stops Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add comprehensive test coverage for SlidingWindowRateLimiter: - Basic limit checking (wouldExceedLimit) - Event recording and pruning - checkAndRecord with error handling - getCurrentCount with window expiration - clearKey and clear methods - pruneStale for cleanup - Sliding window behavior with real timing Also test factory functions and constants. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
- Add 'messageRate' and 'connectionRate' to ResourceLimitError limitType - Update rate limiter to use correct limit type enum values - Update tests to match new limit types Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Move message rate recording to after successful write instead of before send attempt. This prevents failed sends from consuming rate quota. - Add connection rate limiting to automatic reconnection attempts via checkConnectionRateLimit dependency in reconnection lifecycle. - Handle ResourceLimitError gracefully during reconnection by continuing the loop after backoff instead of giving up on the peer. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Add remoteCommsOptions parameter to setupAliceAndBob helper - Configure higher maxMessagesPerSecond for queue limit test to ensure rate limiting doesn't interfere with queue limit testing Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
…rror - Call getCurrentCount once and reuse the value for both message and data - Use DEFAULT_MESSAGE_RATE_WINDOW_MS constant instead of hardcoded 1000 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Move DEFAULT_MESSAGE_RATE_LIMIT, DEFAULT_MESSAGE_RATE_WINDOW_MS, DEFAULT_CONNECTION_RATE_LIMIT, and DEFAULT_CONNECTION_RATE_WINDOW_MS to constants.ts for consistency with other default constants. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Contributor
Coverage Report
File Coverage
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Revert to using checkAndRecord() for message rate limiting instead of separate check and record calls. The separated approach had a TOCTOU race where concurrent sends could all pass the check before any recorded, bypassing the rate limit. Yes, failed sends now consume quota, but this is necessary for security - recording after send would allow attackers to make unlimited concurrent attempts that bypass the rate limit. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #661
Summary
maxMessagesPerSecond)maxConnectionAttemptsPerMinute)Implementation Details
SlidingWindowRateLimiterclass with automatic pruning of old eventssendRemoteMessagebefore sendingResourceLimitErrorwhen limits are exceededTest plan
🤖 Generated with Claude Code
Note
Adds configurable sliding-window rate limiting to remote comms and propagates limit errors.
SlidingWindowRateLimiterwith defaults inconstantsand factories for message/connection limitsinitTransportto enforcemessageRatebefore send andconnectionRatebefore dialing; cleans limiter state on stale-peer cleanup/stop; newRemoteCommsOptions(maxMessagesPerSecond,maxConnectionAttemptsPerMinute)ResourceLimitErroras retryable; logs and continues after backoffResourceLimitErrorschema to includemessageRateandconnectionRateWritten by Cursor Bugbot for commit cf0fab5. This will update automatically on new commits. Configure here.