|
^. You can just generate the config on request (e.g. query worlds for player count, set default world to lowest or whatever strategy). Then you can cache that for whatever interval. Whenever the cache is evicted, next request will regenerate the config.
Not sure what you're trying to do though.
The whole idea of load balancing is that you don't need to communicate between your hosts. Because each request is going through the load balancer, it is the one that decides which host to choose. That's the main function of a load balancer, select a host.
There are different types of implementations (algorithms) that can decide which host to choose. You can find the algorithms using a simple google search "load balancer algorithms".
The default algorithm is "least connections", which simply picks the host with the least connections. But you don't always want this. You may have a host running on 8 cores and a host running on 2 cores. What you want in this scenario is that the 8 cores will be chosen more frequently than the second one because it's more "powerful". This load balancer algorithm is called "weighted least connections". The 8 cores host has a bigger "weight" of being chosen.
Each algorithm has its purpose.
in most servers this hasn't been a problem and there haven't been any measures implemented that would indicate load balancing was necessary.
the only examples that come to mind are hestia, alotic and some 614 (might be dementhium). they both had standalone update servers/social servers/game servers.
Yeah sounds like the most simple way to do this is have a query before you assign the IP & Port to the client, and let your load balancer pick which server to send the user to. Sounds like this could be fun to implement, but not sure if it's required in this particular niche.
That's not quite true, while the game worlds aren't load balanced, the login server's I believe are. IIRC from playing back in 08-12 there used to be around 20 login servers/lobbies e.g.lobby7.runescape.com
To add to that, no load balancing is actually one of Hestia's issues, connecting 2k clients simultaneously is problematic as everything goes through the 3-in-1 login/lobby/cross-world-chat "social server". But let's face it, no live server's need to test or support 2k concurrent login's.
The guy's talking about config's are correct, you can pass thelobbyid
andlobbyaddress
as client properties which will offset the port starting at 40000 (50000 for dev mode). You've got to watch out though, a lot of "dirty" high revision clients have world/lobby offsets "disabled" by whoever did the first Isaac disabling and subsequently everyone who copied him. At least in all 637, 666 & 667 client's I've seen in the downloads section.
That sounds like the best idea for what I'm trying to accomplish. I was wondering how to integrate that step inside the client's protocol, but I realized I could just fetch the data from the web service before launching the JFrame... That would be quite simple and easy to implement.
Huh maybe, but that sounds like a pain to manage. I'd rather not add multi-world support for game servers.
Yep, that's what I'm going to do. Just call some API and fetch the default hosts at startup.
If you're talking about the server that sends the initial hosts back to the client, assuming that's his only responsibility I don't think load balancing is necessary. Even though it will get multiple startup requests, that information would be extremely lightweight.
Thanks for the idea. I'm probably just going to generate it once per minute. The worlds can just update their connection count in the DB and then I can generate some formula based on that.
I didn't think of the individual server strength. I guess I can just store the number of cores in the DB and do a load formula like:
connection_count * (1/server_cores)
Yep, that's the plan.
Yep, planning on overwriting the parameters on client launch forlobbyaddress
.
------------
Anyway, thanks for the help everyone!
Probably the 2nd due to the lack of servers. But either way, since the server is choosing the algorithm, it's really easy to implement both and have a switch between the two modes. It's probably just a few line of code each.
Load-based: make a cached list based off the formula I wrote: connection_count * (1/server_cores)
Proximity-based: fetch location from connected client + calculate closest server
« Previous Thread | Next Thread » |
Thread Information |
Users Browsing this ThreadThere are currently 1 users browsing this thread. (0 members and 1 guests) |