diff --git a/doc/npcUserGuide.pdf b/doc/npcUserGuide.pdf
index 9a0d79c..ecbde59 100644
Binary files a/doc/npcUserGuide.pdf and b/doc/npcUserGuide.pdf differ
diff --git a/doc/npcUserGuide.xml b/doc/npcUserGuide.xml
index 1ad2527..da06ccc 100644
--- a/doc/npcUserGuide.xml
+++ b/doc/npcUserGuide.xml
@@ -35,12 +35,12 @@
content.
The Naval Research Laboratory (NRL) reference implementation of the
- NORM protocol includes support for 8-bit (and very soon 16-bit)
- Reed-Solomon FEC encoding with additional support for other coding
- algorithms (e.g., Low-Density Parity Check (LDPC)) planned for the future.
- The NORM specification allows for different FEC algorithms to be applied
- within the protocol. The current Reed-Solomon NORM FEC algorithms in the
- NRL implementation are limited to modest code block sizes (With 16-bit
+ NORM protocol includes support for 8-bit and 16-bit Reed-Solomon FEC
+ encoding with additional support for other coding algorithms (e.g.,
+ Low-Density Parity Check (LDPC)) planned for the future. The NORM
+ specification allows for different FEC algorithms to be applied within the
+ protocol. The current Reed-Solomon NORM FEC algorithms in the NRL
+ implementation are limited to modest code block sizes (With 16-bit
Reed-Solomon coding, larger block sizes will be allowed but very high data
rates may not be possible). For channels with random errors, the current
NORM FEC codecs are often adequate as there is flexibility in how the
@@ -59,17 +59,10 @@
sizes).The NORM protocol is described in Internet Engineering Task Force
- (IETF) Request For Comments (RFC) RFC 3940 and RFC 3941. These are
- experimental RFC standards. These documents have been revised in recent
- Internet-Drafts and it should be noted that the Naval Research Laboratory
- (NRL) implementation of NORM that is represented here has been updated to
- reflect the revised protocol. In addition to this demonstration
- application, NRL provides a NORM protocol library with a well-defined API
- that it is suitable for application development. Additionally, the NRL
- source code distribution supports building the NORM protocol as a
- component into ns-2 and OPNET network simulation
- environments. Refer to the NRL NORM website <http://cs.itd.nrl.navy.mil/work/norm>
+ (IETF) Request For Comments (RFC) RFC 5740 and RFC 5741. NRL provides a
+ NORM protocol library with a well-defined API that it is suitable for
+ application development. Refer to the NORM website <https://github.com/USNavalResearchLaboratory/norm>
for these other components as well as up-to-date versions of this
demonstration application and documentation.
@@ -203,12 +196,12 @@
npc encode input originalFile.txt
- The default npc configuration is XXX.
-
This will produce and output file named
"originalFile_txt.npc" in the current working
- directory, The original file can be recovered (decoded) using the
- syntax:
+ directory. The default npc configuration is
+ "auto 100.0" providing 100% parity content which makes
+ the encoded file size roughly double the input file. The original file can
+ be recovered (decoded) using the syntax:
npc decode input originalFile_txt.npc
@@ -216,8 +209,8 @@
named "originalFile.txt" in the current working
directory. (The file name information was stored in first "meta data"
segment of the ".npc" file). This default naming convention can be
- overridden by using the npc "output" option. For example, the
- syntax:
+ overridden by using the npc ""
+ command. For example, the syntax:
npc decode input originalFile_txt.npc output file.txt
@@ -247,13 +240,13 @@
commands included to support transport of npc encoded
files. The distinction here is that a file that _fails_ NORM transport
might still be successfully decoded with npc. There
- are two receiver-side norm demo application options that apply
- here:
+ are two receiver-side norm demo application options
+ that apply here:
The "" command causes
- norm to not delete (and attempt to postprocess)
+ norm to not delete (and attempt to postprocess)
"aborted" files (files that failed reliable NORM transport).
@@ -323,8 +316,8 @@
<numData>Specify the number of source data segments (packets)
- per npc FEC coding block. (Default block sizing is
- auto)
+ per npc FEC coding block. (Default block sizing
+ is auto)
@@ -332,7 +325,7 @@
<numParity>Specify the number of FEC parity segments (packets)
- added per npc FEC coding block. (Default is 2
+ added per npc FEC coding block. (Default is 2
segments).
@@ -345,10 +338,10 @@
percentage of FEC parity segments to include per block. The "auto"
block sizing sets the block size as large as possible to treat the
entire files as one logical FEC block to maximize FEC performance.
- The maximum possible block size currently supported by npc are
- blocks where (numData + numParity) is less than or equal to 65536.
- The maximum buffer size can be limited by using the
- command.
+ The maximum possible block size currently supported by
+ npc are blocks where (numData + numParity) is
+ less than or equal to 65536. The maximum buffer size can be
+ limited by using the command.
diff --git a/src/common/normPrecode.cpp b/src/common/normPrecode.cpp
index 75bc83c..853706b 100755
--- a/src/common/normPrecode.cpp
+++ b/src/common/normPrecode.cpp
@@ -112,7 +112,7 @@ const ProtoFile::Offset NormPrecodeApp::SEGMENT_MAX = 8192;
NormPrecodeApp::NormPrecodeApp()
: encode(true), segment_size(1024), num_data(196), num_parity(4),
- parity_fraction(-1.0), b_max(65536),
+ parity_fraction(100.0), b_max(65536),
i_max(1000), i_buffer_max(1500000000)
{
in_file_path[0] = '\0';
@@ -222,6 +222,7 @@ bool NormPrecodeApp::OnCommand(const char* cmd, const char* val)
return false;
}
num_data = numData;
+ parity_fraction = -1.0; // explicit block size overrides "auto" mode
}
else if (!strncmp("parity", cmd, len))
{