Jump to content

"Mothership" Server


bdmovies

Recommended Posts

Say I've got this:

 

Company A needs to utilize the services of Company B. Both Companies are using my application. Company A can assign Company B to the job. <-- This sounds simple enough, Company A needs to create a profile for Company B and can then just assign them as needed (Company B would be equivilant to an employee in Company A, but Com. B is serving some area of the country where A does not have employees).

 

Now the cool part. When A assigns B to the job, B gets the information automatically added to it's DB. A and B's servers are both sitting on the companies local servers. So, I need a way to get the info from A to B. Here are my possible solutions:

 

1. I've got a "Mothership" server that gets updated when A assigns B. Then, B queries the Mothership DB to see if they have a new job.

 

Pros to 1:

I can keep my DB schema from A to mothership to B.

It's conservative (I know this would work)

 

Cons to 1:

Any changes to schema would have to be reflected on the mothership server.

HEAVY traffic on the mothership database. The query from A to Mship would have to occur periodically (Like, every few seconds, minutes at most.) If I just had A and B companies it would be fine, but looking into the future, what happens when I've got companies A, B, C, all the way through ZZ? Or, in reality, when we've got a network of hundreds of companies (Our target number of clients is in the 100's).

 

2. Use SOAP to work directly with A and B, no mothership needed.

 

Pros to 2

No mothership

 

Cons to 2:

I have no knowledge of SOAP.

Heavy traffic on each companies servers

 

That's where I am at now. I was also contemplating an XML based file containing all of the info needed, and storing that file in the DB. I still have lots of calls to the DB, but the DB is smaller in size. I also thought about using XML and a file system on the mothership server, but that sounds dangerous.

 

Thoughts?

Link to post
Share on other sites

Couldn't the server that needs to be modified always listen?

 

 

For example, if my friend across the room wants to tell me something, I wouldn't periodically ask him if he has anything to say.  I would be listening (maybe :P) and he would just tell me.

 

Pros:

Minimal traffic

 

Cons:

Always listening, thus always running, although the overhead would be very, very small.

 

 

Or maybe I've misunderstood the question.  Now that I reread it, I think I have, but the concept could still apply.

 

 

 

 

 

 

 

(And for those out there that are going to want to generalize, I do realize that constantly listening could, indeed, be a bad idea sometimes.)

Link to post
Share on other sites

I guess that always listening could work, but I really don't want to go down that route. I have a feeling Security would come up quite a bit. But how exactly would that work? I would need a listener on EVERY page of my app.

 

Maybe I'm missing something, but if there is a constant listening, wouldn't that mean high traffic?

Link to post
Share on other sites

Why would every page of your app need to listen?  You would have one script/application listening.  Also, why would listening create traffic?  Perhaps you're thinking of polling and not listening?

 

 

What exactly is your server setup again?

 

 

Serv A and B are entirely separated, in different LANs?

Link to post
Share on other sites

So, I've decided to just use a completely unnormalized table on the mothership. When a admin goes to the home.php page an ajax call is sent to the mothership, if it returns true, then there are jobs there (SELECT COUNT(*) FROM lightspeed WHERE pServer = 'someuniquevalue' AND down = '0').

 

SOAP just seemed like too much work for this.

Link to post
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.