Re: [hlds_linux] erm question
On 7/17/05, Steve Dalberg <[EMAIL PROTECTED]> wrote: > Lastly, and I'm not sure on this, but I don't believe that > all updates from a server to client are identical, but I'm not sure... "Game data is compressed using delta compression to reduce network load. That means the server doesn't send a full world snapshot each time, but rather only changes (a delta snapshot) that happened since the last acknowledged update. With each packet sent between the client and server, acknowledge numbers are attached to keep track of their data flow. Usually full (non-delta) snapshots are only sent when a game starts or a client suffers from heavy packet loss for a couple of seconds. Clients can request a full snapshot manually with the cl_fullupdate command." -- http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Request a higher minimum value for cl_cmdrate.
When you decrease the cl_updaterate without decreasing the rate, then the DTT increases. On 7/16/05, Clayton Macleod <[EMAIL PROTECTED]> wrote: > but it's not, the server takes into account your latency and the 100ms > delay... > > On 7/16/05, James Tucker <[EMAIL PROTECTED]> wrote: > > That's not as important as the accuracy with which you aim at a model > > which is now up to 100ms out of place. > > > -- > Clayton Macleod > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] (no subject)
Quoting Sebastian <[EMAIL PROTECTED]>: Lmao...Np rgr that...And for Macleod I got a good laff outta that thanx man :-) And you fellas are correct I should have read the manual first..But that thing reads like directions to a mattel toy.Too tell you the truth at first glance I was stoopified.I was just hoping someone had a script made up er sumthing so I didn't have to take hours tring to understand the manual.But I found a post on valves website with a dir script that worked well.Thanks again for the help and sry to all for the "troubles". > can you guys cut the crap already? man. > > [EMAIL PROTECTED] wrote: > > >Quoting Clayton Macleod <[EMAIL PROTECTED]>: > >Indeed. > > > > > >>truly pathetic > >> > >>On 7/17/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> > >> > >>>Quoting Clayton Macleod <[EMAIL PROTECTED]>: > >>> > >>> > >>>um yeah good one! Your parents must be proud. > >>> > >>> > >>> > >>> > > > -- > Certified E-mail - No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.336 / Virus Database: 267.9.0/50 - Release Date: 7/16/2005 > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] (no subject)
can you guys cut the crap already? man. [EMAIL PROTECTED] wrote: Quoting Clayton Macleod <[EMAIL PROTECTED]>: Indeed. truly pathetic On 7/17/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Quoting Clayton Macleod <[EMAIL PROTECTED]>: um yeah good one! Your parents must be proud. -- Certified E-mail - No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.336 / Virus Database: 267.9.0/50 - Release Date: 7/16/2005 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] (no subject)
rtfm On 7/17/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Quoting Clayton Macleod <[EMAIL PROTECTED]>: > Indeed. -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] (no subject)
Quoting Clayton Macleod <[EMAIL PROTECTED]>: Indeed. > truly pathetic > > On 7/17/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Quoting Clayton Macleod <[EMAIL PROTECTED]>: > > > > > > um yeah good one! Your parents must be proud. > > > -- > Clayton Macleod > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] erm question
krio the d34d1 wrote: i've said "as an option" oh and yeah, its ok to multicast to those only who support it and unicast to the rest, isn't it? No. Not really. If you are LAN'ing, then there is no point as I've said previously, so lets take the example of connecting via the internet... You have an ISP... While they *may* run some multicast routing protocol (PIM for example), they will not extend that to the end user. They will not extend that to peers, except for contractual obligations (ie someone pays them to). Its really nasty, and taxing on routers. Keep in mind that a multicast address is always a destination address. So a node joins a multicast group and the router will (once Multicast routing does its thing) forward the traffic to the host. Imagine hosts one the internet constantly joining and leaving multicast groups... Routers will have a hard time keeping up, and that much constant change isn't something that a network operator likes... ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] (no subject)
truly pathetic On 7/17/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Quoting Clayton Macleod <[EMAIL PROTECTED]>: > > > um yeah good one! Your parents must be proud. -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] (no subject)
Quoting Clayton Macleod <[EMAIL PROTECTED]>: um yeah good one! Your parents must be proud. > spinner, you're such a fool...and SO mature yourself... > > > On 7/17/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Quoting Stan Bubrouski <[EMAIL PROTECTED]>: > > Ive found that using proxies helped me by RTFM.Now THIS IS THE PROBLEM > > > > > > http://www.cs-sourcemod.com/Forums/index.php?act=Attach&type=post&id=209 > > > > but don't go there.Please don't I wouldnt want you to waste your > time.Someone > > with a little more maturity please, Then maybe we can find an answer to why > the > > url shows up when It shouldnt Instead of getting another letter by someone > with > > there "HoCkEy HeLmet" strap on too tight. > > > > Best regaurds and a thank you for not repling back to this massage. > > > -- > Clayton Macleod > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] erm question
Well, not yet.. I've messed around with mBGP and it's just not useful right now.. At 01:40 PM 7/17/2005, Steve Dalberg wrote: Ok, it appears that you have heard about multicast, but haven't actually tried to use it... First thing, the application (server and client) would have to support it... Second, this would only work on a LAN or enterprise environment, as internet carriers do not share multicast routing info. And if it were a LAN, why bother, since bandwidth is not an issue... Lastly, and I'm not sure on this, but I don't believe that all updates from a server to client are identical, but I'm not sure... Could be, in which case if everything above was obviated, then it would work. IPv6 does address this, as Multicast addresses will be a subset of IPv6 larger networks, but it is still unclear of carriers will support actual multicasting. Still about a decade off anyways (except for those in Asia maybe) krio the d34d1 wrote: why not to use multicast, probably as an option, for server -> clients packet flow? lets see. let "a" be the ammount of bytes to be send to specify a full one player state at a frame(coords or whatever) let "n" be the number of players. current way, if i get it right: clients -> server: a*n server -> clients: a*n*n (should be a*n*(n-1) but world isnt perfect) sum: a*(n+n*n) example 32 players: a*1056 multicast way: clients -> server: a*n server -> clients: a*n sum: 2*a*n example 32 players: a*64 that would erm cut like 93.9% of bandwidth used on a 32 slot server? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] (no subject)
spinner, you're such a fool...and SO mature yourself... On 7/17/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Quoting Stan Bubrouski <[EMAIL PROTECTED]>: > Ive found that using proxies helped me by RTFM.Now THIS IS THE PROBLEM > > > http://www.cs-sourcemod.com/Forums/index.php?act=Attach&type=post&id=209 > > but don't go there.Please don't I wouldnt want you to waste your time.Someone > with a little more maturity please, Then maybe we can find an answer to why > the > url shows up when It shouldnt Instead of getting another letter by someone > with > there "HoCkEy HeLmet" strap on too tight. > > Best regaurds and a thank you for not repling back to this massage. -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] erm question
i've said "as an option" oh and yeah, its ok to multicast to those only who support it and unicast to the rest, isn't it? plus a bit of control over it for server admins and we hit the jackpot in the near future. 2005/7/17, e-Plutonia <[EMAIL PROTECTED]>: > IPv6 in US, yes at least 1/2 a decade, in europe, they may have parts > set with IPv6, in which case, implementing this in the near future > would not be such a dumb idea. And also considering that right now > IPv6 > IPv4 & vice versa translations are possible. Just not multicast > traffic yet. > > On 7/17/05, Steve Dalberg <[EMAIL PROTECTED]> wrote: > > Ok, it appears that you have heard about multicast, but haven't actually > > tried to use it... First thing, the application (server and client) > > would have to support it... Second, this would only work on a LAN or > > enterprise environment, as internet carriers do not share multicast > > routing info. And if it were a LAN, why bother, since bandwidth is not > > an issue... Lastly, and I'm not sure on this, but I don't believe that > > all updates from a server to client are identical, but I'm not sure... > > Could be, in which case if everything above was obviated, then it would > > work. > > > > IPv6 does address this, as Multicast addresses will be a subset of IPv6 > > larger networks, but it is still unclear of carriers will support actual > > multicasting. Still about a decade off anyways (except for those in > > Asia maybe) > > > > krio the d34d1 wrote: > > > > >why not to use multicast, probably as an option, for server -> clients > > >packet flow? > > >lets see. > > >let "a" be the ammount of bytes to be send to specify a full one > > >player state at a frame(coords or whatever) > > >let "n" be the number of players. > > > > > >current way, if i get it right: > > >clients -> server: a*n > > >server -> clients: a*n*n (should be a*n*(n-1) but world isnt perfect) > > >sum: a*(n+n*n) > > >example 32 players: a*1056 > > > > > >multicast way: > > >clients -> server: a*n > > >server -> clients: a*n > > >sum: 2*a*n > > >example 32 players: a*64 > > > > > > > > >that would erm cut like 93.9% of bandwidth used on a 32 slot server? > > > > > >___ > > >To unsubscribe, edit your list preferences, or view the list archives, > > >please visit: > > >http://list.valvesoftware.com/mailman/listinfo/hlds_linux > > > > > > > > > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > > > > > -- > DJ Fadyeyev > Founder > e-Plutonia > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] HTTP Download.
For those of you who typed sv_downloadurl and got "" it is because not every
server has it set up. Some simply let you dl from the server playing the
game instead of a separate location.
- Original Message -
From: "Simon Lange" <[EMAIL PROTECTED]>
To:
Sent: Sunday, July 17, 2005 8:00 AM
Subject: RE: [hlds_linux] HTTP Download.
apache has bandwidthlimiting too, but ppl usin downloadurl becuase the
DONT
WANT bandwidth limiting. however, the best was is to user mod_rewrite and
to
check condition if the remote http refferer is one of the allowed
gameservers. if not, well, one way would be to throw an error, another way
would be to direct them to ur website.
if the remote http refferer is correct (hl2://) u allow access with
full
speed. well, if u still want bandwidth shaping use one of the bandwidth
shaping modules coming with apache1/2 :)
almost forgot: u can use mod_rewrite directives within ur .htaccess
container. ;)
regards
Simon
PS: and now please back to mailinglist topic... knowledge how to
configure/secure apache is an issue of another mailinglist. :D
Simon Lange //Director
www.polynaturedesign.com
+49[0]4131 220121 PHONE
+49[0]4131 224730 FAX
+49[0]1717793294 CELL
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bart King
Sent: Sunday, July 17, 2005 11:08 AM
To: hlds_linux@list.valvesoftware.com
Subject: RE: [hlds_linux] HTTP Download.
Hi all, to drop in my two pence on this:
On our 64 player server using sv_downloadurl, we have a different
solution.
Instead of running Apache (which is a little bulky just for serving HTTP
requests from Half-Life 2 clients), we run thttpd, a much lighter web
server
that also has the advantage of rate limiting. We then limit thttpd's
total
outgoing traffic to around 250KB/s.
This never appears to be much of a problem, since when the map does change
to a custom map, typically, only 5-10% of clients end up downloading it -
either the rest of the 60+ clients have it already or disconnect because
it's not de_dust ("OMG WTF I PLEH DUST").
Although, if we're playing a new map that no-one will have, we sometimes
drop the rate limit so our regulars can fetch without waiting too long.
It's all a question of balance - I would find restricting the requests to
HL2 only a little constrained.
Of course, you can always tell people to download maps off the web
prior...
[ ToldYa.GIF of type image/gif deleted ]
*grin*
--
Bart King -- http://www.bart666.com
+44 781 219 5654 -- PGP: 0xC9C3EB8B
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] erm question
IPv6 in US, yes at least 1/2 a decade, in europe, they may have parts set with IPv6, in which case, implementing this in the near future would not be such a dumb idea. And also considering that right now IPv6 > IPv4 & vice versa translations are possible. Just not multicast traffic yet. On 7/17/05, Steve Dalberg <[EMAIL PROTECTED]> wrote: > Ok, it appears that you have heard about multicast, but haven't actually > tried to use it... First thing, the application (server and client) > would have to support it... Second, this would only work on a LAN or > enterprise environment, as internet carriers do not share multicast > routing info. And if it were a LAN, why bother, since bandwidth is not > an issue... Lastly, and I'm not sure on this, but I don't believe that > all updates from a server to client are identical, but I'm not sure... > Could be, in which case if everything above was obviated, then it would > work. > > IPv6 does address this, as Multicast addresses will be a subset of IPv6 > larger networks, but it is still unclear of carriers will support actual > multicasting. Still about a decade off anyways (except for those in > Asia maybe) > > krio the d34d1 wrote: > > >why not to use multicast, probably as an option, for server -> clients > >packet flow? > >lets see. > >let "a" be the ammount of bytes to be send to specify a full one > >player state at a frame(coords or whatever) > >let "n" be the number of players. > > > >current way, if i get it right: > >clients -> server: a*n > >server -> clients: a*n*n (should be a*n*(n-1) but world isnt perfect) > >sum: a*(n+n*n) > >example 32 players: a*1056 > > > >multicast way: > >clients -> server: a*n > >server -> clients: a*n > >sum: 2*a*n > >example 32 players: a*64 > > > > > >that would erm cut like 93.9% of bandwidth used on a 32 slot server? > > > >___ > >To unsubscribe, edit your list preferences, or view the list archives, > >please visit: > >http://list.valvesoftware.com/mailman/listinfo/hlds_linux > > > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > -- DJ Fadyeyev Founder e-Plutonia ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] srcds setup: sv_forcepreload cvar / heapsize parameter
I have been looking at this as well, Free to Inactive Memory can cause
issues, it would be nice to be able to cause the proccesses to only be
able to gain memory, rather that allow them to release into inactive.
I know everyone running on 512 MB > on their servers will be flaming
me, but when you have 2 to 4 GB's of memory, and a 2 GB swap on top of
that, which is never used, you would sacrifice memory for performance.
On 7/17/05, Christoph Franke <[EMAIL PROTECTED]> wrote:
> --
> Hello folks,
>
> just wanted to know what the cvar sv_forcepreload is _exactly_ for and
> if it is advisable to set it to 1 on a dedicated linux server. The other
> question is, if one can achieve a performance gain by setting an above
> default heapsize. Lots of rumors circulate ("use 1/2 of your physical
> ram"), but no hardened facts, as far as my research went. I come to
> think, that at some point these huge memory reservations get
> counterproductive. But I might err. So what's your advise?
>
> Server is a dual opteron with 2 GB ECC Ram.
>
> Regards
>
> Christoph
> --
> Content-Description: Digital signature
>
> [ signature.asc of type application/pgp-signature deleted ]
> --
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives, please
> visit:
> http://list.valvesoftware.com/mailman/listinfo/hlds_linux
>
--
DJ Fadyeyev
Founder
e-Plutonia
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] erm question
Ok, it appears that you have heard about multicast, but haven't actually tried to use it... First thing, the application (server and client) would have to support it... Second, this would only work on a LAN or enterprise environment, as internet carriers do not share multicast routing info. And if it were a LAN, why bother, since bandwidth is not an issue... Lastly, and I'm not sure on this, but I don't believe that all updates from a server to client are identical, but I'm not sure... Could be, in which case if everything above was obviated, then it would work. IPv6 does address this, as Multicast addresses will be a subset of IPv6 larger networks, but it is still unclear of carriers will support actual multicasting. Still about a decade off anyways (except for those in Asia maybe) krio the d34d1 wrote: why not to use multicast, probably as an option, for server -> clients packet flow? lets see. let "a" be the ammount of bytes to be send to specify a full one player state at a frame(coords or whatever) let "n" be the number of players. current way, if i get it right: clients -> server: a*n server -> clients: a*n*n (should be a*n*(n-1) but world isnt perfect) sum: a*(n+n*n) example 32 players: a*1056 multicast way: clients -> server: a*n server -> clients: a*n sum: 2*a*n example 32 players: a*64 that would erm cut like 93.9% of bandwidth used on a 32 slot server? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
[hlds_linux] mp_teamplay?
Hi there, I was just looking thorugh a customer's css server.cfg when I found the entry mp_teamplay "2048" Well, what does this cvar do with this value? I googled around and found out that the default value is 0 and that one source told me that it defines whether the players play team death match or deathmatch. But does this make sense on a counter-strike server? There are always teams, however. And even if it defines whether to play in teams or not - what is the sense in setting it to "2048"? What does the server do with this value? Hope for an anwer. Jens -- [EMAIL PROTECTED] 0531 349 2007 0179 546 4887 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
[hlds_linux] erm question
why not to use multicast, probably as an option, for server -> clients packet flow? lets see. let "a" be the ammount of bytes to be send to specify a full one player state at a frame(coords or whatever) let "n" be the number of players. current way, if i get it right: clients -> server: a*n server -> clients: a*n*n (should be a*n*(n-1) but world isnt perfect) sum: a*(n+n*n) example 32 players: a*1056 multicast way: clients -> server: a*n server -> clients: a*n sum: 2*a*n example 32 players: a*64 that would erm cut like 93.9% of bandwidth used on a 32 slot server? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] (no subject)
Quoting Stan Bubrouski <[EMAIL PROTECTED]>: Ive found that using proxies helped me by RTFM.Now THIS IS THE PROBLEM http://www.cs-sourcemod.com/Forums/index.php?act=Attach&type=post&id=209 but don't go there.Please don't I wouldnt want you to waste your time.Someone with a little more maturity please, Then maybe we can find an answer to why the url shows up when It shouldnt Instead of getting another letter by someone with there "HoCkEy HeLmet" strap on too tight. Best regaurds and a thank you for not repling back to this massage. > 6ft vertical holes should be dug for message senders like this. If > you read the examples provided with Apache for using htaccess you'd > see you can accomplish what you want without having to write even a > simple script. Sadly since reading a manual seems to be below you or > you're not capable of following directions I don't know if you can be > helped. > > If you were having problems using htaccess most likely you setup your > .htaccess incorrectly and if you had posted or something someone might > have been able to help you. For assistence (and waste of time) > contact a local mental health professional for anger management > classes. > > -sb > > On 7/16/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > Ive used a .htaccess and the access from web browser stopped.Although I > could > > download maps,etc from server just fine, while some clients complain'd > about > > getting the "you do not have this map".To the ppl tring to help thank you > for > > your time.To the ppl stating RTFM <- you can stop wasting your > time.Because > > thats all you seem to beA WASTE OF TIME. > > > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] (no subject)
6ft vertical holes should be dug for message senders like this. If you read the examples provided with Apache for using htaccess you'd see you can accomplish what you want without having to write even a simple script. Sadly since reading a manual seems to be below you or you're not capable of following directions I don't know if you can be helped. If you were having problems using htaccess most likely you setup your .htaccess incorrectly and if you had posted or something someone might have been able to help you. For assistence (and waste of time) contact a local mental health professional for anger management classes. -sb On 7/16/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Ive used a .htaccess and the access from web browser stopped.Although I could > download maps,etc from server just fine, while some clients complain'd about > getting the "you do not have this map".To the ppl tring to help thank you for > your time.To the ppl stating RTFM <- you can stop wasting your time.Because > thats all you seem to beA WASTE OF TIME. > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
[hlds_linux] srcds setup: sv_forcepreload cvar / heapsize parameter
--
Hello folks,
just wanted to know what the cvar sv_forcepreload is _exactly_ for and
if it is advisable to set it to 1 on a dedicated linux server. The other
question is, if one can achieve a performance gain by setting an above
default heapsize. Lots of rumors circulate ("use 1/2 of your physical
ram"), but no hardened facts, as far as my research went. I come to
think, that at some point these huge memory reservations get
counterproductive. But I might err. So what's your advise?
Server is a dual opteron with 2 GB ECC Ram.
Regards
Christoph
--
Content-Description: Digital signature
[ signature.asc of type application/pgp-signature deleted ]
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
RE: [hlds_linux] HTTP Download.
apache has bandwidthlimiting too, but ppl usin downloadurl becuase the DONT
WANT bandwidth limiting. however, the best was is to user mod_rewrite and to
check condition if the remote http refferer is one of the allowed
gameservers. if not, well, one way would be to throw an error, another way
would be to direct them to ur website.
if the remote http refferer is correct (hl2://) u allow access with full
speed. well, if u still want bandwidth shaping use one of the bandwidth
shaping modules coming with apache1/2 :)
almost forgot: u can use mod_rewrite directives within ur .htaccess
container. ;)
regards
Simon
PS: and now please back to mailinglist topic... knowledge how to
configure/secure apache is an issue of another mailinglist. :D
Simon Lange //Director
www.polynaturedesign.com
+49[0]4131 220121 PHONE
+49[0]4131 224730 FAX
+49[0]1717793294 CELL
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bart King
Sent: Sunday, July 17, 2005 11:08 AM
To: hlds_linux@list.valvesoftware.com
Subject: RE: [hlds_linux] HTTP Download.
Hi all, to drop in my two pence on this:
On our 64 player server using sv_downloadurl, we have a different solution.
Instead of running Apache (which is a little bulky just for serving HTTP
requests from Half-Life 2 clients), we run thttpd, a much lighter web server
that also has the advantage of rate limiting. We then limit thttpd's total
outgoing traffic to around 250KB/s.
This never appears to be much of a problem, since when the map does change
to a custom map, typically, only 5-10% of clients end up downloading it -
either the rest of the 60+ clients have it already or disconnect because
it's not de_dust ("OMG WTF I PLEH DUST").
Although, if we're playing a new map that no-one will have, we sometimes
drop the rate limit so our regulars can fetch without waiting too long.
It's all a question of balance - I would find restricting the requests to
HL2 only a little constrained.
Of course, you can always tell people to download maps off the web prior...
> [ ToldYa.GIF of type image/gif deleted ]
*grin*
--
Bart King -- http://www.bart666.com
+44 781 219 5654 -- PGP: 0xC9C3EB8B
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
RE: [hlds_linux] HTTP Download.
Hi all, to drop in my two pence on this:
On our 64 player server using sv_downloadurl, we have a different solution.
Instead of running Apache (which is a little bulky just for serving HTTP
requests from Half-Life 2 clients), we run thttpd, a much lighter web server
that also has the advantage of rate limiting. We then limit thttpd's total
outgoing traffic to around 250KB/s.
This never appears to be much of a problem, since when the map does change
to a custom map, typically, only 5-10% of clients end up downloading it -
either the rest of the 60+ clients have it already or disconnect because
it's not de_dust ("OMG WTF I PLEH DUST").
Although, if we're playing a new map that no-one will have, we sometimes
drop the rate limit so our regulars can fetch without waiting too long.
It's all a question of balance - I would find restricting the requests to
HL2 only a little constrained.
Of course, you can always tell people to download maps off the web prior...
> [ ToldYa.GIF of type image/gif deleted ]
*grin*
--
Bart King -- http://www.bart666.com
+44 781 219 5654 -- PGP: 0xC9C3EB8B
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
