<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Junxiao,<br>
<br>
thanks for your prompt feedback, below follows a short description
of my quick&dirty "set-up" and then few more comments in-line:<br>
<br>
Scenario in mind (caveat: I don't know if it makes sense, but that's
what I need; so if you think of an alternative, as I guess you
already did according to your previous suggestion, please feel free
of throwing away what follows and propose sth else)<br>
-----------------------<br>
On the same machine where nfd is running, I use the ndnpeedk to
generate an Interest with prefixA. My nfd has a rule that forwards
Interests with prefixA out to a specific veth1. On that veth1 I have
some software running that processes the Interest and then forwards
the same Interest back to the nfd through a different interface,
veth2. In the meantime I've started a local producer (ndnpoke -w)
for that content that correctly receives the Interest(the 2nd one
received on veth and not the 1st one issued by ndnpeek) and answers
back with the Data. The nfd forwards the data back to veth2, the
software processes it and then forwards it to nfd through veth1. Nfd
forwards the data back to ndnpeek.<br>
<br>
Why am I doing this? I need two applications, one consumer and one
producer, like ndnpeek and ndnpoke that generate ndn packets. <br>
<br>
The problems that I would like to avoid are the following:<br>
- the pit record for the Interest issued by ndnpeek risks to drop
the Interest received on veth2 [SOLVED] I change the nonce when I
process the Interest for the 2nd time.<br>
- ndnpeek and ndnpoke cannot be started simultaneously, otherwise
ndnpoke will provide the Data to ndnpeek in one step<br>
- if the 1st Interest creates a PIT record, how to avoid that nfd
will use it when receiving Data from ndnpoke? The daemon will have a
PIT record like the following<br>
"prefixA/content ---- facex(local to ndnpeek), facey(to
veth2)"<br>
and it should choose only facey<br>
<br>
Quick and dirty workaround<br>
-----------------------------------------<br>
By now I simulate the scenario above in the following way:<br>
1. Starting nfd and registering prefixA to veth1 with the nfdc cmd<br>
2. Issuing an Interest for prefixA/content with ndnpeek<br>
3. The Interest is correctly forwarded to my software through veth1
where I hold it for a while<br>
4. After ndnpeek timeout, I unregister prefixA from nfd<br>
5. Starting ndnpoke for prefixA/content with a long waiting time <br>
6. Unpausing my software that forwards the original Interest to nfd
through veth2<br>
7. nfd forwards it to ndnpoke and I get the data back from veth2<br>
8. holding again the Data<br>
9. register prefixA again like done in 2<br>
10. issuing a new Interest with ndnpeek<br>
11. unpausing the Data to forwarded it back first to nfd and then to
ndnpeek<br>
<br>
Crazy, isn't it?<br>
<br>
<div class="moz-cite-prefix">On 01/05/2016 01:35 PM, Junxiao Shi
wrote:<br>
</div>
<blockquote
cite="mid:CAOFH+OabWYudvGkQQfzJ6XBr9_pJn29KjE19v3B89GgqJ8AQ+Q@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p dir="ltr">Hi Salvatore</p>
<p dir="ltr">I'll offer a different idea to solve your problem:
pretend to be NDN forwarder.</p>
<p dir="ltr">NDN programs recognizes $HOME/.ndn/client.conf, and
connects to the NDN forwarder specified in "transport" option. <a
moz-do-not-send="true"
href="http://named-data.net/doc/ndn-cxx/current/manpages/ndn-client.conf.html"><a class="moz-txt-link-freetext" href="http://named-data.net/doc/ndn-cxx/current/manpages/ndn-client.conf.html">http://named-data.net/doc/ndn-cxx/current/manpages/ndn-client.conf.html</a></a><br>
</p>
</blockquote>
<br>
Cool, I didn't know about this config option. I guess this does mean
that the local apps use TCP instead of Unix socket as transport
connection towards the local forwarder. Have I got it right?
<blockquote
cite="mid:CAOFH+OabWYudvGkQQfzJ6XBr9_pJn29KjE19v3B89GgqJ8AQ+Q@mail.gmail.com"
type="cite">
<p dir="ltr">
You can point the transport to the TCP port or Unix socket
listener of your next stage, and use existing NDN programs.<br>
</p>
</blockquote>
My other stage is a veth. Does it make any difference with what
you're thinking of? After reading this one, I'm not sure that I've
got the previous sentence well. Could you please elaborate a little
bit according to the scenario I've described. <br>
<blockquote
cite="mid:CAOFH+OabWYudvGkQQfzJ6XBr9_pJn29KjE19v3B89GgqJ8AQ+Q@mail.gmail.com"
type="cite">
<p dir="ltr">Consumer programs should with just fine.<br>
Producer programs need small modifications: bypass prefix
registration step.<br>
</p>
</blockquote>
<blockquote
cite="mid:CAOFH+OabWYudvGkQQfzJ6XBr9_pJn29KjE19v3B89GgqJ8AQ+Q@mail.gmail.com"
type="cite">
<p dir="ltr">Yours, Junxiao</p>
<div class="gmail_quote">On Jan 5, 2016 05:27, "Salvatore
Signorello" <<a moz-do-not-send="true"
href="mailto:salvatore.signorello@uni.lu">salvatore.signorello@uni.lu</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I would like to generate some NDN packets that are not
processed in a first stage by the NFD daemon, so I guess that
I cannot use ready-made things like ndnpeek/pook/ping/etc.<br>
<br>
Has anyone already implemented an NDN module for a packet
generator like Scapy? If so, or if there exists other ways to
do that, could you please point me to the right resources?<br>
<br>
Do I really need to write a module for a packet generator? I
mean: does the ndn-repo have anything else that may fit the
purpose?<br>
<br>
Any help would be really appreciated,<br>
Salvatore<br>
<br>
-- <br>
Salvatore Signorello<br>
PhD student @ SecanLab<br>
<br>
Interdisciplinary Centre for Security, Reliability and Trust<br>
SnT, University of Luxembourg<br>
<a moz-do-not-send="true"
href="http://wwwen.uni.lu/snt/people/salvatore_signorello"
rel="noreferrer" target="_blank">http://wwwen.uni.lu/snt/people/salvatore_signorello</a><br>
<br>
_______________________________________________<br>
Nfd-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
<a moz-do-not-send="true"
href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev"
rel="noreferrer" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a><br>
</blockquote>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Salvatore Signorello
PhD student @ SecanLab
Interdisciplinary Centre for Security, Reliability and Trust
SnT, University of Luxembourg
<a class="moz-txt-link-freetext" href="http://wwwen.uni.lu/snt/people/salvatore_signorello">http://wwwen.uni.lu/snt/people/salvatore_signorello</a></pre>
</body>
</html>