Capturing NORM Protocol Statistics

[marygilliland]

With debug level set to 3, receivers generate messages such as the text shown below every 20 seconds. Some of these fields are fairly obvious, such as grtt, others not so much, such as read_index. Can an explanation for these fields be provided? And is there an API to obtain any or all of these values? I would especially like to be able to have my receivers report the number of nacks they have sent, but some of these other stats may also be useful to monitor if there is an API. Similarly, I am interested in having my sender application be able to report the number of nacks it has received from all receivers, if there is an API to accommodate that.

I have noticed a few function calls used in examples (such as NormPreallocateRemoteSender) that are not documented in the Developer Guide, else I wouldn't ask if there are additional API functions.

Proto Info: REPORT time>20:38:48.415938 node>279718906 ***************************************
Proto Info: Remote sender>279715930 grtt>0.001662 sec loss>0.109489
Proto Info: rxRate> 25.040 kbps rx_goodput> 22.960 kbps
Proto Info: rxObjects> completed>0 pending>1 failed>0
Proto Info: fecBufferUsage> current>50400 peak>89600 overuns>0
Proto Info: strBufferUsage> current>50400 peak>89600 overuns>0
Proto Info: resyncs>0 nacks>20 suppressed>0
Proto Info: stream_sync_id>0 stream_next_id>23 read_index:1.36
Proto Info: ***************************************************************************

Thanks!

[bebopagogo]

It is on my "todo" list to provide an API to access the statistics that NORM keeps that you see here in the debug log output. I had outlined an approach based on using a type-length-value for packing stats into some buffer that an application could use to query for these values as well as reset the counters (i.e., so that a different interval than what the debug logging uses could be supported if desired). Since, I have been fairly limited on time spent on the NORM code, I haven't accomplished that yet. Your interest will let me prioritize that.

In the meanwhile, there is a sort of "hack" available where you can redirect the text debug content to a "pipe" that your application can monitor for the logging text and parse to retrieve the stats. As I said, this is a "hack". The NormOpenDebugPipe() can be used to open a named "message" pipe. The underlying Protolib ProtoPipe class is used for this and your application would just need to include a ProtoPipe instance and use the ProtoPipe::Listen(pipeName) and ProtoPipe::Recv() methods to open and get the debug log messages (ProtoPIpe can be used within a thread or supports asynchronous I/O). Note that Protolib is not as well-documented as the NORM code. Also, you don't have to use the ProtoPipe class. On Unix systems a Unix-domain socket is used to implement the pipe while on WIndows a similar thing is used (a message pipe) ... Protolib is convenient for cross-platform portability. There are ProtoPipe examples in the Protolib code and there are Python and Java bindings to the ProtoPipe code, too

As you also noticed, I haven't updated the API documentation to include some more recent functions. My time on NORM has been focused on the examples/normSocket.h code that is an extension to the API on top of the base API calls you are using to provide a simplified socket-like API for more basic NORM use patterns and includes supporting a client-server paradigm similar to TCP by carefully managing the binding and connection of the underlying UDP sockets the NORM code uses.