Discussion Breaking down L2j for cloud usage

[Elfo]

a

Edited October 1, 2021 by Elfocrash

[Nightw0lf]

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

[Elfo]

a

Edited October 1, 2021 by Elfocrash

[Tryskell]

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 January 26, 2018 by Tryskell

[Pastorious]

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)

[Elfo]

a

Edited October 1, 2021 by Elfocrash

[vampir]

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 January 26, 2018 by vampir

[Sdw]

That approach is way too soft, also not worse the price

[Pastorious]

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.

[xxdem]

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

[Elfo]

a

Edited October 1, 2021 by Elfocrash

[xxdem]

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

[xxdem]

 

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

[Sdw]

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

[Elfo]

a

Edited October 1, 2021 by Elfocrash