Main Page | Modules | Class Hierarchy | Class List | Directories | Class Members | Related Pages | Examples

Todo List

page ANTARES API documentation
Figure out when to properly return by copy, reference, or pointer and refactor the code appropriately.

Learn C++ template-linking magic well enough to be able to build a working shared library.

Design a language for expressing flow attributes, and build a parser to read that language, so that attributes can be specified in a configuration file.

Build an autoconf wrapper for building ANTARES.

Set up the autoconf wrapper to be able to build on *BSD.

Tidy up the dependencies and depended-upon libraries (particularly qcap - the reliance on a patched pcap for file pointers is not a great thing).

Member Aggregate::addAttrib (const std::string &ident, const Attribute &attrib, uint32_t tier=0)
add checking to ensure attribute is valid for this aggregate

Member Aggregate::getPacketCount (void) const
this is going to get tricky if we need a packet count of non-basic aggregates that contain other (not necessarily exclusive) aggregates (i.e. overlapping sub-aggregates).

Member Aggregate::tiers
reimplement this to use a vector of pairs and the STL sort algorithm

Member ArithmeticAttribute::linkToAggregate (Aggregate &parent)
- verify that the attributes exist and are scalar

Member ByteCountAttribute::compute (void)
set up ByteCountAttribute as a listener so that it can compute its value online

Member ByteCountAttribute::getValue (void) const
- check for overflow

Class Clock
We can probably build a better system to handle time-based events. One option would be to implement multiple event channels, e.g. global, per flow, per attribute, etc., then have attributes subscribe to the appropriate channels. For example, a 'max datarate' attribute would have to subscribe to the appropriate packet length window, which would notify the former before and after any value was added or removed from the window. This route would require a lot of careful design to be sure that everything would work properly, without incurring excessive amounts of overhead.

make certain that all attributes update when their values are accessed, otherwise bad things _will_ happen. This would be best to do by changing the getAttrib handling so that the superclass was more involved, possibly by replacing the per-attribute function with an initialization that populates a member which could be accessed by Attribute::getAttrib.

Member ConsecutivePacketFilter::match (const TraceIterator &pkt) const
these match functions should probably throw an exception if the wrong one is used; e.g. if the StreamKey match is called on a ConsecutivePacketFilter that has a non-null prevPacket.

Find a better way to implement stateful packet filters.

Class ConversationTrackerAttribute
possibly extend this to be able to consider bytecounts in each direction instead of or in addition to datagram count.

Class DurationAttribute
Generalize to a RangeAttribute

Class Histogram< T >
Histogram<T>( const T& lower, const T& upper, const T& increment, bool finite = false );

Class HistogramAttribute< T >
ctor which takes a Histogram object, so that we can use custom Histogram subclasses transparently.

Member IPv4Key::operator< (const StreamKey &rhs) const
Test comparisons between unidirectional and bidirectional IPv4Keys

Member MemoryAttribute::begin (void) const
should push all the iterator stuff up to ArrayAttribute, there's no need for it to be here.

Member MemoryAttribute::getAttrib (const std::string &ident) const
actually implement this, e.g. first and last - will need to template-ize StaticScalarAttribute, though

Member MemoryAttribute::getSum (void) const
this functionality should be implemented in ArrayAttribute. Will need to find a good way to do getAttrib hierarchically first, though, e.g. always call super::getAttrib() before throwing an UnknownAttributeException if you don't know the ident.

Member StreamKey::getDirection (const TraceIterator &packet) const
Possible support for StreamKeys with more than two directions?

Member StreamedTCPParser::handlePassedPacket (TraceIterator &newPkt)
figure out a better way to do this that can distinguish between different flows with the same 5-tuple (probably add a unique ID by XORing tv_sec, tv_usec, and the ISN - would need to cache that though, as they would not be available later in the session)

Member StreamedUDPParser::handlePassedPacket (TraceIterator &newPkt)
figure out a better way to do this that can distinguish between different flows with the same 5-tuple (probably add a unique ID by XORing tv_sec, tv_usec, and the ISN - would need to cache that though, as they would not be available later in the session)

Member SumAttribute::getValue (void) const
- check for overflow

Class TraceIterator
Make const TraceIterators protect the Packet without requiring major contortions to support anceator and descendant tracking (the major headache for const TraceIterators)

Generated on Thu Apr 5 01:02:39 2007 for ANTARES by  doxygen 1.4.2