Maybe this can help show I'm no random noob. This was my latest brainstorm about the server operation that I posted on another forum but I'll repost here.
</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>QUOTE (Zero)</td></tr><tr><td id='QUOTE'>I'm posting this for pure thought process and maybe feedback. I'd post it on my own forum but everyone there doesn't play CO and couldn't provide feedback on top of not giving a shit :P
I was thinking of how TQ manages all their servers. Half/half all connect on the same ip and same port. Though there may be two auth servers in that case (two different servers each running a single exe - two auth servers running ~33 game servers under each exe).
This might explain high ping times because a single exe is handling the thousands of sockets and packets per second from all the players connected to that tree of servers. Back when it used to be one group, ping was low and very responsive.
Anyway, they had to have used multiple threads because a single thread would burn under this kind of pressure. We'd see pings more into the thousands regularly and never below 1k. The receive function itself would be situated on the main thread seeing as it probably runs through api and the main thread handles api. (if written in c++ which is most likely)
The send functions all operate separate contained within the parent server thread. Basically a thread per server with child threads per server thread running game operations. I currently run my sources without a server class because I figured I'd have each server run a separate exe.. but ever wonder why when one server is down, more go down? Or how certain servers are up yet others aren't? It's all controlled via a single app I believe through which they can actively start/restart/close/manage each specific server via it (if they did it intelligently) or just a single exe that manages it all itself.
wewt.
Main entry thread
-> \/ breaks off into specific server threads
server thread 1
-> breaks off into threads to control server aspects etc.
server thread 2
-> breaks off into threads to control server aspects etc.
each server maintaining its own memory space within global vars accessible by all servers at any time and the auth server also meaning possible instant statistics over multiple servers. On top of that, this opens up the ability to cross server communicate for example kicking a char off that logged onto another server on the same account.
I did a similar practice with my login server I coded for my previous game. It ran two separate exes naturally, a main (account controller) and a world (character controller and server gateway) in which I combined them both and created dynamic loading worlds based off a config meaning ultimately multiple servers hosted under a single exe (not game servers, but their gateway they had to connect to for server settings and data). With this it's just a matter of reusing that in here and creating a server class to create on startup.
The main thread would manage the message pump while each server thread could have it's own message queue (that I'd build myself) for processing messages between auth server and other servers so as to not cause access conflicts.
The class would be such
G_pServer[DEF_SERVERCOUNT];
each array position representing another server and each server maintaining it's own client class list and such. Ultimately the only memory they'd share directly is the address location to their private memory and then indirectly all the data contained within that server.
meh. </brainstorm>
[/b][/quote]
If anyone would like to help, learn more info, or whatever you can add me to msn
. It would be much appreciated and I can give back to the community tenfold if not more. I can begin releases as soon as I code it possible to fully login (or before, but there'd be little point to that). I'll say it in hopes someone breaks down over it 





