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