[Ndn-lib] wireEncode/wireDecode interface missing in Name class

Alex Afanasyev alexander.afanasyev at ucla.edu
Sat Apr 12 12:14:10 PDT 2014


Hi Jeff,

I actually read Dave's email in a very different way you did :).   We must have a way to work with efficient representation of name (marshal/unmarshal) in the API.  Right now we have none and the only way name can be "unmarshalled" is from plaintext URI, which is really inefficient.  TLV is our efficient format that we are using right now, exposing it in API must be done, since it is actually trivial to do.

Actually, I had exactly the same question as Wentao a while back.  In several applications that I wrote I directly rely on name wire encoding/decoding and I assumed that this part is in CCL, but somehow I missed that it is not there.  Specific examples: ChronoShare, where name as used as in Shuo's repo implementation as a direct index.  Name and direct name manipulation is used in ndnops tool (operator tools to help sign user's certificates, and the web server implementation as a supporting service).  One of the versions of ChronoSync is also using names directly wire format of names to efficiently exchange them.  NDNS implementation must have access to wire encoding of names to efficiently encode name mappings.

Also, in my opinion other parts of Data/Interest packets should also be exposed directly (but not necessarily for the same reason).  Backwards compatibility/application extensibility and this can be applied here.  The library doesn't necessarily know how to handle all what application put into the data packet (remember, we were talking of incorporating application-defined parts into MetaInfo of Data packet).  I can give more examples later, but the point is that in NDN (at least at the current stage of the project), applications need to work with wire format of every element and we have to have this support in the library.

---
Alex


On Apr 12, 2014, at 11:54 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:

> 
> Hi Wento,
> 
> Could you give a specific example of when the wire format (e.g., specific TLV type encoding bits) would be necessary for the applications you are considering to know?   Even the command interests are built up by manipulating the value bits only, I thought.  
> 
> (I'm not saying we shouldn't expose this for experimentation, but I still don't understand the scenario except in the abstract.)
> 
> Thanks,
> 
> Jeff
> 
> 
> From: Wentao Shang <wentaoshang at gmail.com>
> Date: Sat, 12 Apr 2014 10:06:50 -0700
> To: Jeff Burke <jburke at remap.ucla.edu>
> Cc: "Dave Oran (oran)" <oran at cisco.com>, "ndn-lib at lists.cs.ucla.edu" <ndn-lib at lists.cs.ucla.edu>
> Subject: Re: [Ndn-lib] wireEncode/wireDecode interface missing in Name class
> 
> 
> 
> 
> On Sat, Apr 12, 2014 at 9:58 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
>> Wentao,
>> 
>> I'm really not sure what you mean.  If the library extracts the bits of each name component from the TLV component, what more is needed? 
> 
> If the Name is critical to the application, I think maybe it is useful to expose both high-level abstraction and low-level detail (like wire encoded streams). Exposing the wire format of other TLV classes may be an overkill.
> 
> In the current API, we already have wireEncode/wireDecode for Interest and Data. But I would argue that the applications might care more about the wire format of Names than the format of Interest/Data, if they care about the wire format at all...
> 
> Wentao 
>  
>> 
>> Jeff
>> 
>> 
>> From: Wentao Shang <wentaoshang at gmail.com>
>> Date: Sat, 12 Apr 2014 09:43:09 -0700
>> To: "Dave Oran (oran)" <oran at cisco.com>
>> Cc: "ndn-lib at lists.cs.ucla.edu" <ndn-lib at lists.cs.ucla.edu>
>> Subject: Re: [Ndn-lib] wireEncode/wireDecode interface missing in Name class
>> 
>> 
>> 
>> 
>> On Sat, Apr 12, 2014 at 5:17 AM, Dave Oran (oran) <oran at cisco.com> wrote:
>>> This is fairly scary. What if we decide to change the wire format? Do all the applications break?
>> 
>> Hi Dave,
>> 
>> I understand the hope is to decouple applications from wire format as much as possible. But it's not like in the IP world where we almost never touch the TCP/IP header bits in applications. In NDN the Name is shared information between network layer and application layer. I doubt if we can completely eliminate the case where app developers need to deal with the TLV-formatted names.
>> 
>> Wentao
>>  
>>> 
>>> Maybe we're just having a terminology misunderstanding here. Applications should have an API that allows them to construct and deconstruct names from/to typed name components. It's the protocol stack's responsibility to take those application-oriented data structures and marshall/unmarshall the wire format of the name field in the messages.
>>> 
>>> If such an API doesn't exist that's a major hole, IMO.
>>> 
>>> 
>>> On Apr 11, 2014, at 10:03 PM, "Wentao Shang" <wentaoshang at gmail.com> wrote:
>>> 
>>>> One example is repo-ng, which stores names in wire format.
>>>> 
>>>> Another use case in my mind is that I want to create customized command interest for ndn smart home control, which also requires dealing with wire format names.
>>>> 
>>>> Wentao
>>>> 
>>>> On Friday, April 11, 2014, Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:
>>>>> Hi Wentao,
>>>>> 
>>>>> Can you say something more about how your application needs to directly manipulate the Name wire format?
>>>>> 
>>>>> Thanks,
>>>>> - Jeff T
>>>>> 
>>>>> From: Wentao Shang <wentaoshang at gmail.com>
>>>>> Date: Friday, April 11, 2014 5:52 PM
>>>>> To: NDN Lib <ndn-lib at lists.cs.ucla.edu>
>>>>> Subject: [Ndn-lib] wireEncode/wireDecode interface missing in Name class
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> In NDN CCL API 0.1a2 documentation, there is no interface to directly manipulate the wire format of Name class. In some applications this feature is needed. And since Name-related operations are essential part of NDN application development, it would be nice in general to have the capability of handling wire format of Names. Any thoughts about adding this interface to the CCL API?
>>>>> 
>>>>> Best,
>>>>> Wentao
>>>>> 
>>>>> -- 
>>>>> PhD @ IRL, CSD, UCLA
>>>> 
>>>> 
>>>> -- 
>>>> PhD @ IRL, CSD, UCLA
>>>> 
>>>> _______________________________________________
>>>> Ndn-lib mailing list
>>>> Ndn-lib at lists.cs.ucla.edu
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-lib
>> 
>> 
>> 
>> -- 
>> PhD @ IRL, CSD, UCLA
>> _______________________________________________ Ndn-lib mailing list Ndn-lib at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-lib
> 
> 
> 
> -- 
> PhD @ IRL, CSD, UCLA
> _______________________________________________
> Ndn-lib mailing list
> Ndn-lib at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-lib

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-lib/attachments/20140412/a4cbcd4a/attachment.html>


More information about the Ndn-lib mailing list