Do I have to validate the state of dest in RtmGetOpaquePtr ?? 5) Give opaque ptr instead of handle to the entity method. 7) In RtmAddNextHop, do u need to do the NextHopHandle validation after taking the Entity's Next Hop Lock ? Otherwise we might potentially update a next-hop that has been deleted (which might be OK as you are not updating the state , and you have a ref count on the nexthop) 8) To work on a next hop directly, the next hop owner can keep a pointer, but he still needs to keep a handle around to be able to delete it ??? 9) What about delete all next-hops in one stroke if nexthophandle == null in RtmDelNextHop ? Just keep direct RTM_NEXTHOP_INFO * in the next hop list, but give out handles What if a call has handles from two diff address families/instances ... ? Holddown protocol ? Do I keep track of it the registration ? - Affects GetDestInfo - do u give holddown route Affects GetEnumDests, GetEnumRoutes - do u give helddown routes ..? Do we need a state in the next-hop (that we understand) ? If u expose RtmLockNextHop and RtmLockRoute, the caller has to be aware of the locking mechanism ? Like the granularity of locking etc. ? Improve EnumOverTable to take into account StopContext ?? and Have macros to initialize the space for EnumContext. and Improve AdjustPrefixes to intelligently use StopContext instead of getting everything and doung a PartialMatch.... Implement MAKE_DEST_INFO_FROM_DEST and also make GetDestInfo go through that. Incorporate dave's preference comparision (BGP multi-byte preference) How does this affect matching a specific pref ? When u delete a dest from the tree , make sure that u are not in a state when ref on dest has gone to zero and it is still in the tree. Does not work well with RtmGetExactMatchRoute as u potentially might be trying to ref dest with a ref count of zero. PS each held-down route also contribs to ref count here. How come DEST does have a state and we do check for deleted .... in VALIDATE_DEST_HANDLE //// **** Shift all error processing related to rtm route info from RtmNewRoute to CreateRoute like views parameter checking etc. Have a function to Get all routes that match a certain criteria ? For example, RIP want to query all its routes for the route handle to pass in update (it wants to get a route learnt from a certain neighbour which is part of the opaque info block). How do u know whether update route has been called after lockroute or not ? See if can optimize NewRoute and NewNextHop to use CopyMemory instead of copying field by field ? Use a dynamic lock in dest instead of allocating a new lock ??? Do I need to ref a entity when a route is added (or) can I manage it by keeping refs on the next hop (indirect reln) - Answer is a route guaranteed to have atleast one nexthop at all times ???? UPDATE BelongsToViews in RtmDelRoute Make sure you have a model from updating routes (and nexthops) in place without having to copy stuff out. Do we update the holddown route only for the last route deletion ? Or for every best route change ? If u already have a holddown route (do u change the holddown period for the old route), or do u update the holddown ? The later defeats the purpose of holddown anyway. Semantics of Ignore dests ? Do u ignore even if we have no changes at ignore time ? See if u are reinitializing after allocating and zerong block ? We are processing the change list with a lock preventing all others from adding to the list ? Does putting in the entity list lead to having a ref count ? Serializing the operations on entity lists by keeping lock on entity ? Do we need a read/write lock on the addr family change notifications block ? Include TRACING statements in RTM >> Check status code of Rtl What will happen if we call ProcessChangedDestsList and kill timer from outisde a timer func ? Decide on whether u want to have a Interlocked op to make sure that only one ProcessChangedDests happens at a time ?? Make sure that the caller entity does not de-register while you give callbacks to him (route aged out callbacks etc). ???? Do u validate an entity handle to see if the de-registration has not come up or not ? GetInstanceInfo and GetInstances should return supported address families in an array ? Make sure u delete all routes in the RTMv1 wrapper de-registration GET UR ****ing DE-REGISTER STRATEGY RIGHT ? What happens if he deregisters twice ? What about sync between a non-deregister and a de-register ??? -----Wrappper ------------------------------------------------------------ Do we ignore the VALIDATE and ROUTE_CHANGE callbacks to router manager ? [ in RTMCreateRouteTable ] RTM_ROUTE_CHANGE_BEST will be true even if the best route remained the same but the best route's forwarding information changed ???? In the wrapper, what will happen if DeleteRouteTable happens before other RTM calls (or during) ? Similarly with Deregister etc. ------For Later ----------------------------------------------------------- ComparePref in NT-64 { if (*(ULONGLONG *)Pref1 > *(ULONGLONG *)Pref2) { return +1; } else if (*(ULONGLONG *)Pref1 < *(ULONGLONG *)Pref2) { return -1; } return 0; } --------------------------------------------------------------------------- Make sure you stop the timers (CN timer) on the address family before you DestroyAddressFamily (as they access AF locks...) Make the distinction between counted type (ULONG) and bit-type (DWORD) Do we put a route in hold if it is not the last route to the dest ???? Hold ref in each view .... (RIP and DVMRP putting same dest in holddown) What about DestFlags (do we need it per view - who sets it ...) --------------------------------------------------------------------------- Perf Improvements --------------------------------------------------------------------------- Lookaside lists for common allocations for better locality ??