removed Readme.code because was neither up to date nor informative; updated TODO

diff --git a/Readme.code b/Readme.code
deleted file mode 100644 (file)
index f3fa01c..0000000
--- a/Readme.code
+++ /dev/null
@@ -1,122 +0,0 @@
-     Table of Contents
-=======================================
-1. Code Conventions
-2. Source Code
-
-
-
-1.   Code Conventions
-=======================================
-This section describes the code conventions that must be followed when maintain
-this code.
-
-
-1.1. Data Types
----------------------------------------
-This section is a guideline about the type you MUST use when declaring
-variables and constants. These types were chose to provide portability and
-improve code readability.
-
-- Use the std::string to represent array of characters.
-
-- Use int32_t, int16_t and int8_t (or their unsigned counterparts) - instead of
-  int, short and char, respectively - when the variable or constant MUST have a
-  specific size (e.g. like in the protocol headers). This documents that the
-  variable has the given number of bits. This states clear the intent of the
-  original programmer and avoids improper modifications.
-
-- Use only int for regular integer numbers that do not require any specific
-  size. And document that a variable is non-negative using assertions. Do not
-  use unsigned types to say a number will never be negative.
-
-- Use std::size_t for integers that represent sizes of vectors, objects or
-  buffers. Thus leaving the size definition to the platform.
-
-
-1.2. Coding Style
----------------------------------------
-The coding style used in this program is in accordance with the Intra2net,
-which can be found in the following source:
-
-- http://intranet/support_wiki/doku.php?id=entwicklung:codingstyle
-
-
-1.3. Versioning
----------------------------------------
-Version is built as follows:
-  major.minor
-where:
-- "major" represents big changes in application functionality.
-- "minor" means small changes or bug fixes.
-
-
-1.4. Error Handling
----------------------------------------
-There are two basic kinds of errors that shall happen in the program, errors
-that the program can recover (expected) and errors that the progam can not or
-should not recover from (exceptional errors). Bellow the description and the
-method adopted to deal with each one:
-- Expected: these errors can occur and must be handled by boolean return values.
-  (i.e. if a host is down, if the address was not resolved). This errors can
-  happen, but THE PROGRAM MUST CONTINUE TO OPERATE EVEN IF THEY HAPPEN.
-- Exceptional: these are the kinds of errors that should not occur. They must be
-  handled by exceptions and THE PROGRAM MUST HALT IF THEY HAPPEN.
-Thus, to keep things as simple as possible, this program adopts just two kinds
-of error detection and handling:
-- Return Boolean Value for expected errors and
-- Handle Exceptions for exceptional errors.
-
-
-1.5. Assertions
----------------------------------------
-Also, it is good to use ASSERTS to document assumptions about:
-- method's argument values. If you expect that a parameter have certain values,
-  assert it (preconditions)
-- and if you expect the method deliver a certain value, assert in the end of
-  the method (postcondition).
-This is known by programming by contract.
-
-
-
-2.   Source Code
-=======================================
-In this section is presented an overview of the source code and key design
-decisions.
-
-
-2.1. Main directories
----------------------------------------
-The sources are spread over these distinct directories:
-- conf: keeps default and example configuration files.
-- doc: configuration files used to build the documentation.
-- lib: where lies the third party libraries maintained in this application.
-- src: contains the main application source code.
-- test: where is located the unit tests.
-
-
-2.2. Main concept of application operation
----------------------------------------
-This application makes extensive use of asynchronous timers-handlers from
-Boost ASIO. So this section describes briefly how ASIO works. More information
-can be found in the References section.
-
-The basic idea is to have a handler which will be called when a timer expires.
-After the timer expires, you have to schedule the timer again to call your
-handler once more. Given the declaration of the timer:
-
-    boost::asio::deadline_timer my_timer( my_io_service );
-
-you must specify when it will expire:
-
-    my_timer.expires_at( some_time_in_seconds + seconds( interval_in_seconds ) );
-
-and which method will handle when the timer expires.
-
-    my_timer.async_wait( boost::bind( &MyClass::my_handle_method, this ) );
-
-Then, the my_io_service service can be called to perform a loop:
-
-    my_io_service.run();
-
-
-

diff --git a/TODO b/TODO
index acd666f..a984263 100644 (file)
--- a/TODO
+++ b/TODO
@@ -6,3 +6,19 @@
   single host.
 
 - Make the configuration file reloadable (see bpdyndns).
+
+In December 2014 / January 2015 did a lot of changes to ICMP pinger (v4) which were
+  not replicated in TCP pinger nor in ICMPv6 pinger. Should check if same changes 
+  need to be applied there, too. In particular, the scheduling of reply receive 
+  handlers in ICMP caused trouble, often encountered 'ghost' packages which were all
+  0s because a handler for an old echo request was triggered without new data.
+
+Also, removed threads for each pingchecker, leaving only one thread with one 
+  io_service for all pingers. Tested that a lot with ICMP v4 pinger, but no other.
+
+Might also want to move the parsing of incoming ICMP packages into central class
+  because every ICMP socket receives incoming data for all request from same process,
+  so each pinger has to parse all reply packages of requests from other pingers, 
+  discarding most of them immediately after parsing. A central IcmpPackageDistributor
+  could be created and updated in PingerFactory and be the only one with an ICMP
+  socket.