Jump to content

Breaking down L2j for cloud usage


Recommended Posts

so 1 dedi in europe 1 dedi in russia 1 dedi in africa 1 dedi in canada 1 dedi in amurica 1 dedi in brasil and you have 0 lag globally according to your results: perhaps, maybe, could be, cause i dont see any other use the game data cache is still away from game servers so game server 1 to gameserver N+1 will still have lag to send player1 actions to player2

Link to comment
Share on other sites

World data is unique to each server, while game data can be edited from server to server, depending type of server (faction, multiclass, etc) and rates. So until you want 100 servers clones - no usage at all, except experimenting for your personal usage. You still need a local db for each server, with unique modifications per server (by game data I assume you speak about all static data such as recipes, items, etc while world data would be "instanced" stuff such as spawns, players data, items, etc).

 

DB related, there is strictly no problem with L2J. At worst you got easy ways to fix them (db pooler change/tweak, MySQL server tweak, and at very very worst some edits to avoid db calls - which mean memory management using Java containers).

 

You should better find solutions for the network aspect.

Edited by Tryskell
Link to comment
Share on other sites

Forget.

Cloud is not abstract thing, is a farm of servers who talks one to each other with network protocols.

And at end is still one database, even clustered in master-master replication.

I see here only lags and more lags.

Customer in web app can wait 500ms to response, but player not.

This whole diagram is only good for mass users, for example 1kk (horizontal scaling) with acceptable (for web users) response, not for fluent game for thousands players.

You theory (no lag) can  only fits consumables and movement, but not for player-player interactions (both players from DIFFERENT servers, Nightw0lf wrote about this) like pvp, trade, siege.

 

If  I can understand You idea(?), I suppouse interact one player from one server with another from another server?

 

But yes, decoupling game and cache is good idea (l2off has it), but cache should "talk" to server only in shared memory, not throgh network (lag)

Link to comment
Share on other sites

As you said everything depends on data to run, even most simple request add friend packet have got many calls to check player state, his friendlist, target state. You would either have to send a lot of data each time to make a lot of calls.

 

Architecture seems to be a lot more complicated

Edited by vampir
Link to comment
Share on other sites

22 hours ago, .Elfocrash said:

And you are probably well aware that "shared memory" is something like Redis which is a memory cache over the network. There is no such thing like shared memory without networking. It has to communicate somehow.

 

I can see that it runs pretty well on a local network anyway so just wait till i show you what i mean.

My bad, i'm thinking about sockets on same machine (100% not Redis or any other message broker)

Ok, i'm waiting.

Link to comment
Share on other sites

Sounds very efficient, as efficient as connecting the CPU to a RAM stick a thousands of miles away with bonus noise and failure rates introduced by the network. Every single operation will involve a 200ms latency at best

Link to comment
Share on other sites

30 minutes ago, .Elfocrash said:

Did you even read that this is meant for a local service fabric cluster and not for geolocation based traffic split? It literally replicates the CacheD logic of L2OFF so it's as efficient as L2OFF itself it.

 

Just saw the picture my bad

Link to comment
Share on other sites

 

On 1/25/2018 at 5:23 PM, Nightw0lf said:

so 1 dedi in europe 1 dedi in russia 1 dedi in africa 1 dedi in canada 1 dedi in amurica 1 dedi in brasil and you have 0 lag globally according to your results: perhaps, maybe, could be, cause i dont see any other use the game data cache is still away from game servers so game server 1 to gameserver N+1 will still have lag to send player1 actions to player2

 

lmao

Link to comment
Share on other sites

3 hours ago, .Elfocrash said:

Did you even read that this is meant for a local service fabric cluster and not for geolocation based traffic split? It literally replicates the CacheD logic of L2OFF so it's as efficient as L2OFF itself it.

It can easily be done with the right tools lol

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...