NFD » ndn-cxx

Please attach application code.

Remember that your application shouldn't send Data without first receiving an Interest.

As announced, NFD will not accept unsolicited Data.

I plotted the memory with 0.01 sec sampling, the machine is not running out, it has 128GB RAM.

Please attach application code.

http://redmine.named-data.net/attachments/download/191/ndnputbigchunk.cpp

Remember that your application shouldn't send Data without first receiving an Interest.

As announced, NFD will not accept unsolicited Data.

Ok. But why crash at 800MB? Should NFD not reject whenever it receives any unsolicited data?

This app is sending unsolicited Data into NFD.

When doing so, the Face is not yet connected.

The correct behavior should be: NFD drops those Data; app shouldn't crash.

I guess some buffer used by Face::put is full, most likely StreamTransportImpl<..>::m_transmissionQueue.

I have put this in the stream-face.hpp:

284 while (m_inputBufferSize - offset > 0)
285 {
286 isOk = Block::fromBuffer(m_inputBuffer + offset, m_inputBufferSize - offset, element);
287 if (!isOk){
288 NFD_LOG_WARN("Can not create block from buffer");
289 break;
290 }
291

When the app crashes, NFD log also shows "Can not create block from buffer".

It's normal on NFD side. NFD should show this many times until the whole packet is received. If only part of packet is received, it cannot yet decode TLV

Also, I printed the error code in the error handler (stream.hpp, line 273).

It says: "Error code: asio.misc:2 (End of file)"

Are you saying that if you try to send <800 MB it actually works? i.e. NFD receives the whole thing and forwards it?

It says: "Error code: asio.misc:2 (End of file)"

This only means that TCP/UnixSocket connection got closed.

Davide Pesavento wrote:

Are you saying that if you try to send <800 MB it actually works? i.e. NFD receives the whole thing and forwards it?

Yes, NFD receives the whole thing and puts it in the CS. If there is an Interest for it, NFD sends the data back from CS.

We found out the problem. In the application, m_face.put(*data) was called before the run() loop. This caused the run loop to block while data was being published. The connect timer of 4 seconds in src/transport/stream-transport.hpp caused a timeout and closure of the face.

The only remaining problem is that the face still accepts unsolicited data.

Please close this if that's not a bug/duplicate.

This is not right. There shouldn't be problem calling m_face.put() before run() loop. When put is called before connect, data packet suppose to be remembered and actual publishing should have happened just after connect.

Said a different way, the problem is that the application is creating a Face (default unix transport), putting a huge Data, and then calling run.

I think the timer for the transport connect is ticking away while the large Data is being put. We observed connection setup times between the transport's async_connect and timeout handler being triggered/cancelled varying based on the size of the Data. The problem seems to be solved by doing a short run after creating the Face, then putting the Data and the normal run() call.

Oh... Yeah. This timeout issue seem to be a re-occurring problem and I will try to fix it.

At 20150901 conference call, Alex believes this is probably a duplicate of #2742.
We can confirm this after #2742 is resolved.