koobas.hobune.stream
limit to request size via webplayer
background: I understand that there is a direct limit to the size of packet that Unity Standalone can receive from a website through a yeild WWW call (I think 100K?)
Question: but is there such a limit when communicating with the website hosting the plug-in in terms of request size? what is this limit if it exists?
Explanation: one of the requirements for my web-player game is persistent/consistent contact with the host website for the purpose of save-states, and processing (think buffered requests), and potentially very large host held save files. we have considered breaking the information for the save files into specific requests (only grabbing what is needed per request), or determining how to break up the data to stay under capacities. one of the requirement we were kicking around was having the user be able to upload images to the host website, and then have Unity pull it in, and display them, but if there is a limit to the amount of data that can be given, or a finite limit to the amount of damage per image then we need to figure out whether to nix this feature, or limit the imported file size.
Where is your reference for your background statement? It's not something I recognise. The webplayer uses the browser to fetch files, and I don't think any browser has a limit to the size of the data it can fetch,
this number was found empirically when I was doing work doing GET requests on a RESTful server whom had thousands of entries (mostly full raw android sensor data running about 3 apps for test values).
when I would attempt to pull the full server it would only return 20 -> 25 records. I know that it could return more because when I gave the server the same GET request through browser it returned all 10,000+ the entries.
I'm not sure that you can draw such a broad conclusion from your test, since any number of things could have been happening. For instance, Unity could have been passing different headers with the request that were causing a different response.
Our program regularly makes requests for imagery, JSON, $$anonymous$$$$anonymous$$Z, etc. in the 10s of megabytes without issues.
