From: Christian Herdtweck Date: Thu, 22 Jan 2015 09:12:47 +0000 (+0100) Subject: removed Readme.code because was neither up to date nor informative; updated TODO X-Git-Url: http://developer.intra2net.com/git/?a=commitdiff_plain;h=a4de839c544c6140ef27bf73992f71d509ce51c3;p=pingcheck 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 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 --- 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.