-
Notifications
You must be signed in to change notification settings - Fork 49
chore: move websocket proxy #203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
feat: initial project setup
chore: require 1.85
chore: add readme
chore: add support for hostname prometheus tag and global tags
Support Multiple Upstream WebSocket Connections for HA Setups
* feat(PROTO-945): implement Redis-based rate limiting and update dependencies - Added RedisRateLimit for distributed rate limiting, allowing connection tracking across multiple instances. - Updated Cargo.toml to include new dependencies for Redis and related packages. - Enhanced README with Redis integration instructions and usage examples. - Modified main.rs to support Redis configuration via command-line arguments. - Updated Cargo.lock with new package versions and dependencies. * Add redis-tools to github action for test runs
fix: parse multiple upstream url
* reset redis counters on boot * updates to use heartbeat/cleanup mechanism for tracking * pr comment updates, add tests, move sempahore
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Skipped Deployment
|
Builds of the websocket proxy [are provided](https://github.com/base/flashblocks-websocket-proxy/pkgs/container/flashblocks-websocket-proxy). | ||
The only configuration required is the rollup-boost URL to proxy. You can set this via an env var `UPSTREAM_WS` or a flag `--upstream-ws`. | ||
|
||
|
||
You can see a full list of parameters by running: | ||
|
||
`docker run ghcr.io/base/flashblocks-websocket-proxy:master --help` | ||
|
||
### Redis Integration | ||
|
||
The proxy supports distributed rate limiting with Redis. This is useful when running multiple instances of the proxy behind a load balancer, as it allows rate limits to be enforced across all instances. | ||
|
||
To enable Redis integration, use the following parameters: | ||
|
||
- `--redis-url` - Redis connection URL (e.g., `redis://localhost:6379`) | ||
- `--redis-key-prefix` - Prefix for Redis keys (default: `flashblocks`) | ||
|
||
Example: | ||
|
||
```bash | ||
docker run ghcr.io/base/flashblocks-websocket-proxy:master \ | ||
--upstream-ws wss://your-sequencer-endpoint \ | ||
--redis-url redis://redis:6379 \ | ||
--global-connections-limit 1000 \ | ||
--per-ip-connections-limit 10 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll update the image URLs when I add the docker deployment and have new images
The CI issue for contender is fixed in #204 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we are adding another service independent from rollup-boost
, I think its best to restructure the repo to use Cargo workspaces. This will provide a clean separation between services/dependencies.
Thanks for looking @0xKitsune, happy to add it as a workspace setup if ya'll prefer. cc @ferranbt if I understood, you had a preference to keep them separate/just add a subfolder? (Though I may have misunderstood) |
Sounds good, yeah I think a workspace would be best here rather than standalone crates. Workspaces will simplify dependency management across services without duplicating deps in |
Yes, this was my initial suggestion to keep the PR as lean as possible. If we have to create a workspace we have to restructure everything right? @0xKitsune |
Setting up a workspace does not require major restructuring, however happy defer this to a follow up PR to keep changes minimal. The only change needed is to move the existing crate into a new directory (e.g. rollup-boost/), update the existing |
I'll me make the workspace changes on this PR. If it results in too large a change we can revert the commit + merge separately. |
Hi @danyalprout, is base/flashblocks-websocket-proxy basically closed to changes while this move is happening? If I'd like to make changes to the websocket proxy, should I just fork the branch for this PR instead? |
@paranoiacblack that's right, I'm going to archive that repo later today |
Description
Initial pass for #202