[Opensim-dev] RFC: Proposed Image Request flow/chart

[Teravus Ovares]

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 <jjustincc at googlemail.com> 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
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>