Bug #1455
closed
nfdc prematurely timeouts on failed TCP face creation
Added by Alex Afanasyev about 11 years ago.
Updated almost 11 years ago.
Description
This is a joint problem of nfdc, nfd/nrd::Controller, and FaceManager.
The "problem" occurs when someone tries to create TCP face to some random address. FaceManager uses 4 seconds timeout (4 seconds for DNS resolution or 4 seconds for connect operation). nfd(nrd)::Controller used by nfdc(nrdc) use default Interest lifetime of 4 seconds to get the response.
As a result of these, the actual negative response from FaceManager is never received by nfdc(nrdc) and the only thing nfdc(nrdc) knows is that command interest timed out.
I'm not sure what should be solution to the problem. I guess command interest should have larger (or configurable) lifetime.
- Tracker changed from Task to Bug
- Subject changed from nfdc prematurely timeouts to nfdc prematurely timeouts on failed TCP face creation
At a minimum, it was probably a bad idea for FaceManager to use a connection/resolution timeout that was the same as the default lifetime. However, FaceManager can only modify the timeout on connect because the resolution timeout is not exposed through *Factory.createFace().
You can increase the command's timeout, but I'm wondering if the manager should be told (implicitly via lifetime or explicitly with some parameter field) how long it should wait. If the manager can't create the face in time (or it looks like it can't), then it should respond with an appropriate error before the command times out.
I suggest reducing reducing timeouts on NFD side:
- DNS resolution: 1300ms
This is enough to query 5 Name servers
- TCP connect: 800ms
This is enough for a handshake.
- Above assumes 250ms roundtrip time, which is enough for most broadband connections in the world.
Technically, 4 seconds is the timeout for DNS resolution and default timeout for TCP connection is way longer than 4 seconds (not sure why, but I guess people had reasons...)
I would simply increase timeout in command interests...
Just discovered a new reason to update default timeouts. When nrd::Controller sends registration request, NRD may require to fetch certificates from the certification chain, which could take time.
ndn::nfd::Controller::start<Command>
should take an additional parameter time::milliseconds timeout
with default value set to 10 seconds.
I'll make this change if there's no objection.
Yes. This would be a first step for this.
The two "problems" that will remain is:
- selfRegistration (which may take some time when NRD needs to fetch certificates to validate the request)
- selecting specific identity to sign the command (separate issue from this).
- Project changed from NFD to ndn-cxx
- Category deleted (
Management)
- Assignee set to Junxiao Shi
- Target version deleted (
v0.2)
- Estimated time set to 1.00 h
- Status changed from New to Resolved
- Related to Task #1508: Enable timeout customization for nfd/nrd::Controller operations added
- Status changed from Resolved to Closed
Also available in: Atom
PDF