Forums WoW Modding Support Archives Azerothcore Discord Archives [DiscordArchive] Are you hard coding which Realm is "realm 1" vs "realm 2", if not how do you (consistently) assign t

[DiscordArchive] Are you hard coding which Realm is "realm 1" vs "realm 2", if not how do you (consistently) assign t

[DiscordArchive] Are you hard coding which Realm is "realm 1" vs "realm 2", if not how do you (consistently) assign t

Pages (2): 1 2 Next
rektbyfaith
Administrator
0
01-02-2024, 09:24 PM
#1
Archived author: Abillister • Posted: 2024-01-02T21:24:41.411000+00:00
Original source

Are you hard coding which Realm is "realm 1" vs "realm 2", if not how do you (consistently) assign that? What happens if a 3rd realm is added?
rektbyfaith
01-02-2024, 09:24 PM #1

Archived author: Abillister • Posted: 2024-01-02T21:24:41.411000+00:00
Original source

Are you hard coding which Realm is "realm 1" vs "realm 2", if not how do you (consistently) assign that? What happens if a 3rd realm is added?

rektbyfaith
Administrator
0
01-02-2024, 09:30 PM
#2
Archived author: Honey • Posted: 2024-01-02T21:30:21.243000+00:00
Original source

I'm wondering what's the advantage of having a "crossrealm worldserver" talk to multiple DBs instead of the usual worldserver/DB relation.
While a character is handled not by a regular worldserver but by a crossrealm server, it could easily still know which original worldserver the character belongs to by just adding one map and write potential permanent changes to the DB indicated by that variable.
rektbyfaith
01-02-2024, 09:30 PM #2

Archived author: Honey • Posted: 2024-01-02T21:30:21.243000+00:00
Original source

I'm wondering what's the advantage of having a "crossrealm worldserver" talk to multiple DBs instead of the usual worldserver/DB relation.
While a character is handled not by a regular worldserver but by a crossrealm server, it could easily still know which original worldserver the character belongs to by just adding one map and write potential permanent changes to the DB indicated by that variable.

rektbyfaith
Administrator
0
01-02-2024, 09:30 PM
#3
Archived author: walkline • Posted: 2024-01-02T21:30:38.761000+00:00
Original source

Initially, I considered making them static and loading them from the config. However, it's possible to subscribe the MySQL proxy to an event (using NATS) that notifies when a new realm is added. This event can be sent from the "servers registry" service (I'm referring to this architecture https://github.com/walkline/ToCloud9).
rektbyfaith
01-02-2024, 09:30 PM #3

Archived author: walkline • Posted: 2024-01-02T21:30:38.761000+00:00
Original source

Initially, I considered making them static and loading them from the config. However, it's possible to subscribe the MySQL proxy to an event (using NATS) that notifies when a new realm is added. This event can be sent from the "servers registry" service (I'm referring to this architecture https://github.com/walkline/ToCloud9).

rektbyfaith
Administrator
0
01-02-2024, 09:34 PM
#4
Archived author: walkline • Posted: 2024-01-02T21:34:39.173000+00:00
Original source

Yeah, it's possible to connect to all characters DBs on the worldservers side and route requests from there. However, it would require code changes when interacting with the characters DB, which will break modules, and these changes are not needed for non-clustered mode.
rektbyfaith
01-02-2024, 09:34 PM #4

Archived author: walkline • Posted: 2024-01-02T21:34:39.173000+00:00
Original source

Yeah, it's possible to connect to all characters DBs on the worldservers side and route requests from there. However, it would require code changes when interacting with the characters DB, which will break modules, and these changes are not needed for non-clustered mode.

rektbyfaith
Administrator
0
01-02-2024, 09:36 PM
#5
Archived author: Abillister • Posted: 2024-01-02T21:36:21.938000+00:00
Original source

Well clustering doesn't inherently indicate separate character DB per se. If the goal is for clustering could sharding be used? Theoretically that would offload the "work" to MySQL using built in features rather than needing a separate tool to be built.
rektbyfaith
01-02-2024, 09:36 PM #5

Archived author: Abillister • Posted: 2024-01-02T21:36:21.938000+00:00
Original source

Well clustering doesn't inherently indicate separate character DB per se. If the goal is for clustering could sharding be used? Theoretically that would offload the "work" to MySQL using built in features rather than needing a separate tool to be built.

rektbyfaith
Administrator
0
01-02-2024, 09:39 PM
#6
Archived author: Abillister • Posted: 2024-01-02T21:39:02.457000+00:00
Original source

Though I guess that would still require code changes as it would require a new field for tracking the sharding.
rektbyfaith
01-02-2024, 09:39 PM #6

Archived author: Abillister • Posted: 2024-01-02T21:39:02.457000+00:00
Original source

Though I guess that would still require code changes as it would require a new field for tracking the sharding.

rektbyfaith
Administrator
0
01-02-2024, 09:44 PM
#7
Archived author: Honey • Posted: 2024-01-02T21:44:21.532000+00:00
Original source

I might have misunderstood, but i assumed there would still be a worldserver instance running per realm and an additional instance handling only the cross-server maps.
rektbyfaith
01-02-2024, 09:44 PM #7

Archived author: Honey • Posted: 2024-01-02T21:44:21.532000+00:00
Original source

I might have misunderstood, but i assumed there would still be a worldserver instance running per realm and an additional instance handling only the cross-server maps.

rektbyfaith
Administrator
0
01-02-2024, 09:45 PM
#8
Archived author: Revision • Posted: 2024-01-02T21:45:30.340000+00:00
Original source

at least one per realm
rektbyfaith
01-02-2024, 09:45 PM #8

Archived author: Revision • Posted: 2024-01-02T21:45:30.340000+00:00
Original source

at least one per realm

rektbyfaith
Administrator
0
01-02-2024, 09:47 PM
#9
Archived author: walkline • Posted: 2024-01-02T21:47:39.276000+00:00
Original source

Oh, I think it would require a not small refactoring, and it would be hard to "sell" these changes to our maintainers, since non-cluster mode is the primary and default option. But it's still interesting for me and it would be nice if you could provide more details on this, because i don't see the full picture how it would work.
rektbyfaith
01-02-2024, 09:47 PM #9

Archived author: walkline • Posted: 2024-01-02T21:47:39.276000+00:00
Original source

Oh, I think it would require a not small refactoring, and it would be hard to "sell" these changes to our maintainers, since non-cluster mode is the primary and default option. But it's still interesting for me and it would be nice if you could provide more details on this, because i don't see the full picture how it would work.

rektbyfaith
Administrator
0
01-02-2024, 09:54 PM
#10
Archived author: walkline • Posted: 2024-01-02T21:54:00.581000+00:00
Original source

Almost like that. With the current architecture, every realm has its own characters DB. When we are trying to connect a player to a cross-realm instance, we need somehow to load this player from the DB and save it. To be able to load any player on a cross-realm instance, we need to have a pool of connections to all characters DBs. However, in the current implementation, the worldserver can communicate only with one characters DB.
rektbyfaith
01-02-2024, 09:54 PM #10

Archived author: walkline • Posted: 2024-01-02T21:54:00.581000+00:00
Original source

Almost like that. With the current architecture, every realm has its own characters DB. When we are trying to connect a player to a cross-realm instance, we need somehow to load this player from the DB and save it. To be able to load any player on a cross-realm instance, we need to have a pool of connections to all characters DBs. However, in the current implementation, the worldserver can communicate only with one characters DB.

Pages (2): 1 2 Next
Recently Browsing
 1 Guest(s)
Recently Browsing
 1 Guest(s)