Project

General

Profile

Actions
Copy link

Bug #1785

open

Face: transport is never paused after pushing Data

Added by Alex Afanasyev almost 10 years ago. Updated over 6 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Base
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Steps to reproduce:

  1. modify ndn-cxx transport/unix-transport.cpp, print a message in UnixTransport::pause

  2. run the following snippet:

    Face face;
KeyChain keyChain;
auto data = make_shared<Data>("/B");
keyChain.sign(*data, signingWithSha256());
face.put(*data);
face.processEvents();

Expected: log indicates UnixTransport::pause is invoked after pushing Data

Actual: UnixTransport::pause is never invoked

When no incoming transmission is expected (no registered prefix and no pending Interest), the transport should be put in paused state, where asynchronous send and receive operations are cancelled on the socket.

However, when a face is used in the above manner, the pause condition is not met due to improper design.

Actions
Copy link
 #1

Updated by Alex Afanasyev almost 10 years ago

  • Project changed from NFD to ndn-cxx
Actions
Copy link
 #2

Updated by Alex Afanasyev almost 10 years ago

  • Subject changed from Face can be incorrectly paused in some cases to Face can be incorrectly paused/not paused in some cases
Actions
Copy link
 #3

Updated by Junxiao Shi almost 10 years ago

  • Category set to Base
  • Target version set to v0.2
Actions
Copy link
 #4

Updated by Junxiao Shi almost 10 years ago

  • Tracker changed from Task to Bug
  • Target version changed from v0.2 to v0.3
Actions
Copy link
 #5

Updated by Junxiao Shi over 9 years ago

In what case would Face be incorrectly paused / not paused?

Is there a code snippet that can reliably reproduce these issues?

Actions
Copy link
 #6

Updated by Alex Afanasyev over 9 years ago

Junxiao Shi wrote:

In what case would Face be incorrectly paused / not paused?

Is there a code snippet that can reliably reproduce these issues?

I haven't tested it, but suspect that if you do

Face face;
auto = make_shared<Data>(...);
face.put(*data);

than this would not trigger pausing ever.

Actions
Copy link
 #7

Updated by Junxiao Shi almost 9 years ago

  • Subject changed from Face can be incorrectly paused/not paused in some cases to Face: transport is paused after pushing Data
  • Description updated (diff)
  • Target version changed from v0.3 to v0.4

Original report:

Currently, Face will be put in "paused" state (canceled on outstanding async* operations).

When Face is used only to publish Data (e.g., example in note 2 of issue #1769), the pause condition is never satisfied and even if there is no incoming transmission is expected, async_recv is never stopped.

When Face is used to respond to exactly one incoming Interest (prefix unregistered just after data is "put"), it is unlikely, but the Face can be incorrectly and prematurely put to "paused" state with all send operations canceled.

I'm able to reproduce the first problem with an extension of the snippet given in note-6.

I'm unable to reproduce the second problem with this snippet:

Face face;
const RegisteredPrefixId* rpid;

void
processInterest(const Interest& interest)
{
  std::cout << "processInterest" << std::endl;
  KeyChain keyChain;
  auto data = make_shared<Data>(interest.getName());
  keyChain.sign(*data, signingWithSha256());
  face.put(*data);
  face.unsetInterestFilter(rpid);
}

int
main(int argc, char** argv)
{
  rpid = face.setInterestFilter("/C", bind(&processInterest, _2), bind([]{}));
  face.processEvents();
  return 0;
}

If you have a snippet that can reproduce the second problem , please report a separate bug, because these two problem are related but not the same.

Actions
Copy link
 #8

Updated by Junxiao Shi almost 9 years ago

  • Subject changed from Face: transport is paused after pushing Data to Face: transport is never paused after pushing Data
Actions
Copy link
 #9

Updated by Alex Afanasyev over 8 years ago

  • Target version changed from v0.4 to v0.5
Actions
Copy link
 #10

Updated by Junxiao Shi almost 8 years ago

I guess the problem is caused by the lack of pause call (enclosed in appropriate conditions) in StreamTransportImpl<BaseTransport, Protocol>::handleAsyncWrite?

Actions
Copy link
 #11

Updated by Davide Pesavento over 6 years ago

  • Target version deleted (v0.5)
  • Start date deleted (07/20/2014)
Actions
Copy link

Also available in: Atom PDF