RSProt Explained: The New Networking Stack for OSRS Servers

The Library Quietly Changing How OSRS Servers Are Built

If you have been around the RSPS development scene long enough, you have watched the same problem repeat itself for two decades. Every server base has its own networking implementation. Most of them are inherited from something older that was inherited from something older still. Bugs get carried forward. Protocol changes get patched in half correctly. Performance issues that nobody has the time to properly diagnose just become accepted parts of running a server.

Then occasionally something comes along that actually addresses the problem at the root, and the scene shifts. RSProt is one of those things, and it is worth understanding what it actually does and why people who care about server quality are paying attention to it.

 

What RSProt Actually Is

In plain terms, RSProt is a networking library for OldSchool RuneScape private servers. It handles the parts of a server that talk to the client. JS5 cache delivery, the login flow, the game packet pipeline, info packet building for players, NPCs, and world entities, all of it sits inside this one library.

That might sound mundane if you have not worked on a server. It is not. Networking code is where most of the worst performance problems live, where most of the security holes hide, and where every protocol change from Jagex creates pain. Having a single well maintained library that handles all of it correctly is a genuinely different situation from what most server bases have shipped historically, where networking code was scattered, patched, and rarely audited.

The library targets revisions 221 through 238, meaning it covers current and very recent OSRS protocol versions. That alone is a meaningful thing, because keeping up with Jagex protocol changes has always been one of the slower parts of private server development.

 

Why Networking Code Has Always Been the Sore Spot

For people who have not built a server, it is worth explaining why this part of the codebase matters so much.

The networking layer is the boundary between your server and an unknown number of untrusted clients. Every byte that enters your process from a player started life on someone else's machine. If your code trusts that data even a little too much, you have a problem. If your code is slow at processing that data, you have a different problem. If your code allocates memory inefficiently while processing that data, you have a third problem that only shows up under load when 800 players are online and the garbage collector starts dragging your tick rate down.

The classic RSPS bases never solved any of this well. They solved it well enough to run, which is not the same thing. Servers that have grown past a few hundred concurrent players have all hit the same wall at some point, and that wall is usually the networking layer giving out under conditions it was never designed to handle.

RSProt is interesting because it is one of the few attempts to actually design that layer properly from the start, with modern Netty patterns, careful attention to backpressure, and explicit handling of all the failure modes that classic bases just hope never happen.

 

What It Gets Right

A few of the design decisions deserve attention because they reflect the kind of thinking that is missing from most existing networking code in the scene.

Auto read is disabled by default on all handlers. This is a small detail with large implications. With auto read on, Netty will keep feeding your code data as fast as the client sends it. A malicious client can flood you and your code has to deal with whatever ends up in the buffer. With auto read disabled, the protocol decides when it is ready for more data. The server controls the pace, not the client. This is the right pattern and it is the one most older bases do not use.

Idle timeouts are enforced. Clients that go quiet for 30 seconds on JS5 or 60 seconds on game services get disconnected. Open connections are not free. They cost file descriptors, they cost memory, and they are an attack surface for anyone who wants to exhaust your resources by opening thousands of sockets and never doing anything with them. Enforced timeouts close that vector cleanly.

Channel writability is respected. When the client is reading slower than the server is writing, the outbound buffer grows. Left unchecked, this is how servers run out of memory. The library checks the writability status and backs off, which is the correct behavior and another thing classic bases routinely got wrong.

JS5 fairness is built in. The JS5 service uses a single thread that serves clients in rotation, with small blocks per iteration, so no single client can starve the others by requesting expensive cache groups. A malicious actor cannot tie up the JS5 worker by spamming requests for heavy data, because they only get their fair slice before the next client is served. This is a real attack vector that has been used against private servers historically, and the design here closes it.

Logged in clients get priority on JS5. Subtle but smart. People already in the game get 1,536 byte blocks per iteration while clients still loading get 512 byte blocks. This means players who are actively trying to play do not get held up behind dozens of headless clients hammering the cache. It is the kind of detail you only build in if you have actually watched servers struggle with this exact scenario.

 

The Login Flow and Proof of Work

The login section is where the library really shows its understanding of the threat environment.

Login is expensive. RSA decryption alone takes roughly half a millisecond per key, which sounds tiny until you do the math. A few thousand fake login attempts per second can saturate a server before the logins even get processed, just from the CPU cost of decrypting the login blocks. This has been a known attack vector for years.

