<div dir="auto">Hi John</div><div class="gmail_quote"><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br>
</div>
<div>I am also collecting face information every minute (nfdc face list) and storing</div>
<div>that in a log file so I can see what faces existed around the time of the crash.</div>
<div>My thinking was that when we see the giant interest in the nfd.log I would be able</div>
<div>to tell where it was coming from and track down what was sending it.</div></div></blockquote><div dir="auto">You can do so without logging `nfdc face list`. Forwarder DEBUG log tells you the FaceId. FaceTable::add log tells you local and remote FaceUri associated with this FaceId.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div>
<div><br>
</div>
<div>In this case, during the time that nfd is timing out Fib Updates, I see in my</div>
<div>nfdc log file that nfdc no longer gets any results. I neglected to redirect stderr</div>
<div>to the log file but I suspect that nfdc is failing to connect to get its results.</div>
<div>But just before it starts failing it showed 501 TCP faces.</div>
<div>I have a small number of nodes in the Testbed that have a problem with</div>
<div>fragmentation and for them I run their faces as TCP. That seems to be a problem.</div></div></blockquote><div dir="auto"><br></div><div dir="auto">I used to observed similar behavior for unix faces on several nodes' HTTP status page. Occasionally, there were more than 50 unix faces. I believed it's some large monitoring script starting up. I cannot tell how often this occurs.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div>
<div><br>
</div>
<div>For this node, SRRU, it has faces to 6 other nodes. But just before it crashed</div>
<div>it had 70-100 faces to each of those 6 nodes.</div></div></blockquote><div dir="auto"><br></div><div dir="auto">Are these faces "on-demand" (created because remote node connecting in) or "persistent" (created by a local node)? Do these faces have the same local/remote port number?</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div>
<div>Why would the TCP faces not go away when a new one was needed?</div></div></blockquote><div dir="auto"><br></div><div dir="auto">If the faces were "persistent" and have same remote port but different local port, this suggests a bug in NLSR. Deployed NLSR creates faces if one does not exist, but it might repeat face creation if face dataset does not reflect new faces.</div><div dir="auto">However, I'm not concerned by this potential bug because this feature is no longer present in NLSR source code. It instead relies on "permanent" faces already created in NFD.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><blockquote type="cite">
<div><div style="word-wrap:break-word">
<div>We had another FATAL error overnight.</div></div></div></blockquote></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div><div style="word-wrap:break-word"><div><a href="https://www.arl.wustl.edu/~jdd/nfd.log.SRRU.FATAL.gz" target="_blank">https://www.arl.wustl.edu/~jdd/nfd.log.SRRU.FATAL.gz</a></div></div></div></blockquote></div></div></div></blockquote><div dir="auto">This log does not end with FATAL.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div><div style="word-wrap:break-word"><div><a href="https://www.arl.wustl.edu/~jdd/nfd.log.SRRU.FATAL.gz" target="_blank"></a></div></div></div></blockquote></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><blockquote type="cite"><div style="word-wrap:break-word" dir="auto"><div><br>
</div>
<div>I’m also very curious about what Eric said in the nfd conference call yesterday.</div>
<div>I believe he said that in integration testing he has seen an instance of a long interest</div>
<div>with empty components. Is that actually something built into the tests or is this something</div>
<div>we should be concerned about?</div></div></blockquote></div></blockquote><div dir="auto">No, there isn't an integration test scenario that uses a long name.</div><div dir="auto"><br></div><div dir="auto">Yours, Junxiao</div></div>