[ut2004] Upload and Download speed adjustment

[Zachary Williams]

Downloads from the server will always go at client rate speeds.  This is to 
ensure the server is not impacted by the sending of these things to clients.

http://www.theadminpage.com/redirection.php

There's a good little bit of info for you.

Zach

----- Original Message ----- 
From: "Giuliano Chianelli" <giuliano at rogers.com>
To: <ut2004 at icculus.org>
Sent: Sunday, November 21, 2004 6:28 AM
Subject: [ut2004] Upload and Download speed adjustment


> Running a ut2004 server on my linux box (pclinuxos kernel 2.4.22)
>
> does anyone know what to change to increase the upload/download speed for 
> maps and textures when clients log on? Im running a VCTF style server with 
> custom maps and velicles.
>
> Thanking in advance for all your help.
>
>
> ----- Original Message ----- 
> From: "Jeff Woods" <klaatu at fnordco.com>
> To: <ut2004 at icculus.org>
> Sent: Sunday, November 21, 2004 1:16 AM
> Subject: Re: [ut2004] 64 bit client problems with downloads
>
>
>> Look! Up in the sky!
>>
>> It's a struct! It's an array!
>>
>> It's BACK-SEAT CODERMAN!
>>
>> More powerful than an overloaded function! Faster than an improved bubble 
>> sort! Able to malloc tall heaps in a single bound!
>>
>> BACK-SEAT CODERMAN! Debugging your programs from afar... FOR GREAT 
>> JUSTICE!
>>
>>
>> On Sat, 20 Nov 2004 15:10:46 -0800
>> Tom Emerson <osnut at pacbell.net> wrote:
>>
>>> On Friday 19 November 2004 10:09 pm, Ryan C. Gordon wrote:
>>> > There's a lot more involved than just reading bytes from a socket 
>>> > [...]
>>>
>>> > [...] it's both inaccurate and impolite to show up and tell someone
>>> > that their bugs aren't "rocket science". [...]
>>>
>>> Well, it wasn't my intention to be rude, but from what you're saying it 
>>> sounds
>>> like it is a problem of perception -- namely, mine :)
>>>
>>> I perceive a "percentage complete" calculation to be relatively simple, 
>>> and
>>> that debugging it would take no more effort than to set a breakpoint on 
>>> the
>>> final result > 100.0 and "take a look" at the underlying variables at 
>>> that
>>> point, then backtrack to find out why they are incorrect.  Either the
>>> calculation is incorrect or the values passed to the routine are bogus. 
>>> I
>>> find it hard to imagine how the calculation would be "wrong", so that 
>>> leaves
>>> incorrect inputs [the "GIGO" principle]
>>>
>>> What I gather you're saying is that figuring out why the numbers passed 
>>> to the
>>> routine are "wrong" is a bit harder than merely inspecting memory --  
>>> this is
>>> just a guess, but perhaps you are passing a 32-bit pointer to a routine 
>>> that
>>> internally uses a 64-bit pointer and "whatever" resides in memory just 
>>> prior
>>> to the pointer doesn't cause the treated-as-64-bit pointer to point 
>>> outside
>>> of allocated memory.  [if it did, well, you'd have caught that a long 
>>> time
>>> ago I'd imagine ;) ]  Of course, the fact that the routine is using a 
>>> 64-bit
>>> pointer could be totally unexpected because when compiled for 32 bits, 
>>> it
>>> would be using a 32-bit pointer "as expected", and the program wouldn't
>>> exhibit the incorrect behavior.
>>>
>>> The other point to this thread is "why does this bug exist in the first
>>> place?"  An accountant once told me "if you're off by a penny, you might 
>>> as
>>> well be off by a million dollars" -- the fact that the program reaches 
>>> 100%
>>> AND THEN STARTS OVER should have been a "red flag" for the whole 
>>> download
>>> process -- something is causing the program to retry the download EVERY 
>>> TIME,
>>> and it may be as simple as forgetting to "close" the file initially
>>> downloaded, so it "never" validates properly from the redirected 
>>> host/server
>>> (yeah, I'm guessing again :) but so long as I'm guessing, if it is 
>>> indeed
>>> related to whether or not the file is "closed" properly, perhaps there 
>>> is a
>>> race condition where you [or the "virtual machine"] believe the file to 
>>> be
>>> closed, but the "real" machine hasn't done that yet...)
>>>
>
>