[ut2004] 64 bit client problems with downloads

[Tom Emerson]

On Saturday 20 November 2004 10:17 pm, Ryan C. Gordon wrote:
> > BACK-SEAT CODERMAN! Debugging your programs from afar... FOR GREAT
> > JUSTICE!
>
> Alright, let's not get snippy (snippier?) now.

hmmm... now that I've been "tagged", I might as well share the following 
"debugging-from-afar" tidbits I've collected tonight ;)

When I hit a NEW RECORD HIGH of a download that reached 1000.2% [you read that 
right -- over one THOUSAND percent downloaded] I finally decided to run 
ethereal and "reverse engineer" the connection (since I *obviously* don't 
know what is "going on" with this whole process, what better way to learn 
than to actually look, eh?)  Here is what I saw:

following TCP stream:

     GET /ONS-D%24K-Gunshop.ut2.uz2 HTTP/1.1 
     Host: 67.19.33.20 
     User-Agent: Unreal 
     Connection: close 
 
     HTTP/1.1 200 OK 
     Date: Sun, 21 Nov 2004 08:31:29 GMT 
     Server: Apache/2.0.50 (Win32) 
     Last-Modified: Thu, 21 Oct 2004 19:54:30 GMT 
     ETag: "11d2b-7b4cbd-7ea2e023" 
     Accept-Ranges: bytes 
     Content-Length: 8080573 
     Connection: close 
     Content-Type: text/plain; charset=ISO-8859-1 

followed by "binary data" for the next 8 million or so bytes.  A little more 
poking around and I see in the .UT2004 directory a file called 
"Cache001F.tmp", which is growing [but is actually the "second" attempt at 
downloading the file] and timing an "ls -l" command to as near as "100%" as I 
can, I see this:

drwx------   6 tom users     176 2004-11-21 00:50 ./
drwxr-xr-x  61 tom users    4648 2004-11-20 22:47 ../
drwx------   2 tom users    2544 2004-11-21 00:24 Cache/
-rw-r--r--   1 tom users 8073216 2004-11-21 00:58 Cache001F.tmp
drwx------   2 tom users      80 2004-11-13 00:29 Saves/
drwx------   2 tom users     336 2004-11-20 21:12 System/
drwx------   2 tom users      96 2004-10-28 02:06 UserLogs/
tom at BeastBoy:~/.ut2004> l
total 7967
drwx------   6 tom users     176 2004-11-21 00:50 ./
drwxr-xr-x  61 tom users    4648 2004-11-20 22:47 ../
drwx------   2 tom users    2544 2004-11-21 00:24 Cache/
-rw-r--r--   1 tom users 8097792 2004-11-21 00:58 Cache001F.tmp
drwx------   2 tom users      80 2004-11-13 00:29 Saves/
drwx------   2 tom users     336 2004-11-20 21:12 System/
drwx------   2 tom users      96 2004-10-28 02:06 UserLogs/

OK, caught it just before & after "100%", and sure enough 8097792 is indeed 
greater than 8080573, so at least I "know" that the program is indeed 
receiving (far) more bytes than expected.  I suppose this discredits any idea 
of "bad data due to screwy things like 32 vs. 64 bit pointers", but before I 
reach for that crow-flavored slice of pie, I still have to ask, "why does 
this problem exist?"  What size should the file ONS-D%24K-Gunshop.ut2.uz2 
REALLY be? Roughly 8 meg as reported by the web server, or up to 10 times 
that amount?  I really don't know in this particular case because whomever 
was actually "in" the game managed to finish it before the download 
completed, so the download attempt got knocked out.

Now, I did happen to notice that while the initial download was via HTTP over 
TCP, the second attempt was pure UDP, and I'll grant you that UDP can be a 
bit harder to grok.

I'm thinking the next thing to check would be a comparison of the actual files 
received via each method, but this is next to impossible for a couple of 
reasons:  the ".tmp" cache file is cleaned up immediately after the download 
completes [hey, that IS a good coding practice most days of the week :) ] and 
secondly, we already KNOW the file sizes differ, so it is pretty much 
guaranteed not to match.