LookitsPuck
Jun 14th, 2006, 01:08 PM
So I've decided to go the route of using a master server mainly for distributing loads properly (taking into account users per server, but also average ping over a certain amount of time). But it will also keep master user lists and what chat rooms they're in and the such.
What I'm confused about is how to make the socket server application generic enough that it can communicate with each socket server. Say, for example, that I have three slave servers: S1, S2, and S3. S1 will need to communicate directly with S2 and S3. S2 will need to communicate directly with S1 and S3, and S3 will need to communicate directly with S1 and S2. This will be done via sockets, and I will be using a config file to list all the servers, IPs, and that jazz to what to connect to. Basically, a new thread will spawn on start up for each server and will communicate with each other via those threads.
This is where I'm getting confused, when a socket connection is opened, it's both ways, correct? Currently the server is accepting user connections for IMing, chatting, creating chat rooms, and whatever. Now, as said prior, a new thread will spawn for each server in the config file. My dilemma is how to make this generic enough: remember this:
S1->S2
S1->S3
S2->S1
S2->S3
S3->S2
S3->S1
From what I understand, I'll need to initiate a connection to S2 from S1, and S2 will need to listen. Same for S3 as a listener. But wouldn't this get redundant? Having S1 have a two way connection to S2, and then S2 will have to have a two way connection to S1? Is there a way to make a one way connection per? I don't think I'm phrasing my issue correctly, but hopefully some of the experts here can see my dilemma.
I guess to further clarify this, this is what the dilemma is:
I need to make each slave server a listener for all the other slave servers. But they also need to initiate the connection from each other (effectively making them clients). How do I do this so it's pretty much an adapt the config file issue and just install on to each server to make it scalable?
Additional info:
Well, here are the details of the setup:
.NET 2.0
MySQL backend
W2K3.
Currently, it's a single server setup. Inevitably due to the number of socket connections being limited per server as well as performance reasons, we're probably going to need 3 servers (4 including the master) for this setup. I'd like to make it scalable so adding new servers is a quick and painless procedure.
My only problem is that I'd like the servers to communicate directly with eachother. Take for example a chat room that has like 50 people in it, 30 from the same server, 20 from 2 other servers. Sending the messages to the 30 from the same server is easy. Sending it to the other 20 whilst maintaing some sort of performance isn't such. The queue idea (MSMQ) leaves a middle man for some functionality, as a SENDCHAT command would need to be queued to the master, then the master distributes to each slave server to be queued, and then the slave server retrieves it. Furthermore, this becomes even more an issue outside of chatting when there are dynamic events (this is going to be a game, btw) that utilize bandwidth. I'd like to keep the middle man out of this as much as possible. Basically I'd like the slave server to shoot the message to the appropriate people on the server, then hand off the message directly to the other servers so they can handle it right away.
Has anyone utilized this sort of method before? I'm pretty sure it has been.
What I'm confused about is how to make the socket server application generic enough that it can communicate with each socket server. Say, for example, that I have three slave servers: S1, S2, and S3. S1 will need to communicate directly with S2 and S3. S2 will need to communicate directly with S1 and S3, and S3 will need to communicate directly with S1 and S2. This will be done via sockets, and I will be using a config file to list all the servers, IPs, and that jazz to what to connect to. Basically, a new thread will spawn on start up for each server and will communicate with each other via those threads.
This is where I'm getting confused, when a socket connection is opened, it's both ways, correct? Currently the server is accepting user connections for IMing, chatting, creating chat rooms, and whatever. Now, as said prior, a new thread will spawn for each server in the config file. My dilemma is how to make this generic enough: remember this:
S1->S2
S1->S3
S2->S1
S2->S3
S3->S2
S3->S1
From what I understand, I'll need to initiate a connection to S2 from S1, and S2 will need to listen. Same for S3 as a listener. But wouldn't this get redundant? Having S1 have a two way connection to S2, and then S2 will have to have a two way connection to S1? Is there a way to make a one way connection per? I don't think I'm phrasing my issue correctly, but hopefully some of the experts here can see my dilemma.
I guess to further clarify this, this is what the dilemma is:
I need to make each slave server a listener for all the other slave servers. But they also need to initiate the connection from each other (effectively making them clients). How do I do this so it's pretty much an adapt the config file issue and just install on to each server to make it scalable?
Additional info:
Well, here are the details of the setup:
.NET 2.0
MySQL backend
W2K3.
Currently, it's a single server setup. Inevitably due to the number of socket connections being limited per server as well as performance reasons, we're probably going to need 3 servers (4 including the master) for this setup. I'd like to make it scalable so adding new servers is a quick and painless procedure.
My only problem is that I'd like the servers to communicate directly with eachother. Take for example a chat room that has like 50 people in it, 30 from the same server, 20 from 2 other servers. Sending the messages to the 30 from the same server is easy. Sending it to the other 20 whilst maintaing some sort of performance isn't such. The queue idea (MSMQ) leaves a middle man for some functionality, as a SENDCHAT command would need to be queued to the master, then the master distributes to each slave server to be queued, and then the slave server retrieves it. Furthermore, this becomes even more an issue outside of chatting when there are dynamic events (this is going to be a game, btw) that utilize bandwidth. I'd like to keep the middle man out of this as much as possible. Basically I'd like the slave server to shoot the message to the appropriate people on the server, then hand off the message directly to the other servers so they can handle it right away.
Has anyone utilized this sort of method before? I'm pretty sure it has been.