Sharing VSRO Structure (diagrams)
I have made some visual linking for how does server connecting to each Node.
Hope it is usefull, You can view it on the attachment.
NodeLinking-1Machine.pdf
NodeLinking-3Machine.pdf
NodeLinking-2Machine.pdf
Any comment or discussion about it, just replay here ^^ ...
Cheers ,,
Last edited by megaman963; 12-05-12 at 12:51 PM. Reason: Updating Attachments
Nice, I always wondered about this. What about the 2 mahine? :)Originally Posted by megaman963
I have made some visual linking for how does server connecting to each Node.
Hope it is usefull
NodeLinking-1Machine.pdf
NodeLinking-3Machine.pdf
Any comment or discussion about it, just replay here ^^ ...
Cheers ,,
what is role of p_label
also u1,u2,u3......u20?
Re: Sharing VSRO Structure (diagrams)
Here you are, I will update the orignal post ...
NodeLinking-2Machine.pdf
Cheers ,,
You answer can be found on srNodeLink.ini inside Certificate ...
i know where is it
just asking what doing when is enabled p_label=1
Gameservers/agentservers are not connected each other when there are 2 machines, but on your PDF they are connected:
I have 2 machines and this is how they look like:
So the PDF's for the 2 and 3 machines are wrong.
And btw the P Label is something graphical and doesn't affect nothing on the structure, just the P on the link names like what you see on my pic.
kaperucito thnx for answer
and what about u1,u2,u3... so on
Thank you :)
Those are extra parameters, I don't know what they mean so better leave them like that. I know some of them indicate the server ID they belong to, but nothing else.
p_label 0 = server body
p_label 1 = server cord
It is not wrong ... linking will not be wrong ...Gameservers/agentservers are not connected each other when there are 2 machines, but on your PDF they are connected:
I have 2 machines and this is how they look like:
So the PDF's for the 2 and 3 machines are wrong.
And btw the P Label is something graphical and doesn't affect nothing on the structure, just the P on the link names like what you see on my pic.
because the linking could not effect the real structure if you know ...
so how does my server working ?? and why i share the structure ^^ ??
because it is working ...
I agree on your opinion, but however ... it doesn't affect the function of server if they lilnked well ..
Cheers ,,
Maybe someone is interested how the real vietnam testserver was structured, sadly I don't have the screens of the linking :(
I got some screenshots of taiwan server structure too...
Last edited by LegendaryDev; 14-05-12 at 04:56 PM.
Just as a FYI, it is working only because the incorrect parts are being skipped over by the files. As long as you have "enough right", then it should still work.
This is basically what I learned from reversing the certification stuff back in the day:
- There are many ways to get working configs, the way "official" screenshots are setup is not the only way. In fact, non of my configs match official screens because I removed extra nodes not even needed that they use.
- The direction of the links matters.
- The order of the nodes in the packt.dat matters (at least, the first two)
- The extra fields are a mixture of visual data (such as icon id state), important data, such as ids to link to, service type, etc..., and a lot of extra data that is not useless, but does not need to be figured out to get the files working.
- Editing files by hand is both inefficient and impractical for managing multiple server/shard layouts for the long term.
As a result, I wrote tools to automate the certification generation. Here's a few old teaser screens showing the results (Sept. 2011).
Multiple shards, 1 machine setup each:
This image shows a config that made multiple shards rather than a bunch of different independent ones. Each shard was only 1 machine setup, but it could have been easily extended to more, as the next screen shows.
Single shard, 10 machine setup:
I can certainly assure you I did not do those configs by hand!
How much work is it to setup a 10 machine shard using the tool I wrote? It's as easy as 3 files:
edxonline.txt (fictitious name, lol) - This file lists all of the project files used. For however many shards you have, you'd just fix the count and add a shard# entry with the file name.
Spoiler:
eo_global.txt - This file lists the "global" nodes in your server setup. You can easily add Download or Gateways as your server expands. The ID was left for being able to key it exactly how you want, so when you add more nodes, the ids won't change unless you change them yourself.
Spoiler:
eo_shard1.txt - Each agent/gameserver is listed. If you need more, it's just a matter of adding the entries, if you need less, you can chop them out and update the count.
Spoiler:
Once those project files are setup, I run my tool to generate the inis based on templates. Once the inis are done, it's simply a matter of running my Convert to go from ini->packt and then running the certification server using that packt.
Anyways, point of this post is simple: if you want to learn the VSRO structure, start from scratch. Build your way up to working configurations and reference the old JSRO packt.dat dumped (that's what my tools were originally written for). It's not easy and it takes a lot of time, but if you work through doing what I did with all my tools, you'll be able to come up with automatic tools to easily generate, manipulate, and maintenance larger server/shard setups without having to touch the files again by hand.
Can you post those also? Would like to check them.Maybe someone is interested how the real vietnam testserver was structured, sadly I don't have the screens of the linking :(
I got some screenshots of taiwan server structure too...
