[cod] Semi off topic: COD rentals

Tue Sep 28 11:10:54 EDT 2004

Hi Richard,

For us we have a control panel on a central server, although the control
panel can easily be put on any box with Apache etc. The panel then
interfaces with the main database for some of its information, and it
issues instructions out to the slave boxes by means of an in-house
TCP/IP server / client. The slave boxes then connect back into the DB
for more information, for example to fetch out configuration information
or to get the scripts for server setups.

For changes, if it's a filesystem change (modified files with a new
release for example), it's picked up by our daily update scripts as a
module which needs to be updated. The files are transferred through our
TCP/IP server. If we need to manually deploy a change we can select
specific modules in our staff control panel to be queued for transfer on
each relevant slave box. These slave boxes then request the data to be
transferred. If it's a change to server setup routines then these are
just modified in the central database, or stored with the new module if
we keep the old one for backwards compatibility, and will be used
whenever a configuration is made or applied thereafter.
---------------------------------------
Chris Adams
Fragzzhost
T (07005) 964 855
F (07005) 964 857
www.fragzzhost.com

-----Original Message-----
From: Richard Harrison [mailto:richardnharrison at btinternet.com] 
Sent: 28 September 2004 10:16
To: cod at icculus.org
Subject: Re: [cod] Semi off topic: COD rentals

Hi Jay and Chris,

Can i ask a couple of questions about your control panels?

Do you host your control panel on a central server or is it a web server
thats on the game server?
If its the first (and i am presuming it is the first) how do you push
the changes out to the game servers?
I am not asking for trade secrets but if you could explain things in
general terms it would be appreciated.

Ta,
Richard.

Jay Vasallo <haze at clanwarz.net> wrote:
I keep on knocking but I can't get in....

----- Original Message ----- 
From: "Chris Adams" 
To: 
Sent: Monday, September 27, 2004 9:53 AM
Subject: RE: [cod] Semi off topic: COD rentals

> 
> Technically you shouldn't have to be logged in, but that tour is a bit
> out-dated.
> 
> http://cp.fragzz.com/fragzzPanel
> u: trial
> p: sparrow
> 
> That should give you a slightly better view of things :-)
> Let me know when you're done looking and I'll change the pass again...
I
> got bored of turning the server off every so often last time someone
> asked for the trial details :-)
> 
> ----------------------------------------------
> Chris Adams
> Fragzzhost
> 
> T (07005) 964 855
> F (07005) 964 857
> www.fragzzhost.com
> 
> 
> -----Original Message-----
> From: Jay Vasallo [mailto:haze at clanwarz.net] 
> Sent: 27 September 2004 19:05
> To: cod at icculus.org
> Subject: Re: [cod] Semi off topic: COD rentals
> 
> Hi Chris,
> 
> http://cp.fragzz.com/tour
> 
> Do I have to be logged in to see this? I would like to see it. We have
> one 
> almost done. Even thou it says sof2, it will work for any gamne with a

