ID:2674041
 
Not a bug
BYOND Version:513
Operating System:Windows 10 Home 64-bit
Web Browser:Chrome 89.0.4389.114
Applies to:Dream Daemon
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Tested on a few different versions, in both 513 and 514. Yes, it is still present after 514's changes to browse_rsc().

Descriptive Problem Summary:
The Ref states that browse_rsc() does not send files that are already present in the target's cache. This does not appear to be the case. The files are modified every time browse_rsc() is called and the network usage appears to be the same whether the files are in the cache or not.

Numbered Steps to Reproduce Problem:
1. Send a player an asset with browse_rsc().
2. Send them the same asset with browse_rsc().
3. Look at the network usage during each of those calls and see it's the same.
4. Alternatively, look at the timestamp on the files in their cache.

Code Snippet (if applicable) to Reproduce Problem:
/client/New()
while(1)
src << browse_rsc('big noise.png')
sleep(50)

It's not especially important what the file is, but in this case 'big noise.png' is a 16000*16000 image of... I think it's Gaussian noise but it's just the biggest image I had sitting around

Expected Results:
File would be downloaded once and minimal network communication would occur afterward to see if the client already had the file

Actual Results:
File is resent every time

Does the problem occur:
Every time? Or how often?
Every time, as far as I can tell.
In other games?
Happens in a game and in a test project, so yes.
In other user accounts?
Yes.
On other computers?
Yes.

When does the problem NOT occur?
As far as I can tell it always occurs.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
No idea.

Workarounds:
Manually implement a cache in softcode I guess.
Can you build a test project that shows this in action? I've looked at all this code extensively in the past and I can definitely assure you files are cached on the client end.

However the client-side cache does tend to limit its size and will start to purge older files when it gets beyond a certain point. Maybe that's what you're seeing? How are you confirming that the file is re-sent?
The title isn't great. I would have changed it, but I can't/can't figure out how. The files are cached, but browse_rsc() doesn't detect this and resends them anyway.
As I said in the post, I'm looking at both the file in the cache and the network usage. The network usage is the same whether the file is already in the cache or not, and the file's last modified timestamp changes every time browse_rsc() is called.
Here's the simple test project I used, though the network part I tested with SS13: https://gofile.io/d/GDk5Rw
The last-modified timestamp can change for a lot of reasons so I don't think you can rely on that at all.

I'll take a look at the test project to see if anything pops out.
Lummox JR resolved issue (Not a bug)
Good gads, that noise file is 140 MB. That's absolutely going to trigger cache erasure limits. I don't even see how the browser could display that reliably at 16K by 16K in size. Yikes.
OK, then use a smaller image. It still happens with any file I can find. We first noticed it with a js file and then later realized it was happening with literally every file we ever browse_rsc()ed.

EDIT: I just got the same result replacing big noise.png with a 2*3 pixel image. It's 137 bytes.
I'll try it with a simpler file then and see if I can replicate any results, but I really doubt it. browse_rsc() has always queried the client for permission to send a file before actually sending it. It operates differently now in 514, but there's still a query process involved.

I honestly think that with the ginormous file out of the picture, you're just reading the data wrong. There's always going to be network usage when asking the client if it needs the file, but it's a very small amount of data. There's also going to be timestamp changes to the files involved, and that's 100% normal. Nevertheless I'll run a file through browse_rsc() a couple of times and see what happens in the debugger.
What I'm seeing is the same amount of communication whether the file is already in the cache or not. I can delete the file from the cache and call browse_rsc() again and see a spike of the same size. This [i]could[/i] be the communication to determine if the client already has the file, but if so it's quite a lot of data for that.
By the way, when it checks if the client already has a file, is this just based on the filename or is it a checksum or something?
It's checking a checksum. That should already be known on both ends so it's pretty fast and not a lot of data is being sent.

Probably the only way to test this accurately without a debugger (I have not done so yet) would be to use a file around 1 MB or so and look at the results with that. A 1 MB file should stick around in the local cache just fine, but you'll be able to tell very easily whether 1 MB of data is sent on subsequent browse_rsc() calls.

If you're looking at byes sent/received, it's not going to differ too much with a small file involved. With the mondo ginormous file you had before, its time in the cache was numbered.