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

Alex Afanasyev alexander.afanasyev at UCLA.EDU
Fri Mar 13 16:25:41 PDT 2015


> On Mar 13, 2015, at 4:13 PM, Burke, Jeff <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
> 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/20150313/ab48e2c7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150313/ab48e2c7/attachment.bin>


More information about the Nfd-dev mailing list