[Nfd-dev] Behavior of "on demand" faces to applications

[Burke, Jeff]

Alex / nfd folks,

We're going to make sure local connections are through unix sockets whenever available.

Two quick related questions.  Feel free to send a RTFM pointer:

#A -
- Is there a built-in way for "persistent" routes to get re-established if the TCP connection goes down?   I interpreted your original description to mean this is not the default behavior.

#B -
In the case of UDP faces, what happens in this situation:

1. nfdc is used to register (with a local NFD) a persistent UDP face for a remote NFD
2. The face is created successfully
3. The remote NFD is killed and then restarted

Is the intended behavior that the face created in #1 is still up after #3?   (And, has this been the case in all versions of NFD?  I am debugging a problem on an installation running an older version of NFD on the Raspberry PI.)

Thanks!
Jeff

From: Alex Afanasyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
Date: Fri, 13 Mar 2015 16:53:37 -0700
To: "Gusev, Peter" <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>>
Cc: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>, "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Behavior of "on demand" faces to applications

This could be some side effect of tcp connection, though nothing really should be happening bad.  Do not use TCP to connect to local daemon, unless it is your only option.

You should enable DEBUG level on TcpFace, TcpLocalFace, FaceTable and see why face is removed.

On Mar 13, 2015, at 4:40 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:

Hi Alex,

The face is created in pretty standard way - here is the code<https://github.com/named-data/ndn-opt/blob/master/publisher/src/ros2ndn_converter/src/ndn_controller.cpp#L29>. JeffT’s NDN-CPP library uses TcpTransport to connect to local NFD.
When we noticed that consumer is not getting any data, but producer is alive and no exceptions were thrown (like socket destroyed or similar), we checked nfd-status output and discovered that there is no face with producer’s prefix anymore.

The only fact that producer was running for some lengthy time (20-30 minutes) and no interests were issued for its’ data during this period made us think it might be “on-demand” faces’ problem...

Thanks,

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748
peetonn_ (skype)

On Mar 13, 2015, at 4:31 PM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:

Thanks, Alex. Peter, can you explain where you were seeing this? I thought it was with an app face, not udp...

-----Original Message-----
From: Alex Afanasyev [alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>]
Received: Friday, 13 Mar 2015, 4:25PM
To: Burke, Jeff [jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>]
CC: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu> [nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>]
Subject: Re: [Nfd-dev] Behavior of "on demand" faces to applications


On Mar 13, 2015, at 4:13 PM, Burke, Jeff <jburke at remap.UCLA.EDU<mailto:jburke at remap.UCLA.EDU>> wrote:


Hi folks,

Could you please confirm the default behavior of "on-demand" face creation for applications?

My understanding:  The face created by default when an application registers a prefix is "on demand", meaning it can be destroyed by NFD if inactive for some timeout period.

Not exactly (may be I misunderstood the question).  Whenever face is created by an explicit command, it is “persistent” (we also reserved concept “permanent”, but it is not yet implemented).

On-demand face is face that is created as a response of incoming tcp connect or packet received on UDP face.  Only UDP face can get destroyed, TCP faces exist for as long tcp connection is alive.

* * *

If you’re referring to the UDP face from the the other side of tunnel, then yes.  That face is on-demand and can be destroyed on the other side if no traffic.

Remote registration built in into NFD/RIB management can take care of proper refreshing state.  This is currently implemented, but requires some conventions on registered namespaces / available keys (it is documented in TR Yanbiao is working).

This behavior has caused some troubleshooting challenges with a long-running publisher and occasionally interested consumers.

Some questions:

- Where is this behavior documented? It is mentioned in p10 of the developer's guide, but I can't find either the constant or configuration parameter that sets it.

Some documentation regarding default values used is also available in nfd.conf.sample.


- Is it the case that on-demand faces will not be destroyed if any traffic has traversed them?  Or just that no traffic has traversed during the timeout interval?

Not sure I understood the question.  on-demand udp face will not be destroyed if at least one packet (data/interest) is received during the timeout interval.


- What is the appropriate way to create a face that persists until the process that created it is either destroyed or unregistered the prefix?

Rely on remote registration process (I would say this is preferred).  Alternatively, this could be something else that periodically send interest towards the remote end.


Thank you,
Jeff




_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150321/f31a85f4/attachment.html>