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

Burke, Jeff jburke at remap.ucla.edu
Sat Apr 12 12:47:42 PDT 2014


Ah, I think I see :)

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.

Yes, I agree, if what you mean by "the only way" is what's currently provided in the library.  But things are marshalled (serialized) / unmarshalled is up to the application.  If the application wants to use the TLV encoder, that's fine and we can expose it.   But it should be clear that it's happening because of expedience , not because the app cares about the wire format.

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.

I don't know that applications should be serializing things in the "wire format" - though the repo might - they should serialize in whatever makes sense for the app, which might happen to be the same TLV format (because the encoder/decoder is around and handy) but could also be any number of other representations.

My concern is not just expedience and practicality but  that we need to consider what we are implying to the other users of the libraries, tools, and examples.

Yes, the TLV format is handy and could be used.  But that's an application-level decision, right?   So by choosing the wire format utilities of this, we may convey the wrong message in examples.   Some of this can be fixed by comments and explanations.  In other cases, we may want to specifically demonstrate alternative formats.

I think Wentao is interested in experimenting with the "wire format" (and maybe your tools need to do this for now) itself, which is a different thing altogether and was what my previous email was about.

My 2 cents; a little rushed right now.

Jeff


From: Alex Afanasyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
Date: Sat, 12 Apr 2014 12:14:10 -0700
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: Wentao Shang <wentaoshang at gmail.com<mailto:wentaoshang at gmail.com>>, "ndn-lib at lists.cs.ucla.edu<mailto:ndn-lib at lists.cs.ucla.edu>" <ndn-lib at lists.cs.ucla.edu<mailto:ndn-lib at lists.cs.ucla.edu>>
Subject: Re: [Ndn-lib] wireEncode/wireDecode interface missing in Name class

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<mailto: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<mailto:wentaoshang at gmail.com>>
Date: Sat, 12 Apr 2014 10:06:50 -0700
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: "Dave Oran (oran)" <oran at cisco.com<mailto:oran at cisco.com>>, "ndn-lib at lists.cs.ucla.edu<mailto:ndn-lib at lists.cs.ucla.edu>" <ndn-lib at lists.cs.ucla.edu<mailto: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<mailto: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<mailto:wentaoshang at gmail.com>>
Date: Sat, 12 Apr 2014 09:43:09 -0700
To: "Dave Oran (oran)" <oran at cisco.com<mailto:oran at cisco.com>>
Cc: "ndn-lib at lists.cs.ucla.edu<mailto:ndn-lib at lists.cs.ucla.edu>" <ndn-lib at lists.cs.ucla.edu<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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/aa422754/attachment-0001.html>


More information about the Ndn-lib mailing list