At 06:25 AM 7/15/2005 -0700, Vapor opined:
>Forcing an automatic system based on rates I just can't see being effective.
>What we are realistically saying here is take thousands of connection types,
>speeds and latencies and have the server automatically control their update
>rates. All that will be achieved would be no connection being tweakable and no
>advantage seen on faster connections, all sounds nice yes, but...
But that is the key to the solution, though I admit some
hubris in that since I don't have to actually spend any time or effort
making it work I've not seen the problems associated with it.
Think of me as a member of manglement with pointy hair as you read this.
Source is a hub-and-spoke network topology. The center hub
is the server. Thus the server has the knowledge of rates being
asked for by all clients, the latency each of them have, the
jitter (difference between max and min ping time over the course of
some minor time-frame), and its own load.
Would it not make sense, then, (if CPU cycles were infinite and
bus speed instant and memory a penny for a terabyte - yes, I know
there are constraints) for the server to be able to over-ride
client rate settings on a case-by-case basis by issuing new rates,
starting from a baseline of your overall data rate?
Let's say you've a CS server on a single T1. That's 64Kbps
times 24 channels. Let's say you did 24 players. Fine, we've 64K
to work with for each client. What I'm saying is that rather than
have client A demand rates that would eat up 128K and client B on
two tin cans and a wet string demand 2.4K, we let the server
dynamically tell A "you're good, keep on, here's a little more data
since you've the speed for it and I'm not missing any updates" while
it tells client B (who, being an idiot because we are all plagued by
idiots at some point and I need one in this scenario) set his client
at T1 speeds while drooling on the string to "drop back a bit, you're
missing updates."
Likewise, we're all aware of ping spikes. You're running at
a steady 50ms and then your wife decides to download that latest
Crazy Frog video, or the Nachi worm made it onto some pointy-haired
marketing-type's laptop with a gigabit ethernet connection to your
switch and decides to port-scan all of New Zealand, or you've a
cablemodem and the kid next door starts downloading all the pr0n
in Holland. If the server could dynamically adjust rates for the
clients, as the client connection changes the server would notice
and could quickly adapt.
>You will have millions of players blaming Valve for enforcing "their" rates,
>everything from bad reg to lag will be blamed on this and uproar would
>definately occur.
Agreed, but do you think they'd notice if suddenly they
didn't get ping spikes, and consistently had a smooth game no matter
if there were 12 people or 48 people on the server? Generally the
server has the bandwidth to handle 48 dsl players, but occassionally
people put these things on their office T1 and start it up at night,
or try to run them over 1.5M/512K DSL connections to host a few
friends. Making the engine optimize the clients for the current load
with some overall boundaries would satisfy a large segment of the
server ops and players who don't rent servers and bandwidth from
hosting firms. Only Valve would know that market share.
>I pay a lot of money for my fast internet connections,
I'm sure you do. Let's compare your (unknown) setup to
mine. I've an OC-48 and an OC-192 into my office. My backbone
routers spec out at 460Gbps until I start throwing in policy-based
routing, ACL's, and the like, and they weren't exactly cheap either.
I know whereof you speak, but I'm assuming that 90% of the servers
out there aren't hosted at places like mine but in homes and small
businesses with less spendy methods of getting bandwidth.
The question to be asked here is should I be unstoppable if I
take my game rig to work vs standing still if I play from home, or
should we make an attempt to let the server self-adjust for its needs
and force that on the clients attached? Yes, I'd be less dominant
on the good connection, but less handicapped on the poorer connection.
If the customer, our players, value an even playing field over that
20ms unstoppable ping to their closest server then my idea has merit.
I'm not saying it's do-able, just that is has merit and should
therefore be debated.
>Control of client side rates must be maintained by the client, no other way
>would be widely accepted by the community.
And yet here's an admin asking Valve to change that because
of possible abuse, which is how this thread started.
>The truth of it is although we want to level the playing field and provide
>fairness between all connection speeds, doing so would annoy the masses, who
>are on broadband connections. You only have to look at how many ping
>restricted servers are around to see this.
Ping doesn't equal bandwidth, and I'd posit the idea that
a good game against opponents on an equal playing field would make
a server more enjoyable than a 20ms ping against the 500ms of a
player in New Zealand which just annoys both players. Unless we
charge for the right to connect, we're doing this from our own
largess, so why hold Pinger 20 up as an example compared to
pinger 250? I've yet to pay to play on a server, Valve gives the
server away freely, so it seems to me that our intent is to provide
a free service that others can enjoy. Maximizing that enjoyment is
thus our mission, so whatever helps the varied clients is of import.
If this helps the varied clients, then as above I maintain it has
merit for consideration. If it doesn't, then in the immortal words
of lady from Saturday Night Live, "Never mind."
- Dan
* Dan Sorenson DoD #1066 A.H.M.C. #35 [EMAIL PROTECTED] *
* Vikings? There ain't no vikings here. Just us honest farmers. *
* The town was burning, the villagers were dead. They didn't need *
* those sheep anyway. That's our story and we're sticking to it. *
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
