Quote:
Originally Posted by Derision
I didn't realise you intended queryserv to run 'off-site', I just saw it as a convenient way to:
a) Avoid making database calls in the main thread, which I hate, and using queryserv was easier than using the existing zone dbasync thread.
b) Avoid the issue of syncing data between zone processes, again without having to read/write the database in the main thread, when updates to that data could be made in any zone.
I could move the LFGuild stuff out of queryserv and back into zone, but I would want to put it into the async DB thread which would mean writing an easier to use interface to dbasync, which I have thought about off-and-on for a while and would be an interesting exercise.
Another option would be to allow for multiple queryserv processes. When a queryserv process connects, it would tell world which server opcodes it would handle, e.g. you could have a queryserv co-located with world/zones which would say, 'hey, send me all ServerOP_LFGuild packets', and an off-site one which would say, 'send me all logging packets'.
|
I'm a big fan of the second option honestly. That seems like a fair compromise. The reason to make queryserv was 1) performance in the main thread 2) Disk I/O as a result of many database queries on-site. 3) A place to put things that don't require immediate results from the database. 4) A 'hack' to use multiple processors by creating another executable.
By allowing different queryservs to connect (maybe like the loginserver does?) in different configs, that would work best, at least in my opinion. Can have a log.ini-style file that loads each 'option' for what the queryserv should handle. Have QueryServ set that on connecting.
Threaded Mode
