rob@76: TODO:
rob@76: 
rob@76:     - consider adding the local endpoint name to PacketListener::PacketReceived() params
rob@76: 
rob@76:     - consider adding ListenerThread class to support old seperate thread listener functionality, something like:
rob@76: 
rob@76:         class UdpSocketListenerThread{
rob@76:         public:
rob@76:             UdpSocketListenerThread( UdpSocket& socket, Listener *listener );
rob@76:             UdpSocketListenerThread( UdpSocketReceiveMultiplexer *mux );
rob@76:             ~UdpSocketListenerThread();
rob@76: 
rob@76:             void Run();
rob@76:             void Stop();
rob@76:         };
rob@76: 
rob@76:     - work out a way to make the parsing classes totally safe. at a minimum this
rob@76:     means adding functions to test for invalid float/doublevalues,
rob@76:     making sure the iterators never pass the end of the message, ...
rob@76:         (passing end of message can happen if:
rob@76:             - too many args in type tags
rob@76:                 a. typetags overflow message size
rob@76:                 b. args fulfilling typetags overflow message size
rob@76:             - strings too long or not terminated correctly
rob@76:             - blobs too long or not terminated correctly
rob@76: 
rob@76:         if the message was fully checked during construction, the end() iterator
rob@76:         could be moved back until only arguments which fit withing size() may
rob@76:         be interated (this could be none). A flag could be set to indicate that
rob@76:         something was wrong.
rob@76: 
rob@76:     - other packet badness could include:
rob@76:         - time tags too far into the future (the scheduler should deal with
rob@76:             that i guess).
rob@76:         - message address patterns which aren't correctly terminated
rob@76: 
rob@76:     - improve the ability to parse messages without tags (SC uses methods which
rob@76:             get the data and advance the iterator in one step.)
rob@76:         - Check* could be modified to do this - ie if typetags are not present
rob@76:             it could check that reading the field won't escape the message size
rob@76:             and return the data, or return false if some consistency
rob@76:             constraint is violated.
rob@76:         (or alternately drop support for messages without type tags)
rob@76:         
rob@76: 
rob@76:     - add a method to discard an inprogress message if it gets half
rob@76:         constructed and the buffer is full in OutboundPacket
rob@76: 
rob@76:     - write a stress testing app which can send garbage packets to try to flush out other bugs in the parsing code.
rob@76: 
rob@76: 
rob@76: