Currently, browse_rsc only allows sending one file at a time. While it's smart enough to not re-send a file that already exists, the one-file-at-a-time system means that to send multiple files, it must be called multiple times, with each call requiring a round-trip to the client.
As browse_rsc prevents browse() calls from happening until all of its queued operations finish, this means that transferring more than a very small number of files can end up delaying browse() by a long time, even if the client already has all of the files that are being sent.
Suggested feature: allow using browse_rsc() with an associative list of filenames and files, which will check multiple files at once and send any that are missing. While the initial preloading may still take a while, reducing the round-trip count will help clients that suffer from high latency.
ID:2609579
 Aug 31 2020, 2:07 pm
|
|||||||
Resolved
| |||||||
|
Aug 31 2020, 3:29 pm
|
|
Zewaka
 |
This would be great for SS13 servers that send a bunch of assets to the user at the beginning of the game.
|
hell yeah, i support this
| |
the way the underlying queue works, supporting lists wouldn't help.
the real issue is with how the underlying queue works. | |
The "making the queue better" part was implied.
| |
but you don't need list support to make the queue better!
lummox can already have it batch up sends without having to make browse_rsc take lists because the two concepts are not intertwined! Next time make the feature request you actually want, you don't want browse_rsc to take lists, you want the browse queue to batch and pipeline sends. | |
I'm not sure why you're arguing with me when I clearly said:
the one-file-at-a-time system means that to send multiple files, it must be called multiple times, with each call requiring a round-trip to the client And what the hell is with "you don't want browse_rsc to take lists"? That's explicitly the feature I'm talking about, because the situation that prompted this is I have multiple filenames and files in a list, and I have to loop through the list to send each one, and each one causes another full round-trip request that delays later ones. (E: And also that multiple calls create a long queue of round trips, which part of this feature is suggesting squashing into just one. Logic to combine multiple disparate browse_rsc calls isn't part of this request; it's making a mechanism to handle batching all at once.) | |
Already been suggested.
| |
I appreciate the reminder for this. I've popped it onto my list of things to look at for 514 and I'm gonna bump it up the priority list.
| |
And what the hell is with "you don't want browse_rsc to take lists"? That's explicitly the feature I'm talking about, because the situation that prompted this is I have multiple filenames and files in a list, and I have to loop through the list to send each one, and each one causes another full round-trip request that delays later ones. What I keep trying to explain to you, is the two concepts are entirely divorced. This system will still queue them up one at a time on the back end:
browse_rsc(list(blah = 'blah', ...)))
Like, if lummox goes, and just implements browse_rsc accepting lists, and nothing else, it will still queue them up one at a time. This system can still support batching sends up: for (var/assetfilename in asset_list) You have two goals: 1> You want large groups of files to not take so long to reach the client (primary) 2> You want browse_rsc to be able to accept lists so you don't have to do the loop in slower game code. (secondary) These goals are entirely seperate, each goal can be achieved without achieving the other goal, in fact, the easiest way to achieve each goal does not achieve the other one. Because browse_rsc already uses an out of band queue, the easiest way to make it pipeline multiple requests is to handle that at the queue's code, and because browse_rsc already uses an out of band queue, making browse_rsc take lists wont magically fix the the out of band queue only sending them one at a time. | |
old posts that are related:
http://www.byond.com/forum/post/2264075 http://www.byond.com/forum/post/2528707 | |
Just as an update on this, while browse_rsc() has not been updated to allow a list format, the behavior of browse_rsc() has been significantly improved in BYOND 514 to avoid the normal delays involved when those files have already been downloaded.
| |
I've recently done some work that heavily uses JavaScript aswell as browse_rsc(), looking forward to these changes.
| |
Lummox JR resolved issue with message:
browse_rsc() behavior has been improved so that files can be sent through the regular resource download system, which can 1) check for whether the client already has a file, and 2) batch-send any needed files. The old approach was not scalable and resulted in delays in some games. | |
I realize the resolution of this feature does not actually add a list format as requested, but I think the change fits the spirit of the request.
| |