Hi,
Just wondering if anybody have any experience with using multiple www requests simultaneously? We are having some problems with requests failing randomly and I think it might have to do with the fact that we sometimes uses quite some www requests. Should we at application level queue our www requests? It mostly happens when we requests textures. We get those nasty 8x8 question marks textures.
Thanks,
Ohm
I have used multiple WWW calls before without issue. It really depends on the server your scripts are located / or html or whatever you are loading. If you do not own your server you should call and ask what are the limits. Are you having issues with code? Post it I will see If i can help out.
Please also be aware that in the web player we rely on the browser for network operations and IIRC, many browsers limit the number of simultaneous requests that can be active at one time. You should be able to issue any number, they might get queued up a bit and the behavior there may vary from browser to browser. While a bit heavy handed but good for testing would behandling a request queue yourself and incrementing the max number of WWW operations until you hit that breaking point (of course testing in all browsers).
Thanks for the replies.
I’m using the standalone windows version. I’ll try queue the requests myself and see if that works. The number of concurrent requests can sometimes be about 40-50. The web server that I’m using for the data are also rather low tech. I personally very seldom get the problems but other members of my team get the problems. I’m working from the same LAN as the web server and they don’t.
Cheers,
//Ohm
I am curious just for information sake, why are you in need of so many calls simultaneously?
We are currently streaming all data used in our application. So we have lots of small icon textures and meshes and textures used for character clothing and level props. We will later pack multiple files into one unity package. The main idea is to stream all content to minimize the entry level for the user. We also want some (most) of our applications to start with replacement props and then on the fly update the props when data has been streamed.
//ohm