Multi-Zone Server Support

[GreenBox]

Our char-server can hold multiple zone-servers and handle the client connection correctly between them, but the switch process between zone-servers is a big fail.

During this process the map_session_data struct which holds temporary session data aren't synced with the new zone -server causing session data loss.

Temporary script variables(@var) aren't synced too, so scripts operating with temporary data between zone-servers will not work too.

Also we have a third but minor problem: query_sql, as many scripts query the login table(VIP scripts) we may need another command to query the "main" database, though the login-server.

This issue remembered all those problems, now we need to ask: Is multi-zone server really needed? If yes, what is the best design to fix those problems?

[Cookie]

I'd say it is necessary especially if there's functionality already in place (whether it's functional or semi-functional) and not only that it appears it just needs to be completed. To be honest, I haven't really messed with that code at all and I can only count on my fingers the amount of times I've set-up multiple zone servers - it was really for testing purposes if anything. The problems you listed are all valid though. I personally think the temporary script variables should sync.

[Cookie]

I'd say temporary character variables should sync. That's just my opinion. It all really depends, though.

[Lighta]

I think they shouldn't sync, well I just modelizing the thing as 2 different map-server so it normal that those doesn't follow.

Otherwise they would need to be handle differently and perhaps complicate stuff without good reason, at worst/better we could always add a new symbol for that feature.

A easy quickaround for that would be to writte in sql then when char totaly disconect to erase all variable referenced with that symbol.

The query_sql is a much more important matter imo, even trough most people install all 3 server and schemas on the same host, they could all be splitted, was working quite well when I tryed.

Or I often see people doing script with direct acces to char_db implicitly breaking that indenpendancy. (Just imagine setting another schema in same host wouldn't work either so we implicitly nerf inter_conf)

Guess we could add type for query_sql wich then will redirect to inter to do the proper job. Altough this will increase sql result latency in scripts.

But working on this and renew it may even facilitate the threading implemantation of Sirius White. saw he was trying to do those as thread instead seq like now.

[GreenBox]

The multi-zone support should be seen as a tool for load balancing as in Aegis and not for using different configs. Actually they could work on both ways through some macro or map config.

For the query_sql I can see two ways to solve our problem:

An DB Server,

Which acts as an interface between the servers and the database, this would be a totally abstract layer so we could implement others DBs than MySQL like PostgreSQL and SQLite.

For this option I prefer to have the option to use it or not as for the default setup, an extra process could be a problem for systems with low resources.

Another option is send the queries to the login-server or the char-server and wait the response.