It would be very nice if there were a way to see what's in a client's cache. (MD5 hash reading would be incredibly useful too)
The reason for this is that in SS13, most (I can only think of 1 UI that doesn't use some for of HTML) UIs use HTML windows, most of the modern ones use a variety of stylesheets, javascript files, images, and others.
Now, that's fine and dandy, but we're hitting the point where we have so much of these that sending them to the client when they join is sort of impractical since it disables the usage of browse()/browse_rsc(), for very long amounts of time.
A solution to this is to send the files when they are first needed BY the client, however, it is impossible to be sure a file arrived before actually opening the UI (non issue through browse()/browse_rsc(), however it is an issue when making UIs through winset() or output()).
So after said wall of text I simply request a way to see the contents (possibly MD5 hashing) of a client's cache.
ID:1925978
 Aug 27 2015, 5:56 pm
|
|||||||
| |||||||
Basically, there is is a decent size time frame (up to a few minutes depending on ping) when a client connects, that sending them these resources causes the client to ignore any winset/winshow call, including that use winset/winshow, like browse(). This includes if they already have these resources.
So basically, for the first 30 seconds to 3 minutes of a connection, the client doesn't get any of the browse() windows. There was a bug report on this some time back, by pomf. | |
As MrStonedOne stated, browse_rsc() sends it no matter what.
| |
If this file is sent no matter what, that's definitely not intended behavior. I'll look into this some more as I get into 509 to see if there's a way to shore this up.
| |
I think it's worth bringing up for you to look at while you are digging in that code, that the overhead is massive.
I'm talking about 30 second lag for all of our interface windows on LOCALHOST on connection to send browse resources in the lower double digits. | |
Yeah, that seems way out of proportion.
| |
I can confirm that browse_rsc() is either sending the file on every request, or taking just as long to check that it still exists. In my preloader experiments, I looped through roughly 170 files to send to the client and it took -forever- on live servers (we're talking minutes often).
| |
I've added this issue to my list of priorities for 509.
| |
I checked on this, and tried sending a file via browse_rsc() that's already in the client's cache. As expected, the client does in fact determine that the file has already been received, and sends back a response that says the file was completed. The browse_rsc() call is not blocking, so other files can be queued up, and any other files already queued up will be sent in turn immediately without waiting for a tick interval.
Suffice it to say I haven't been able to reproduce the long delay issue yet. If anyone can produce a demo that shows the problem in action I'll be happy to look into it further. [edit] I did find one thing I think is suspect: the file transfer code does not take message queuing into account. I added flush instructions to the two routines in file sending/receiving that write messages. | |
Download & compile this revision of /vg/station code, that's the last commit in which 800+ files were sent to the client on login.
You don't even need to be an admin to see that it's bad, connect, and you'll see that the new player options menu is 100% unresponsive for multiple minutes. I know 800+ is a LOT, but we fixed it by sending the client the files when they first NEEDED the file, this did cause other issues which is why I made this feature request. | |
on /tg/station is more closer to 200, and its still bad.
Its the query -> wait -> response process. I'll say it again, pipeline pipeline pipeline =P How ever, the fact its soo bad on even local host is odd as hell. | |
I can't help but think that maybe the queuing thing I found is an issue, then.
Though I also think the way the files are chained is probably not ideal. The problem is that's a huge can of worms to open. | |
It's an easy fix too, the massive majority of our browse_rsc() uses compiled strings (single quote), so you could make those skip the queue and get grouped up if preload_rsc is enabled. Because At that point it's safe to say the client has them, they just need to be put in the cache folder for use in browse windows.
quickedit: Ideally thou, adding more pipelining to the process (almost) never hurts. | |
I think I get what you mean here, though. output() isn't capable of doing the same "wait for files" behavior that browse() does because it's control-agnostic; it doesn't care that you're sending to a browser control or another kind.