183 lines
5.8 KiB
Plaintext
183 lines
5.8 KiB
Plaintext
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 ?? |