I tried a similar thing for load balancing with little results, it's really about how your server uses its resources.
So for a little backstory, I've implemented a gateway server to handle connections and message codecs then translating them into messages sent into a channel (publish/subscribe system) to decouple the logic that handles and emits game commands/events so that I can implement the logic in any language that supports publish and subscribe (redis for my case). The server and the game can be implemented in the same language or two different languages if desired.
While that's working great, I also realized a possibility as a result of this design!
Say you have a client and server that implements the 317 protocol. What happens when you want to change revisions? Well, the answer varies depending on how well you've implemented the networking code in your server. In most new servers, it's as simple as re-implementing the message codecs. In others, it's rewriting a bunch of functions that are in a single class.
Luckily, new servers have proper abstraction of the incoming and outgoing messages, so this is just taking that and rewriting it a bit.
Easier scalability and resilience in the face of a denial of service attack or sudden heavy load. Scaling down saves money during off-peak hours and can be easily configured by a daemon to create new instances with more demand. Note, this is mostly for demonstration and learning purposes as an instance can already handle >7k messages per second (super high for any server). This could also help in mitigating denial of service attacks, if configured correctly. You could also improve latency for users by decreasing max connections per instance.
Now, seeing the possibilities, I am considering adding a mode to the gateway server:
Publish/subscribe (redis, but can be made to use any such as AMQP) - Already implemented
Proxy (any other RS client protocol)
Using publish/subscribe mode will allow servers to accept connections from clients with any supported protocol without needing to implement any client-specific protocol at all. All that's necessary is to write/read messages to/from publish/subscribe channels. This solves a lot of problems by clearly separating the responsibility of the network code vs the game code. The two never interact directly besides through the channels. Already gains all the aforementioned advantages.
Using proxy mode will allow clients with any supported protocol to translate messages sent in one protocol to another revision's protocol. This makes it compatible with typical RSPS that only support one protocol.
Server implementing 317
Accepts connections from 377
Server implementing OSRS (latest rev)
Accepts connections from select OSRS rev clients
Server and client implements same revision
Uses proxy as a load balancer
|« A Positive RSPS Future | Economy - donating »|
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)