On Sat, Apr 07, 2007 at 04:56:53PM -0700, Ken Taylor wrote:
> So my voyages through the VOS codebase have brought me to the misc:search
> metaobject. It's a pretty nifty metaobject, really... but i have some
> questions/comments:
>
> - It looks like when you "acquire" an object, some times it will also
> acquire all that object's children. I'm specifically looking at the
> CatchUpdatesFilter::savechildren value. But I don't quite understand in what
> cases this gets set and what the rationale is for getting the children. All
> the message filtering stuff makes the code a bit hard to understand, because
> the filters happen "in the background" and change the normal behavior of the
> VOS system... the fact that you guys seem to be allergic to comments doesn't
> help either ;) (i jest! i jest ... sorta)
The basic theory behind the search metaobject is that it has a
pattern-matching state machine that walks the vobject tree, synthesizes
queries to each vobject, and catches the responses (hence the filter).
The responses are the packed into a COD, gzipped, and that is
transmitted to the client which does the process in reverse. This is
what allows VOS to have a fine-grained representation of the world yet
still download it relatively quickly and efficiently.
That said, I haven't decided whether to keep it for s5 or do something
else that might be simpler. It's arguably overkill, and the complexity
means it may be hard to optimize. Also it needs to accomodate some
design for caching, where the client might send a set of hash codes
describing its cached data, and the search object has to be smart enough
to only send the parts that have changed.
> (man, i'm just a complainer, aren't i?)
Reed is right, I don't comment my code enough. I'll try to be better
about it in the future, especially since I know more people are looking
over my shoulder now.
Also: you should be REALLY thankful you didn't see the first version of
the search metaobject :-)
> - Could it be possible for there to be a malicious or just buggy
> infinite-loop query that messes up the server (since incoming update
> messages are being deferred during a query), or is it guaranteed to
> terminate?
As each vobject is visted, a temporary flag is set to prevent it from
being processed a second time, so it won't get stuck on cyclical links.
> - Should there be some sort of access control ability on the search node,
> limiting who is able to initiate a search?
>
> - Could the search node be used to "get around" property "deny all" access
> control in some cases, and return the forbidden data anyway?
The search is done with the identity of the requester, so while it may
be possible that someone could attempt a denial of service attack by
issuing multiple searches, it should not enable them to access data they
wouldn't be able to access otherwise.
--
[ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
