-Wish List
-=======================================
+- Validate configuration input errors, adding validation for input values, with
+ more descriptive messages if the user enters wrong values.
-- Implement a factory method to create the Pingers objects. Something like:
- smart_ptr<Pinger> pinger_ptr = PingerCreator::create(PingerCreator::Boost)
+- Allows input error handling for values which are not strictly required. The
+ goal is avoid the annoying requirement to put "port" and "interval" at every
+ single host.
-- Design a timer class on top of boost timer, but simpler.
+- Make the configuration file reloadable (see bpdyndns).
-- Include the i18n_noop in the strings, but this requires linking with the
- libgettext.
+In December 2014 / January 2015 did a lot of changes to ICMP pinger (IPv4) 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.
-- Use the I2n::Logger to log messages.
+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.
-- Perform a better treatment of missing configuration items, actually the
- application just crashes.
-
-- Refactor the BoostPinger class, it is becoming a monster.
-
-
-Known Bugs
-=======================================
-
-- If one of the "[host]" in the configuration file omit the "interval" entry,
- the application uses the next "[host]"'s "interval" entry, instead of a
- default value. The problem is specific to the configuration read classes
- that are not smart enough to verify which "[host]" have this entry and which
- don't.
- Example:
- [host]
- name=A
- [host]
- name=B
- interval=1
- [host]
- name=C
- interval=3
- Thus, the tuples will be (A,1) , (B,3), (C,?), but A should have a default
- value, instead of borrow B's value.
-
-- The interval between each ping to the same host is 1 second later than in the
- configuration file. For example, a ping configured to be performed each 5
- seconds takes 6.
-
-- The overhead when handling a link that is down causes delays with the next
- pings. This happens if the ping interval is a value close to the ping timeout.
- So the application wait this amount to ping the next host.
- This bug has something to do with the blocking ping, because the ping method
- returns only after a reply or timeout, thus increasing the interval to the
- next schedule ping to the same host and to the other hosts.
-
-- The sequence number is always 1. As the BoostPinger is created for just one
- ping.
-
-
-Fixed Bugs
-=======================================
-
-- If one ping fails, the subsequent analysis report that the ping is down:
- Example:
- Request timed out
- - Host down: www.ufsc.br
- - Speeding up ping interval to: 30s <-- should speed up, OK
- - Time elapsed since last ping: 65s <-- elapsed time, OK
- 20 bytes from 150.162.2.10: icmp_seq=1 ttl=47 time=252 ms
- - Host down: www.ufsc.br <-- dammit! It is not down, WRONG
- - Speeding up ping interval to: 30s <-- should not speed up again, WRONG
- - Time elapsed since last ping: 31s <-- elapsed time, OK, but should go
- back to original
- 20 bytes from 150.162.2.10: icmp_seq=1 ttl=47 time=253 ms
- - Host down: www.ufsc.br
- - Speeding up ping interval to: 30s
- - Time elapsed since last ping: 31s
+If the system time is changed backwards, the pingchecker freezes, including its signal
+ handler (boost asio's deadline_timer seems to work with time points on a non-monotonic
+ clock). Change that! (apparently, boost asio 1.49 introduces a steady_timer, try that)
git://developer.intra2net.com / pingcheck / blobdiff