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)

---