Thanks for the comments 1. The stuff in the LLClient section would be mostly within the one client thread. The async callback in GetAsset will follow the flow chart after AssetLayers Decoded through one iteration. That's the only place in the llClient section where the thread context is nebulous. The client thread could be pumped by receiving UDP packets. We receive at least 1 packet a second in purely agent updates
2. Potentially yes. We may need a server side priority reordering for things that are taking a long time within the priority queue. 3. At least to me the 'too many requests per client' check will be different per client and therefore, in my mind, it should be within the LLClient thread. Currently, it's hard coded at 10 requests per image per client. Maybe we need another 'global' image/asset limitor in GetAsset? 4. No. Not looking to change that Best Regards Teravus On 1/15/09, Justin Clark-Casey <[email protected]> wrote: > Teravus Ovares wrote: > > Greetings all those interested in OpenSimulator development, > > > > I have compiled the following flow chart as a proposal for the > > process, the system separation, and the thread contexts of image > > requesting and would request the community's comments on it. > > > > You can find the flow chart here: > > http://opensimulator.org/images/2/2e/Image_req_process_flow_char.jpg > > > > > > I'm looking forward to some great responses. > > A few comments > > 1) I find the Client Thread label in the top right a bit confusing, since I > presume there are multiple threads involved > in that top half. Is is that the main packet processing thread (from > LLClientView) would be responsible for the initial > addto/reorder on the priority queue? Might this possibly extend up to the > point where the async asset request is made? > And then is the thread coming from the async completion handling the rest of > the process? (right up until "pop item > off priority queue"). > > Hmm, actually, that probably wouldn't work since it would tie up the single > AssetCacheThread processing async asset > requests. As you can see I'm confused, so clarification as to how threading > would work here would be appreciated :) > > 2) Relating to the above, is there any potential for delay if the asset > server is responding unevenly? If this is a > big delay in a single asset request does this hold up the process of sending > out textures? > > 3) Could the 'requests too high' handling part in the LLClient section be in > the Core? This strikes me as something > that could be quite generic > > 4) I think that at the moment, a single failure to look up an asset from the > asset cache marks it as permanently not > found. I think this marking only occurs if we successfully received a 'not > found' reply from the Asset service. This > strikes me as reasonable since we really don't expect asset UUIDs to suddenly > become valid. Are you proposing that we > change this? > > Thanks! > > -- > justincc > Justin Clark-Casey > http://justincc.wordpress.com > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
