Outstanding:
------------
move scripts to merc/

fix quake

* 03/31/2005: Global and static objects -- work inside simulator somehow!

* 03/31/2005: Fix Timer class. The interface is broken.

* 03/31/2005: RealNet performance problems. Simple ping application
  benchmarking. Use libasync? in general, kernel asynchronous I/O stuff should
  be figured out.
  
* 03/30/2005: Profile the RTree package and find what's taking time. The
  library may be useful for making Mercury's matching more efficient. 
  It might be useful to make a nimble RTree package out of the bloated library
  as well.

* 03/20/2005: Interest::Overlaps () aint extensible the right way. Current
  design forces all constraints to have "value" type -- what we want is
  that only routable constraints should have that type.

* 03/19/2005: Join protocol may need re-working. When all nodes join 
  concurrently, all of them can end up hitting one guy! fixed this
  temporarily using a round-robin policy at bootstrap. Change this to 
  a normal DHT-like joining algorithm.

* 03/19/2005: RealNet scheduling - we need to make mercury more event
  driven as far as network processing is concerned. must make it sleep 
  more so larger number of instances can be run.
  
* 03/19/2005: TCP connects are blocking. Given that we are un-threaded,
  this is BAD! Must fix this some day afterwards. the app should get an
  indication of something happenning. 

* 03/19/2005: g_MercAttrRegistry is too fragile to be used in mercury/
  basically, bootstrap can also link with it without initializing it.
  just get rid of that global.
  
* 03/19/2005: Bootstrap's processing is linear when it processes a
  heartbeat. Fix that. 
  
* 03/11/2005: Two problems:
  - PubSubManager::DoWork::MatchLocal is too slow when there are too many
    local pubs/subs to match against (n^2). Solution: more efficient
    data structure to hold pubs/subs.
  - There are too many local stale pubs/subs. Solution: no idea.
* 02/28/2005: Valgrind
==2362== Use of uninitialised value of size 4
==2362==    at 0x1BA6793A: BBox::Contains(Vec3 const&) const (common.cpp:130)
==2362==    by 0x1BA8F9A6: SimplePlayer::IsInterested(Vec3 const&) (SimplePlayer.cpp:48)
==2362==    by 0x1BA75578: DynamicGameObject::InterestTime(OMEvent*,
std::map<GUID, OMInterest*, less_GUID, std::allocator<std::pair<GUID
const, OMInterest*> > >*) (GameObject.cpp:263)
==2362==    by 0x1BAA9573: Manager::HandlePub(OMEvent*, bool) (Manager.cpp:1441)
==2362==    by 0x1BAA8C2F: Manager::HandleEvent(OMEvent*, bool) (Manager.cpp:1290)

* 12/23/2004: Ashwin found that there are multiple send_reg/recv_reg/etc.
              per nonce. some duplication somewhere.
* 12/15/2004: What happens when fetch requests fail to ilicit responses?
              Objects could be stuck in the pending store forever...
* 12/15/2004: need an interface to remain interested in objects that are not
              in anyone's subscription but we want to keep anyway (e.g.,
              pointers).
* 08/27/2004: it looks like we are getting pubs for objects that have been
              deleted either long after they are deleted or we forgot to
              record a deletion record for the guid. the symtoms are that we
              are getting regs for prims that we don't have and we get pubs
              from ourselves for objects that we don't have object info for.
              Some of these are OK -- we sometimes get regs for items that
              no longer exist because they were temporary (drops) and the pubs
              have a lifetime of 30sec.
              -- does this still occur?
* 07/02/2004: Figure out how come even after we get a proper deletion for an
              object, we sometimes get more deletions in later updates. This
              appears to he happening even if no messages are dropped.
              Doesn't impact correctness, but this is not efficient.
              -- does this still occur?

Semi-Resolved:
--------------

Resolved:
---------

* 07/22/2004: Get rid of this lazyblob business. It barely saves us
              any time and isn't used anymore anyway. Also, forget about
	      "GConnection" and just pass in a Packet to fill since I
              doubt we're ever going to revamp this thing enough to pass a
              connection oriented interface all the way up.
              --- There is a LazyBlob memory leak! (not anymore?)
              --- uses Packet now
* 12/15/2004: GObjectRefMap should be a list not a map, since there can be
              multiple pointers to the same guid.
* 07/21/2004: Sometimes (in quake) we get registrations for objects that don't
              exist any longer and aren't in deleted guids? This => a replica
              connection assertion failure about the guid not being in the
              deleted guids eventually...
* 08/23/2004: Need to insert some Thread::Yield()s into the main quake loop.
              Ideally, we also want to place the majority of the Recv()
              processing in a separate thread because now it is blocked
              behind Send() -- This "recv" thread could just use the last
              snapshot of the object store to avoid having to lock it
              constantly.
* 08/27/2004: on emulab, it appears we are dropping lots of packets (out >> in)
              this -> lots of warnings in replica connection about conns
              getting reset and stuff like that...
              It appears we are seeing cross traffic from other experiments?
              Packet size doesn't seem to affect this, but packet rates >
              200pps per node seem to -> huge chunks of packet losses...
* 07/17/2004: MERCURY: Merc sometimes drops events (or they just seem to
              "disappear" and not get received) sometimes when the pub
              send rate is very high? i.e., quake send rates.
              Symptom: run quake, stand in front of a couple replica items.
	      Don't move. During some frame periods (some times up to a few 
              seconds), we only get the pubs for some of the items, but not
              the others. This is definitely a Merc or OM bug...
* 08/29/2004: there was a realnet thread blocking bug which caused it to
              block on select even if there were new sockets to read from
              (because those sockets were added in another thread). Fixed.
* 08/29/2004: there was a bug in RealNet which caused checking whether
              a socket had data on it to take 10ms (it used a select). Fixed.
* 08/24/2004: Figure out why MercuryRouter::DoWork() is taking so long...
              combo of pub-out-of-range -> looping around the merc ring
              forever and infinite message queues.
* 08/19/2004: Migration sometimes causes a race condition that makes the SID !=
              LocalSID. This causes the assertion in ReplicaConnection.cpp:
              ASSERT(obj->GetSID() == m_Manager->GetSID());
              to fail. -- was because of stale pubs from the previous node -> SetSID
* 08/19/2004: The times recorded for DiscoveryLatLog for message reception are
              incorrect "on the wire" times because we don't record the time 
              until RealNet processes the message, which may be a long time 
	      after the kernel receives it. In general, the high CPU cost of 
              Send() and quake application processing appears to be severely 
              inflating our latencies.
	      -- fixed this by putting recv processing in another thread.
* 08/22/2004: Ugh... it looks like emulab's clocks aren't synchronized even
              though their webpage says 1ms synchonization. :P
	      Apparently they are synchronized and we just have thread time-slice
              issues...
* 07/24/2004: When we get a registration for a new object, we should send
              an update immediately and not wait for the next Send(),
              otherwise the framerate becomes a factor in the object
              discovery latency.