> config. But then this is the old one and not the updated one.
> http://www.clanwarzgamingservers.com/sof2/index.php
> 
> Anyone familar with kkron?
> 
> 
> ----- Original Message ----- 
> From: "Chris Adams" 
> To: 
> Sent: Monday, September 27, 2004 8:55 AM
> Subject: RE: [cod] Semi off topic: COD rentals
> 
> 
>> Yeah we used to do things like that but since I've written the
>> all-powerful multi-gaming control system ;-) it handles all that for
> us
>> (thank god) so we don't really do anything with IPs and ports these
> days
>> since we have our master lists imported into a query / join program
>> luckily. Also it's a bit impractical on the larger boxes that can
hold
>> up to say 20 customers since most ISPs will only give up to 5 or 8
> free
>> IPs, if any at all and often less for dedicated servers.
>>
>> -------------------------------------------
>> Chris Adams
>> Fragzzhost
>>
>> T (07005) 964 855
>> F (07005) 964 857
>> www.fragzzhost.com
>>
>>
>> -----Original Message-----
>> From: Nathan P. [mailto:natedog550 at hotmail.com]
>> Sent: 27 September 2004 16:27
>> To: cod at icculus.org
>> Subject: RE: [cod] Semi off topic: COD rentals
>>
>> The main reason in my opinion for doing virtual interfaces is so that
>> you
>> can give each client their own IP - it still hits the same physical
>> adapter
>> but it's nice having separate IPs per server. The only thing
> hindering
>> some
>> people from that is having to buy the IPs. Most sell for like
> $10/month
>> an
>> IP. But if you were short on cash you could do the port thing but I
>> like
>> having my own IP personally. Easier to keep up with client servers in
>> my
>> opinion :)
>>
>> --
>> NateDog
>>
>>
>>> -----Original Message-----
>>> From: Chris Adams [mailto:chris at fragzzhost.com]
>>> Sent: Monday, September 27, 2004 10:05 AM
>>> To: cod at icculus.org
>>> Subject: RE: [cod] Semi off topic: COD rentals
>>>
>>> No problem - good luck! :-)
>>>
>>> You don't even need virtual interfaces actually if you just change
> the
>>> port number with the net_port cvar :-). I can't remember exactly how
>> CoD
>>> deals with it, but if you put it on your command line and also in
>>> autoexec.cfg followed by a net_restart, you'll definitely be safe
> :-).
>>>
>>> Does anyone know exactly how CoD deals with it? It seems to vary
>> between
>>> the Q3-based games so I have our control engine just do it in every
>>> possible way usually to make sure it works. Would be nice to know
:-)
>>>
>>> ----------------------------------------
>>> Chris Adams
>>> Fragzzhost
>>>
>>> T (07005) 964 855
>>> F (07005) 964 857
>>> www.fragzzhost.com
>>>
>>>
>>> -----Original Message-----
>>> From: Jafo [mailto:jafo at nowhere.ca]
>>> Sent: 27 September 2004 14:42
>>> To: cod at icculus.org
>>> Subject: RE: [cod] Semi off topic: COD rentals
>>>
>>> Hello everyone,
>>>
>>> Thanks to everyone who responded to this thread! I was really
>> expecting
>>> hosting companies to be pretty closed lipped about this! Picked up
>> some
>>> REALLY good information from people's posts thank you very much!
>>>
>>> I'm going to purchase a box, co-lo it and get things started!
>>>
>>> I never even thought about running one set of binaries with virtual
>>> interfaces, that really beats virtual OS installs! Not to mention
the
>>> gains by running one set of binaries with sticky bit set!
>>>
>>> Mark, you provided some really good in depth feedback, I really
>>> appreciate
>>> it!
>>>
>>> Thanks all,
>>> Keith.
>>>
>>> On Sat, 25 Sep 2004, Mark J. DeFilippis wrote:
>>>
>>> >
>>> > If you are executing the same executable and can use parameters on
>> the
>>> > command line that is
>>> > fine. It is the same inode. The question I was answering was for
> a
>>> person
>>> > who appeared to
>>> > not understand why, if Linux is in fact a multiuser/multi-tasking
>> OS,
>>> what
>>> > difference does
>>> > it make if I load from one file or many copies of the file.
>>> >
>>> > In the scenario you present... if you are executing the same file,
>> it
>>> is
>>> > the same
>>> > inode. Make it sticky... and you have the same as the symlink
>>> scenario.
>>> >
>>> > For those admins that wish to have a separate executable in the
> user
>>> > space (on perhaps a server where the admin choose to have the
>>> executable
>>> > in the users space with his other files and configs) the symlink
>>> method works
>>> > very well.
>>> >
>>> > If your servers are being spawned by calling the same executable,
>> you
>>> in fact
>>> > are correct, you get the same benefits. For added savings on load,
>>> make the
>>> > executable
>>> > sticky, and your golden.
>>> >
>>> > Dr. D
>>> >
>>> >
>>> > At 03:51 PM 9/25/2004, you wrote:
>>> >
>>> > >But we execute the same binary in the same path for each server&?
>> Why
>>> the
>>> > >symlink?
>>> > >
>>> > >
>>> > >
>>> > >------------------------------------
>>> > >
>>> > >Chris Adams
>>> > >
>>> > >Fragzzhost
>>> > >
>>> > >
>>> > >
>>> > >T (07005) 964 855
>>> > >
>>> > >F (07005) 964 857
>>> > >
>>> > >www.fragzzhost.com
>>> > >
>>> > >
>>> > >
>>> > >-----Original Message-----
>>> > >From: Mark J. DeFilippis [mailto:defilm at acm.org]
>>> > >Sent: 25 September 2004 20:33
>>> > >To: cod at icculus.org
>>> > >Subject: Re: [cod] Semi off topic: COD rentals
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >You are thinking application level. This is Kernel level.
>>> > >I spent lots of time in my career developing real time embedded
>>> coding
>>> > >in Unix/Linux kernels.
>>> > >
>>> > >Look at two linuxded files that are not sym linked. But use this:
>>> > >
>>> > >ls -li
>>> > >
>>> > >Note the left side has a value called an inode. An inode is a
>> unique
>>> > >identifier for that file. Notice that your two files have
>> different
>>> inodes?
>>> > >
>>> > >When the loader goes to load code for your two servers using
those
>>> > >files, each is copied in to swap (so your swap space is n servers
> *
>>> sizeof
>>> > >executable)
>>> > >The same is true of code segments.
>>> > >
>>> > >If you sym link the two executables (Note they must be on the
same
>>> > >filesystem to do so. If you symlink two files on different file
>>> systems,
>>> > >obviously Linux will have to copy the file to the new file
system,
>>> and it
>>> > >will have a new inode number. (This is because each filesystem
> has
>>> > >it's own superblock, which maps Inodes to file blocks, and file
>>> names.
>>> > >
>>> > >The filename if only for human consumption. All Linux cares about
>> is
>>> that
>>> > >inode number.
>>> > >
>>> > >anyway... If you symlink the two server files, and now do a "ls
>> -li",
>>> > >notice the inode numbers are the same!
>>> > >
>>> > >When you execute the server (with sticky bit on) it is copied to
>>> swap,
>>> > >then pages copied in to ram and executed. When the second server
>>> > >is executed, even though the file has a different path, it has
the
>>> same
>>> > >Inode. The linux kernel looks up the inode, and notes this inode
>> has
>>> > >the sticky bit set, and in fact that it already exists in Swap.
It
>>> copies
>>> > >the pointers to the code segments as I previously mentioned, and
>>> > >begins execution.
>>> > >
>>> > >You ask why?
>>> > >
>>> > >Because 10 servers your way will load 10 copies in to swap, 10
>>> > >copies in to memory, etc. Using the method of symlinks, which
>>> > >is really nothing more than a link in the super block. The super
>>> block
>>> > >maintains all information about which disk blocks belong tio
which
>>> > >files. For your simlink the new file entry simply gets the same
>>> > >inode id copied to the table. Same inode, same code... With
>>> > >shared libraries in memory, for the 10 servers only 1 copy
>>> > >exists in swap. Only 1 copy exists in memory.
>>> > >
>>> > >I hope this is more clear.
>>> > >
>>> > >Dr. D
>>> > >
>>> > >
>>> > >
>>> > >At 02:18 AM 9/25/2004, you wrote:
>>> > >
>>> > >Guess im a little confuused here, why would you symlink when cod
>> (all
>>> > >quake3 base games) support multiple users. using fs_basepath and
>>> > >fs_homepath accomplishes the same thing as symlinking doesnt it?
>>> > >Jase
>>> > >NateDog wrote:
>>> > >
>>> > >
>>> > >Woah......now there's a guy who knows his stuff! Awesome tips
> man!
>>> You
>>> > >really explain things well. Much appreciated.
>>> > >
>>> > >--
>>> > >NateDog
>>> > >
>>> > >----- Original Message ----- From: Mark J. DeFilippis
>>> > >To: cod at icculus.org
>>> > >Sent: Friday, September 24, 2004 9:59 PM
>>> > >Subject: RE: [cod] Semi off topic: COD rentals
>>> > >
>>> > >
>>> > >
>>> > >I had written much about this a while back. I will repeat a bit
of
>>> > >it here for the sake of those who wish to do this. Want to know
> why
>>> > >you should do this, why it works and a bit on how it works...
>>> > >
>>> > >Linking the binaries allows the CPU to share the same Code
segment
>>> pages.
>>> > >Servers
>>> > >will be allocated their own data segments for both Heap and Stack
>>> > >(Which grow towards one another)... One of the reasons Ryan was
>> able
>>> > >to so quickly find that original prob back in 1.1.)
>>> > >
>>> > >If there is a write attempt to the code segment, that server/user
>> is
>>> given
>>> > >their own copy. In the case of most of the shared libs in Linux,
>> the
>>> code
>>> > >is reentrant, and hence these writes don't happen.
>>> > >
>>> > >One other recommendation, I am not certain if I made...
>>> > >
>>> > >You can reduce the spikes you get when a server is restarted by
>>> > >setting the "Sticky" bit on the executable. (Do a man on "mode"
>>> command)
>>> > >What this does is the first time the executable is loaded, the
>> entire
>>> > >executable is copies to SWAP space. Once copied to swap,
> executable
>>> > >pages are copied in to ram to be executed.
>>> > >
>>> > >The best way to keep a server at optimum is to never have to
page.
>>> > >However, under certain conditions, this does happen. It the
>>> executable
>>> > >is sticky, it remains in swap, and the page segment need only be
>>> > >brought back in to memory from swap.
>>> > >
>>> > >Also note, when a second and subsequent user of the Sym Linked
>>> executable
>>> > >starts his/her server, the executable IS NOT copied in to swap
>> again,
>>> it
>>> > >uses
>>> > >the one already in swap (hence the concept "sticky")... it sticks
>>> there.
>>> > >
>>> > >Thus on new startup, A call is made to load the executable,
> however
>>> the
>>> > >Kernel immediately updates the CS and ES code pointers to the
>> shared
>>> > >memory mbufs where the executable code exists, allocates a DS
data
>>> > >segment, and moves your process back to the scheduler for CPU as
>>> > >your I/O is complete.
>>> > >
>>> > >You skip the copy of the executable to SWAP.
>>> > >You skip the copy of pages to Real RAM.
>>> > >You execute off shared pages in memory already with your own set
> of
>>> > >executable
>>> > > registers CS, ES. Get your data segment, and your server
> starts
>>> up.
>>> > >
>>> > >Not only do you save ram, but start impact on the other servers
> due
>>> to I/O
>>> > >DMA transfer setup, and context switching between system and user
>>> space,
>>> > >but you spare the CPU spike as well.
>>> > >
>>> > >Regards
>>> > >
>>> > >Dr. D
>>> > >
>>> > >
>>> > >At 05:08 PM 9/24/2004, you wrote:
>>> > >
>>> > >I just had that question recently also. I did some research on
> the
>>> internet
>>> > >and a lot of peeps are doing symlinks. I tried it with MOH:AA and
>> it
>>> works
>>> > >beautifully, not sure if that's the "right" way to do it but it's
>>> pretty
>>> > >cool cause' you have one base install and symlinks in the other
>>> client
>>> > >folders.
>>> > >
>>> > >--
>>> > >NateDog
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >-----Original Message-----
>>> > >From: John Kennington
[mailto:john.kennington at buzzcard.gatech.edu]
>>> > >Sent: Friday, September 24, 2004 3:04 PM
>>> > >To: cod at icculus.org
>>> > >Subject: RE: [cod] Semi off topic: COD rentals
>>> > >
>>> > >Depending on the number of cpus in the box, you can run 10 to 15
>> CoD
>>> > >servers per
>>> > >box. So it is quite cost effective.
>>> > >
>>> > >John Kennington
>>> > >
>>> > >-----Original Message-----
>>> > >From: Jafo [mailto:jafo at nowhere.ca]
>>> > >Sent: Friday, September 24, 2004 3:58 PM
>>> > >To: cod at icculus.org
>>> > >Subject: [cod] Semi off topic: COD rentals
>>> > >
>>> > >Hello,
>>> > >
>>> > >If this isn't the forum for this question, please forgive me for
>>> asking
>>> > >here.
>>> > >
>>> > >There seems like a lot of people on this list that run "server
>>> rental"
>>> > >operations. Just curious how people are doing that cost
>> effectively?
>>> > >Obviously one can't run each customer's game server on seperate
>>> hardware.
>>> > >Are people using some sort of "virtual linux" installs to run
>>> multiple
>>> > >servers on one box with seperate IP addresses? If that is the
case
>>> how
>>> > >many servers would one dual 2.4 Xeon w/2gig RAM run?
>>> > >
>>> > >Thanks,
>>> > >Jafo
>>> > >
>>> > >
>>> > >
>>> >
>>>
>>>---------------------------------------------------------------------
-
> -
>>> -----
>>> > >
>>> >
>>>
>>>S2-------------------------------------------------------------------
-
> -
>>> ----------
>>> > >Mark J. DeFilippis, Ph. D EE defilm at acm.org
>>> > > defilm at ieee.org
>>> >
>>>
>>
>
S2----------------------------------------------------------------------
>>> ---------
>>> > Mark J. DeFilippis, Ph. D EE defilm at acm.org
>>> > defilm at ieee.org
>>> >
>>> >
>>> >
>>>
>>>
>>
>>
>>
>> 
> 
> 
> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/cod/attachments/20040928/e95e8de9/attachment.htm>