RSProt handles this two ways. First, the actual RSA work is moved off the Netty worker threads onto a separate pool, so even if logins back up they do not stall the parts of the server handling actual gameplay. Second, and more importantly, proof of work is required before the login block is even decoded.

Proof of work is the same general idea that cryptocurrency mining uses. The server hands the client a chunk of random data and a difficulty level. The client has to find a number that, when appended to that data and hashed, produces a result with enough leading zeros to meet the difficulty. There is no shortcut. The client just has to grind through hashes until it finds one that works. The server, by contrast, only does the verification once, which costs almost nothing.

The practical effect is that anyone trying to spam your login service has to burn real CPU time on every single attempt. Suddenly a flood of fake logins is expensive for the attacker and cheap for you, which is exactly the asymmetry you want. The default difficulty produces something like 100,000 to 500,000 hashes per attempt on the client side. Multiply that by however many bots someone wants to throw at you, and the attack becomes economically painful to sustain.

This is not a perfect defense, because nothing is, but it is the right kind of defense for this specific problem and most existing server bases do not implement it at all.

 

Game Packet Handling Done Right

The game packet pipeline includes a clever pattern that is worth describing because it is something most bases get wrong.

Packets come in two broad categories. User packets, which are things like player input, chat, and combat actions. And client packets, which are things like camera updates and other lower priority traffic. The library tracks how many of each have been processed in the current cycle, and once thresholds are hit, it disables auto read and single decode mode. Translation: Netty stops shoving more packets at you until the server has actually finished processing the current batch.

This guarantees that no matter how aggressively a client tries to send data, the server processes a bounded amount per tick. The maximum theoretical inbound buffer per channel ends up around 130KB, which is fine. Without this kind of bounded processing, a malicious client can drown the server by sending packets faster than the server can keep up, and you get cascading delays that affect every other player.

There is also a nice optimization where packets that nobody has registered a consumer for just get their bytes skipped rather than parsed into objects that immediately get thrown away. Small thing, but the kind of small thing that adds up when you are processing thousands of packets per second across hundreds of players.

 

What This Means for the Scene

Networking libraries do not generate the kind of excitement that custom content does. Players do not log into a server because the JS5 service is fair. Server owners are not going to advertise their proof of work implementation in their threads.

But the servers running on solid networking foundations are the ones that survive past their first growth spurt. They are the ones that do not crater under launch traffic. They are the ones that do not become unplayable when a popular content creator brings 500 viewers in at once. They are the ones whose owners are not spending every weekend hunting down memory leaks and mysterious tick rate drops.

The gap between a server built on disciplined networking code and a server built on whatever was in the 317 base that was floating around in 2012 is real, and it shows up exactly where you would expect. Stability under load. Resistance to denial of service. Clean handling of edge cases that the original code never anticipated. Headroom for growth.

That gap has historically been hard to close because writing networking code that handles all this correctly is hard work that takes months and produces no visible result. A library that closes that gap by giving people a properly built foundation to start from is a meaningful contribution to the scene, even if most players will never know it exists.

 

The Honest Caveats

A few things worth being clear about.

The library is in alpha. The maintainers are explicit about this. Breaking changes are possible, and anyone integrating it needs to be prepared to follow updates. This is not a finished product, it is a serious work in progress with active development behind it.

Integration is not trivial. The library handles the networking layer, but you still need a server framework around it that knows how to use it correctly. The quick guide in the documentation gives you a sense of what is involved, and it is real engineering work. This is not a drop in replacement that magically fixes a broken server.

It targets a specific range of OSRS revisions. If you are running a server on something older, or running a pre EoC base, or doing custom client work, the library may or may not fit your situation. It is built for a specific audience and that audience is people running on recent OSRS protocol versions.

None of that takes away from the value of what it is doing. It just sets realistic expectations about who should be looking at it and when.

 

Why This Matters For Picking a Server

If you are a player, the practical effect of all of this is that the servers building on better foundations tend to be the ones still around in a year. Networking code is invisible from the player perspective, but its consequences are not. Lag, disconnects, login queues, rubber banding, world instability, all of these trace back to the networking layer eventually.

The servers that consistently rank well over time on our list tend to be the ones investing in their infrastructure, not just their content. Custom raids and unique items get players in the door, but the technical foundation is what keeps them logged in. Both matter. The servers that get both right are the rare ones, and they are usually obvious from how they are talked about in the community.

If you want to find them, the RSPS list is the place to start. The servers holding their positions month after month are the ones that took their development seriously from day one, networking code included, and the gap shows up in the player experience every single day.