Fri Oct 29 09:45:31 UTC 2004
Below is the output of 'cdcc rtt' from one of our mailservers, running dccifd, with passwords removed. ----> # cdcc rtt # 10/29/04 11:32:58 CEST /usr/local/dcc/map # Re-resolve names after 13:32:58 Check RTTs after 11:47:58 # 0.52 ms threshold, 0.60 ms average 5 total, 4 working servers IPv6 off dcc2.dcc.xs4all.nl,- 32771 # 220.127.116.11,- XS4ALL ID 1021 # 100% of 32 requests ok 7.59 ms RTT 9 ms queue wait dcc3.dcc.xs4all.nl,- 32771 # 18.104.22.168,- XS4ALL ID 1022 # 50% of 4 requests ok 0.52 ms RTT 0 ms queue wait dcc4.dcc.xs4all.nl,- 32771 # * 22.214.171.124,- XS4ALL ID 1065 # 33% of 6 requests ok 0.40 ms RTT 0 ms queue wait dcc5.dcc.xs4all.nl,- 32771 # 126.96.36.199,- XS4ALL ID 1066 # 25% of 8 requests ok 10.49 ms RTT 8 ms queue wait dcc1.dcc.xs4all.nl,- 32771 # 188.8.131.52,- # not answering <--- Note that cdcc claims that dcc1.dcc.xs4all.nl was 'not answering' at this time. It most definitely was. A tcpdump of traffic to or from 184.108.40.206 from the host that this command was run on, shows no packets being sent to that server at all. A random check indicates that more of our dcc client installations exhibit this behaviour, although apparently not all. Is that intended behaviour? Does this not cause that last server to never be picked by the client as the server to send it's reports to? Thanks, Vincent.
More information about the DCC