oxen-storage-server
µWebSockets
Our great sponsors
oxen-storage-server | µWebSockets | |
---|---|---|
5 | 41 | |
26 | 16,718 | |
- | 1.0% | |
8.6 | 8.6 | |
about 1 month ago | about 1 month ago | |
C++ | C++ | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
oxen-storage-server
- About new Session encryption protocol...
-
Weekly Dev Update 06/07/2021
[Storage Server] Testing, bug fixes, and miscellaneous updates for the big 2.2.0 update https://github.com/oxen-io/oxen-storage-server/pull/433
-
Weekly Dev Update 08/06/2021
https://github.com/oxen-io/oxen-storage-server/pull/433 Make random message retrieval more efficient (the current approach scales poorly as the database grows) Refactor how timestamps and TTLs are handled; we now store a timestamp and an expiry, but no longer the TTL value, instead the TTL value is simply a temporary value that can be given when storing a message to implicitly define the expiry. Remove dead code/disused OMQ endpoints. Fix SS not shutting down properly if it gets signalled while still trying to get the initial keys from oxend. Change database storage to store bytes rather than base64-encoded data. Base64 is a transport encoding that is needed for javascript, but was being wastefully stored in the database too. Change generated hash to be based on fundamental values rather than user-provided encodings. Don't require timestamp and ttl to be passed as strings anymore. Allow storing using timestamp+expiry (as an alternative to timestamp+ttl). Expose storage rpc endpoints through a new public oxenmq rpc category storage.WHATEVER (e.g. storage.store). This allows clients that want to use zmq speak more efficiently to SS. Add bt-encoded input/output support to the OMQ storage endpoints; this is noticeably more network efficient because it requires neither base64 encoding, nor establishing and handshaking new connections for every request. The OMQ storage endpoints take params either json or a bt-encoded dict, and reply in kind. Clean up internals by moving transport encoding of internal values closer to the transport layer. (Aside from a cleaner design, this was also needed to get bt-encoded responses out cleanly). Add delete/expiry API interfaces to delete all, delete selected, delete by timestamp, shorten all expiries, and shorten specific message expiries.
-
Weekly Dev Update 01/06/2021
Replace boost beast with uWebsockets https://github.com/oxen-io/oxen-storage-server/pull/432 Remove pre-HF18 legacy code/endpoints that isn't being called anymore Remove process_lns_request endpoint (it is broken, and Session clients have already switched to using oxend_rpc with ons_resolve instead). Replace boost beast http(s) client code with cpr (https://github.com/whoshuu/cpr); this is a whole lot nicer to use for HTTP requests. Replace boost beast http server code with uWebSockets (https://github.com/uNetworking/uWebSockets). This gives a much nicer interface, and makes it easy for us to add websocket support for clients in the future. Remove boost::asio; it's not needed anymore with the removal of the above. Replace bootstrap RPC code with authenticated, encrypted OMQ RPC. Remove boost circular buffer use; a regular map with a two-line trim is simpler for the block hash cache and a limit on stored snodes doesn't seem necessary for the rate limiter. Make rate_limiter clean itself periodically rather than keeping buckets around indefinitely Make rate_limiter thread-safe so that you don't need to hold the entire service_node_ lock to use it. Remove ip_utils; we don't allow redirects and are sufficiently restrictive on the URL target that it seems unnecessary (plus not having it lets us offload DNS lookup to curl as part of the request). Replace /swarms/ping_test/v1 with /ping_test/v1; this new request now returns the remote pubkey in a header, and no longer includes an SSL cert signature (so that we can drop the SSL cert signatures after HF19). The old one will still be used until HF19. Add OMQ endpoint for storage tests; starting at HF19 it will get used rather than the HTTPS one. Refactor storage test retries into request_handler (rather than being in the HTTPS specific code) Move HTTPS server-specific code for validating snode signatures from headers out of generic request_handler code and into HTTPS-specific code. Make onion proxy-to-url timeout a bit less than the onion request timeout so that the client has a better chance of getting a relayed timeout error (rather than getting a timeout from the edge node). Miscellaneous cleanups. Logger: use file and line number instead of func because the latter is nearly useless when called from a lambda. Shorten timeout values for ping tests, storage tests, and bootstrap connections to 5s, 15s, and 10s, respectively, from. Refactor recent stats reporting to use rolling averages that always have 60-70min of stats and drop off 10min at a time, rather than the 1-period hard reset. Also fixes various stats that weren't calculated/reported properly. Add onion and proxy requests to systemd status line as well as used database size. Enable WAL for sqlite3 database Removed buffered message relaying for swarm propagation; it's counterproductive with omq's persistent connections. Enable jemalloc by default.
-
Weekly Dev Update 01/04/2021
Allow http in onion requests to an external server https://github.com/oxen-io/oxen-storage-server/pull/415
µWebSockets
-
I'm open-sourcing my game engine
They use (uWebSockets)[https://github.com/uNetworking/uWebSockets], which was written in C++, but has an interface to use in NodeJS. It's been really performant for me in my simple tests compared to other popular websocket libs that slow down fairly quickly.
-
8 Best WebSocket Libraries For Node
µWebSockets, pronounced as "microWebSocket”, is a WebSocket library written in C++ and has Node.js bindings. Its design focuses on being efficient and scalable, making it ideal for applications that require high concurrency and low latency.
-
Recommendations for a CPP HTTP server which supports changing max threads at run time.
You can do that with any single threaded library that leaves threading to you. Like for example https://github.com/uNetworking/uWebSockets
-
What's the hot tech stack these days?
Websockets are also pretty valuable for updating the page in real time, there are servers in many languages. I'm a big fan of https://github.com/uNetworking/uWebSockets which is C++ but also has JS bindings to use with Node.js.
-
I have done a full benchmark of a POST REST API on my computer: Node.js vs Fastify vs Express.js vs Deno vs Bun vs GO. Node.js is used WITH and WITHOUT clustering on 6-core I7 processor
Can you include uWebsockets? https://github.com/uNetworking/uWebSockets
-
[Cpp] Quelle bibliothèque de serveur Web C++ faut-il utiliser de nos jours ?
μWebSockets Génial, rapide, peut transformer l’eau en vin. Nécessite C++17.
-
Nuklear – A single-header ANSI C immediate mode cross-platform GUI library
Not exaclty -- it looks like it's pretty overkill for my needs
I'm looking for something more like websocketpp[0], or even just grpc without a requisite proxy. uWebsockets looks really promising, being header only, but in the fine print requires a runtime library. unfortunately, none of that ecosystem seems to use cmake, making integrating it that much more of a pain.
why use cpp for this, I'm sure some HNer will ask. the ray tracer itself is using cuda, that's why. I've also debated
- running it as a grpc server and having some proxy in a more web-accessible language
- creating python bindings and using python to make a websocket/http server for it
neither of those are out of the question, but they're not my first choices, because I'd like to keep the build & execution simple. introducing dependencies, especially other executables, is in conflict with that.
i don't need anything particularly scalable -- a threaded implementation, or one using select() would be fine, if not preferable.
[0] https://docs.websocketpp.org/
[1] https://github.com/uNetworking/uWebSockets
-
WebSocket Server in C
Really cool i also made and CAPI for using WebSocket in C, https://github.com/uNetworking/uWebSockets/tree/master/capi
I will take a deep look on your project thanks for sharing!
-
Socketify.py - Maybe the fastest web framework for Python and PyPy
We discover a really fast, small, and well maintained C++ Library called uNetworking/uWebSockets, but no C API available, so we create and adapt the full C API from uNetworking/uWebSockets and will integrate libuv powered fetch and file IO, this same C API is used by Bun
- In the 1970s, programming was an elite's task. Today programming is done by uneducated "farmers" and as a result, the care for smart algorithms, memory usage, CPU-time usage and the like has dwindled in comparison.
What are some alternatives?
loki-network - Lokinet is an anonymous, decentralized and IP based overlay network for the internet.
Boost.Beast - HTTP and WebSocket built on Boost.Asio in C++11
session-open-group-server
libwebsockets - canonical libwebsockets.org networking library
session-android - A private messenger for Android.
WebSocket++ - C++ websocket client/server library
session-open-group-server
drogon - Drogon: A C++14/17 based HTTP web application framework running on Linux/macOS/Unix/Windows [Moved to: https://github.com/drogonframework/drogon]
oxen-mq - Communications layer used for both the Oxen storage server and oxend
Mongoose - Embedded Web Server
cpr - C++ Requests: Curl for People, a spiritual port of Python Requests.
rpc-websockets - JSON-RPC 2.0 implementation over WebSockets for Node.js and JavaScript/TypeScript