<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">\documentclass[onecolumn,letterpaper,11pt]{article}

%=================================================================
\input{common_latex/common_latex_packages}
\input{common_latex/common_latex_definitions}
\input{common_latex/common_latex_help_format}
%=================================================================

\begin{document}

\begin{labcover}
\labtitle{uFldDelve: Delving into uField Message Traffic}
\vspace{0.1in}
\labdate{Nov 2023}
\vspace{0.1in}
\labauth{Michael Benjamin, mikerb@mit.edu}
\labauth{Department of Mechanical Engineering}
\labauth{MIT, Cambridge MA 02139}
\labsrc{project-pavlab/appdocs/app\_ufld\_delve} 
\labtoc{small}
\end{labcover}

\wikidoc{file=IvPTools.PMediator}
\wikidoc{auth=mikerb@mit.edu}

%=================================================================
\section{Overview}
%=================================================================
\label{sec_pmed_overview}
\index{upMediator}

The \app{pMediator} application is a tool for mediating messages
between vehicles in situations without guaranteed message arrivals.
Outgoing messages may request a return acknowledgement message (an
"ack"), and periodically repeat the message until an ack is received
or time limit or re-send limit has been reached. The policy for
repeating a message may be configured individually per message type to
account for vital messages and nice-to-have messages. The
\app{pMediator} app runs on each vehicle and stores local information
to handle outgoing and incoming messages. Handling of incoming messages
involves both sending return acknowledgement messages and ensuring that
no incoming message is posted twice. 

\vspace{0.1in}
\noindent
The setup overview is depicted in Figure \ref{fig_pmed_overview}:

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.85\textwidth]{figures/pmed_overview.png}
  \caption{{\bf Mediated Messaging:} An outgoing message to another
    node originates within any application. The \vvar{pMediator} app
    adds a tracking ID. An app specific to whichever comms medium is
    in use will send the mediated message to the destination
    vehicle(s). A \var{pMediator} app on the receiving vehicle will
    process the message by (a) sending an acknowledgement message back
    to the sender, and (b) posting the incoming message locally. The
    incoming message will be unpacked by the \vvar{uFldMessageHandler}
    app, resulting in a MOOS variable publication received by the
    destination appp.}
\label{fig_pmed_overview}
\end{figure}
\vspace{0.1in}

\noindent
The addition of \app{pMediator} to our autonomy toolbox is based on
the following observations and assumptions:

\begin{packed_itemize}
\item Colloborative autonomy software needs to assume that
  inter-vehicle communications will be lossy, resulting dropped,
  delayed or out-of-order messages. This includes comms between the
  shoreside comand-and-control and vehicles.
\item Duplicated messages can be reliably prevented but arguably should
  also be accounted for and tested.
\item The \app{pMediator} should not only improve but also monitor and
  measure inter-vehicle message performance.
\end{packed_itemize}

\vspace{0.1in}
\noindent
Complementing \app{pMediator}, our simulation environment should also be
able to simulate lossy comms with a variety of manners of performance
drop-off, based on inter-vehicle range, message rate, and message size.
The existing app, \app{uFldNodeComms}, is augmented to simulate lossy
comms and support the \app{pMediator} inter-vehicle messaging scheme.


%=================================================================
\section{Overview Issues with Inter-Vehicle Messaging}
%=================================================================

Messages may be sent between vehicles in many different manners, e.g,
WiFi, satellite, underwater acoustic modems and so on. The issues
addressed with \app{pMediator} are independent of {\em how} messages
are sent. Instead it is concerned with {\em what} messages are sent,
whether or not their receipt by the receiver can be verified, and what
to do if it is not received.

\vspace{0.1in}
\noindent
First it is worth reminding ourselves that not all messages are the same
with respect to their importance and with respect to the policy of handling
dropped messages. They can be lumped into three general categories as
depicted in Figure \ref{fig_pmed_unequal_msgs}

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.50\textwidth]{figures/pmed_unequal_msgs.png}
  \caption{{\bf Categories of Messages:} Messages may vary from (a)
    fire-and-forget, (b) repeat if bandwidth allows, and (c) critical,
    to be repeated perhaps an unlimited number of times until an
    acknowledgement is received.}
  \label{fig_pmed_unequal_msgs}
\end{figure}

\vspace{0.1in}
\noindent
For messages that are important enough, an acknowledgment return message
can be requested (an "ack" for short). As depicted below, if the
acknowledgement has been received, the message is considered
successful. An unsuccessful message may be due to either the original
message being dropped, or the acknowledgment message being dropped.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.50\textwidth]{figures/pmed_dropped_msg.png}
  \caption{{\bf Messages with Acknowledgements:} Using an
    acknowledgement return message, the sender can be assured that the
    mesage was received (top).  The lack of an ack may be due to the failure
    of the original message (middle) or the failure of the acknowledgment
    message to reach the sender (bottom).}
  \label{fig_pmed_dropped_msg}
\end{figure}


%=================================================================
\section{Vanilla Inter-Vehicle Messaging}
%=================================================================

Inter-vehicle message passing in the MOOS-IvP environment follows a
{\em convention} with two parts. First, all inter-vehicle messages are
wrapped in the MOOS variable \mvar{NODE\_MESSAGE\_LOCAL}, arriving at
the destination vehicle(s) as \mvar{NODE\_MESSAGE}. The
\app{uFldMessageHandler} unpacks the arriving message and posts the
intended MOOS variable and value. Second, message passing is achieved
through the \app{pShare} application between vehicles, during which
the name of the messaged changes from \mvar{NODE\_MESSAGE\_LOCAL} to
simply \mvar{NODE\_MESSAGE}.

\vspace{0.1in}
\noindent
Either or both parts of this convention may be swapped out and replaced
with some other implementation. The idea is shown in Figure
\ref{fig_pmed_msg_path} below.

\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.65\textwidth]{figures/pmed_msg_path.png}
  \caption{{\bf A Typical Message Path:} (1) An application generates
    a messaged to be shared to another vehicle by packing it within a
    \mvar{NODE\_MESSAGE\_LOCAL} posting. (2) The message is shared to
    the other vehicle using some comms medium. In simulation or in
    WiFi this is done with the \app{pShare} app. (3) The packed
    message is received on the destination vehicle and unpacked to a
    simple message posted to the vehicle's local \var{MOOSDB}. (4) The
    app on the destination vehicle meant to be the consumer of this
    message, will finally receive the message.}
  \label{fig_pmed_msg_path}
\end{figure}

\vspace{0.1in}
\noindent
As we will see, the \app{pMediator} app will augment this convention
with another stage to handle acknowledgments and repeating real or
perceived dropped messages. 

%=================================================================
\subsection{Structure of an Outgoing Inter-Vehicle Message}

Each outgoing inter-vehicle message is originated by posting to the
variable \mvar{NODE\_MESSAGE\_LOCAL}. This message has four key parts:

\begin{packed_itemize}
\item {\em Source Node:} The name of the vehicle originating the message
\item {\em Destination Node:} The name of the destination vehicle
\item {\em Variable Name:} The MOOS variable of the message
\item {\em Variable Value:} The value of the MOOS variable for the message
\end{packed_itemize}

\vspace{0.1in}
\noindent
Below are a couple example messages: 

\prevgreen
\begin{verbatim}
 NODE_MESSAGE_LOCAL = src_node=abe, dest_node=ben, var_name=RETURN, string_val=true
 NODE_MESSAGE_LOCAL = src_node=eve, dest_node=fin, var_name=DIST, double_val=1984
\end{verbatim}
\postverb

\noindent
Since MOOS messages are either numerical (type double) values or
string values, the value component of a \mvar{NODE\_MESSAGE\_LOCAL}
posting has either the field \var{double\_val} or \var{string\_var}
as in the examples above.

\vspace{0.1in}
\noindent
Note that a message is sent without naming the app on the receiving
vehicle. Like any other interaction in a publish-subscribe architecture,
the receiving app receives this information only because it registered
for mail on this variable.

%=================================================================
\subsection{Messages Sent to Groups of Other Vehicles}

The sender of a message is an app that publishes the original outgoing
message \mvar{NODE\_MESSAGE\_LOCAL} as described above. It is not
uncommon for the sender to want to send the message to "everyone", or
"everyone in my group". Such designations are generally supported
in outgoing messages. 

\vspace{0.1in}
\noindent
The first of the following two messages request the message is sent to
"all" other vehicles, and the second requests that all vehicles in the
group "blue" receive the message.

\prevgreen
\begin{verbatim}
 NODE_MESSAGE_LOCAL = src_node=abe, dest_node=all, var_name=RETURN, string_val=true
 NODE_MESSAGE_LOCAL = src_node=abe, dest_group=blue, var_name=RETURN, string_val=true
\end{verbatim}
\postverb

\noindent
The questions remain:

\begin{packed_itemize}
\item What is the list of "all" vehicles or the list of vehicles in group "blue"?
\item Where does this information come from? Another app? Configuration parameters?
\item How does the message get routed to these vehicles specifically?
\end{packed_itemize}






%=================================================================
\section{The Role of pMediator}
%=================================================================

A design goal of \app{pMediator} is that it can be enabled alongside
the "normal" messaging conventions, i.e., requiring no changes to how
messages are generated by the sender, unpacked by the receiver, or
related at all to the inter-vehicle messaging medium. The design
of \app{pMediator} is described here:



%=================================================================
\subsection{The Role of pMediator in Sending Outgoing Messages}
\label{sec_pmed_outgoing}

When \app{pMediator} is used, outgoing messages generated by any app
are constructed in the usual manner, through the generation of a
\mvar{NODE\_MESSAGE\_LOCAL} publication. Rather than exporting this
message directly to other vehicles, e.g., using \app{pShare}, this
message is instead read by \app{pMediator}, as shown in Figure
\ref{fig_pmed_send_msg}. Upon receipt of \mvar{NODE\_MESSAGE\_LOCAL},
a new message is created with augmented information, by
\app{pMediator}. The new message uses the MOOS variable
\mvar{MEDIATED\_MESSAGE\_LOCAL}, and adds an ID unique to each
outgoing message. It is comprised of the source vehicle name and an
integer incremented upon each message. This mediated message (not
\mvar{NODE\_MESSAGE\_LOCAL}) is then shared offboard to the
destination node(s).


\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.88\textwidth]{figures/pmed_send_msg.png}
  \caption{{\bf Messages Sent with pMediator:} (1) The outgoing
    message is generate by the sending app as normal. (2) The original
    outgoing messaged is received by \app{pMediator}. (3) An internal
    table is augmented with the new message, assigning the message a
    unique ID field. (4) The outgoing message is replaced with
    \mvar{MEDIATED\_MESSAGE\_LOCAL}, augmented with the unique ID. (5)
    The mediated message is sent off-board to the destination
    node(s).}
  \label{fig_pmed_send_msg}
\end{figure}

\vspace{0.1in}
\noindent
A table of outgoing messages is maintained by \app{pMediator}, keyed
on the unique message identifier. For messages where an acknowledgment
return message is requested, this table is used for keeping track of
which messages have been acknowledged. The table also keeps track of
the original message content in case it needs to be re-sent. It also
holds the time since the message was last sent, for each message, to
allow control over the wait time between re-sending messages. A total
count of message sends is maintained for each message for cases where
the number of re-send attempts is limited.


\newpage

%=================================================================
\subsection{The Role of pMediator in Receiving Incoming Messages}
\label{sec_pmed_incoming}

When \app{pMediator} is used, incoming offboard messages from other
nodes arrive in the variable \mvar{MEDIATED\_MESSAGE}, perhaps via the
local \app{pShare} app or another comms medium. The only app
registering for this variable is \app{pMediator}. Upon receipt, it
will unpack the message into a \mvar{NODE\_MESSAGE}, removing any ack
information from the mediated messge. If the mediated message had
contained the field \var{ack=true}, then \app{pMediator} will also
generate a return acknowledgement message in the variable
\mvar{ACK\_MESSAGE\_LOCAL}. See Figure \ref{fig_pmed_recv_msg}.

\vspace{0.1in}
\noindent
Not all messages require an ack return message. On the sender side,
\app{pMediator} can be configured to name one or more MOOS variable
messages that do not require and acknowledgment. Regardless of whether
an ack is requested, the \var{ack\_id} field will be included in all
mediated messages. This ensures the uniqueness of each message, and
allows the receiving \app{pMediator} to ensure that no message will
be published locally twice. 


\vspace{0.1in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.95\textwidth]{figures/pmed_recv_msg.png}
  \caption{{\bf Messages Received with pMediator:} (1) The incoming
    message is received as a \mvar{MEDIATED\_MESSAGE}, to the local
    MOOSDB and received by \app{pMediator}.  (2) The mediated message
    is unpacked, removing any \var{ack} fields, to create a
    \mvar{NODE\_MESSAGE} published to the local MOOSDB.  (3) If
    \var{ack=true} was contained in the mediated message, an
    acknowledgement message is generated by the mediator to be
    delivered back to the sending node (4) via the same comms medium.
    (5) The \mvar{NODE\_MESSAGE} is unpacked by
    \app{uFldMessageHandler}, and (6) posted wit the intended MOOS
    variable and value to the local MOOSDB. (7) Finally the original
    message, \mvar{RETURN=true} is consumed by the intended app on the
    receiving node.}
  \label{fig_pmed_recv_msg}
\end{figure}

\vspace{0.1in}
\noindent
After \app{pMediator} has unpacked the mediated message and generated
and posted \mvar{NODE\_MESSAGE} to the local MOOSDB, the normal
(unmediated) inter-vehicle messaging pipeline continues. The
node message is unpacked by \app{uFldMessageHandler} and the actual
contained message is published to the local MOOSDB where presumably
some client application is waiting to receive this information.

\newpage

%=================================================================
\section{Handling Dropped Messages}
%=================================================================
\label{sec_pmed_acks}

By default, \app{pMediator} will request an acknowledgement message
for each outgoing message, indicated by the inclusion of
\var{ack=true} in the message. See Figure \ref{fig_pmed_recv_msg}.
Messages that do not received an ack message in return, may be
re-sent to the node that did not acknowledge receipt. The ack and
re-send policy has a number of configuration options. 

\vspace{0.1in}
\noindent
Note: If a message is being sent to a {\em group} of vehicles, a
distinct message is created and tracked for destination vehicle.  For
example if a message is being sent from \var{abe} to \var{ben} and
\var{cal}, two distinct ack IDs will be created, e.g., \var{abe\_123}
and \var{abe\_124}. If an ack is received from \var{ben} but not
\var{cal}, the message will be resent only to \var{cal}.

%=================================================================
\subsection{Messages that Do Not Require and Acknowledgment}

Some inter-vehicle messages may not require an
acknowledgement. Typically such messages are {\em status} messages
that are sent on a regular interval with new messages obviating old
(or dropped) messages. In this case the message variable is named
with the configuration parameter:

\prevblue
\begin{verbatim}
no_ack_vars = FUEL_STATUS, PROP_STATUS
\end{verbatim}
\postverb

\noindent
The parameter accepts a comma-separated list of MOOS variables, with
perhaps multiple configuration lines. Duplicates are simply ignored.

%=================================================================
\subsection{Setting an Upper Limit on the Number of Re-send Attempts}
\label{sec_pmed_retries}

By default, a message will be re-sent a maximum of 5 times before
giving up. This can be changed with the configuration parameter,
\pvar{max\_tries}. For example:

\prevblue
\begin{verbatim}
max_tries = 10
\end{verbatim}
\postverb

\vspace{0.1in}
\noindent
If a variable is on the \pvar{no\_ack\_vars} list, then no further
attempts to send will be made after the first attempt, and this parameter
does not apply to that variable.

%=================================================================
\subsection{Time Interval Between Re-send Attempts}
\label{sec_pmed_rthresh}

If a message is being sent with an ack requested, a re-send will be
attempted if no ack has been received after a configured interval.
The default for this interval is 2 seconds and may be customized, for
example to 5 seconds, with:

\prevblue
\begin{verbatim}
resend_thresh = 5
\end{verbatim}
\postverb

\noindent
Currently it is not possible to set the re-send interval per message
type. 


%=================================================================
\subsection{A Bare-Bones Example pMediator Configuration}

Listing \ref{lst_pmed_config} below shows a bare-bones configuration.

\vspace{0.25in}
\begin{listing}{Example bare-bones configuration of \app{pMediator}}
\label{lst_pmed_config}
\footnotesize
\begin{verbatim}
 1  ProcessConfig = pMediator
 2  {                                                               
 3    resend_thresh = 3
 4    max_tries     = 6
 5    no_ack_vars   = MUSTER_STATUS
 6    group         = blue_team
 7    mates         = deb,fin
 8  }                                                          
\end{verbatim}
\end{listing}
\normalsize
\vspace{0.1in} 


%=================================================================
\section{Configuration Parameters of pMediator}
%=================================================================
\label{sec_pmed_config_params}

The following parameters are defined for \app{pMediator}. For
some parameters, more detailed description are provided in other
sections. Parameters having default values are indicated so.

\vspace{0.15in}
\begin{listing}{Configuration Parameters for \app{pMediator}}
\label{lst_pmed_params}
\renewcommand{\arraystretch}{1.1}
\begin{longtable}{rp{0.69\textwidth}} 

  \pvar{vname}: &amp; The name of ownship. This will be used in creating
  the \var{ack\_id} field in outgoing mediated
  messages. \ref{sec_pmed_outgoing} \\ 

  \pvar{no\_ack\_vars}: &amp; A comma-separted list of outgoing message
  variables that will not request an acknowledgement return message.
  A fire-and-forget policy. \\

  \pvar{no\_ack\_var}: &amp; Same as \pvar{no\_ack\_vars}, but typically
  only containing one variable. \\

  \pvar{group}: &amp; Name of the ownship group. \\
  
  \pvar{resend\_thresh}: &amp; Time between re-send attempts unless an
  ack message has been received. Section \ref{sec_pmed_rthresh}. \\

  \pvar{max\_tries}: &amp; Number of times a variable will be re-sent
  before an ack has been received until giving up. Section
  \ref{sec_pmed_retries}. \\

  \pvar{mates}: &amp; An explicit list of vehicle names to be considered
  part of our group. Section \ref{sec_pmed_mates}. \\

  \pvar{mate}: &amp; Same as \pvar{mates}, but typically containing only
  vehicle name when using this parameter. 

\end{longtable}
\end{listing}


%=================================================================
\section{Publications and Subscriptions for uFldObstacleSim}
%=================================================================
\index{pMediator!Publications and Subscriptions}
\index{Publications and Subscriptions!pMediator}
\label{sec_pmed_interface}

The interface for \app{pMeditor}, in terms of publications and
subscriptions, is described below. This same information may also be
obtained from the terminal with:

\vspace{0.1in}
\begin{consoleverb}
 $ pMediator --interface or -i
\end{consoleverb}
\vspace{0.05in}

%=================================================================
\subsection{Variables Published by pMediator}
\label{sec_pmed_pubs}

\begin{packed_itemize}[2]
\item \mvar{APPCAST}: Contains an appcast report identical to the
  terminal output. Appcasts are posted only after an appcast request
  is received from an appcast viewing utility. Section
  \ref{sec_pmed_appcast}

\item \mvar{ACK\_MESSAGE\_LOCAL}: For incoming mediated messages
  requesting an acknowledgement return message, this variable is
  posted to contain the acknowledgment.

\item \mvar{NODE\_MESSAGE}: For incoming mediated messages, the
  contained node message will be republished locally in this variable.

\item \mvar{MEDIATED\_MESSAGE\_LOCAL}: For outgoing node messages. The
  original node message will be packed in this message. Section
  \ref{sec_pmed_outgoing}.

\item \mvar{BCM\_REPORT\_REQUEST}: Posted upon startup, this messages
  requests from the contact manager a list of vehicles with 10K range.

\end{packed_itemize}

\noindent
Example postings:

\prevgreen
\begin{verbatim}
 MEDIATED_MESSAGE_LOCAL = ack_id=abe_007,ack=true,src_node=abe,dest_node=ben,
                          var_name=RETURN,string_val=true

     ACK_MESSAGE_LOCAL  = id=abe_007,src=abe,dest=ben 

           NODE_MESSAGE = src_node=abe,dest_node=ben, var_name=RETURN,
                          string_val=true

     BCM_REPORT_REQUEST = var=MEDIATED_GROUP_10K, range=10000
\end{verbatim}
\postverb

%=================================================================
\subsection{Variables Subscribed for by pMediator}
\label{sec_pmed_subs}

The \app{uFldObstcleSim} application will subscribe for the following
MOOS variables:

\begin{packed_itemize}
\item \mvar{APPCAST\_REQ}: A request to generate and post a new
  apppcast report, with reporting criteria, and expiration. 
\item \mvar{NODE\_MESSAGE\_LOCAL}: When \app{pMediator} handles
  outgoing node messages, it looks for publications to this variable.
\item \mvar{MEDIATED\_MESSAGE}: When \app{pMediator} handles incoming
  messages, these messages arrive in this variable.
\item \mvar{ACK\_MESSAGE}: Incoming acknowledgements of previously
  sent messages.
\item \mvar{MEDIATE\_GROUP\_10K}: A report from the contact manager
  listing the names of all vehicles in our group with ten kilometers.
  This variable can be configured or disabled. Section \ref{pmed_grp}.
  
\end{packed_itemize}

\noindent
Example postings:

\prevgreen
\begin{verbatim}
 NODE_MESSAGE_LOCAL = src_node=abe,dest_node=ben,var_name=RETURN,
                      string_val=true
   MEDIATED_MESSAGE = ack_id=abe_007,ack=true,src_node=abe,dest_node=ben,
                      var_name=RETURN,string_val=true
        ACK_MESSAGE = id=abe_007,src=abe,dest=ben 
 MEDIATED_GROUP_10K = abe,ben,deb
\end{verbatim}
\postverb

%=================================================================
\section{Terminal and AppCast Output}
%=================================================================
\label{sec_pmed_appcast}

The \app{pMediator} application produces some useful information to
the terminal and identical content through appcasting. An example is
shown in Listing \ref{lst_pmed_appcast} below.

On line 2, the name of
the local community, typically the shoreside community, is listed on
the left. On the right, \var{"0/0(1582)} indicates there are no
configuration or run warnings, and the current iteration of
\app{pMediator} is 1582. Lines 4-9 show the configuration settings.
On Line 7, the list of named mates is empty, which means the list
of mates on line 8, were inferred from an incoming message from
the contact manager, identifying the teammates \var{ben}, \var{cal},
and \var{deb}.

\vspace{0.1in}
\noindent
Lines 11-13 provide an overall recap on total messages sent to all
other vehicle for all message types (MOOS variables). Note that
the total number of messages sent exceeds the number of acknowledgement
messages received in return, indicating there is significant lossy
comms at play.

\vspace{0.1in}
\noindent
Lines 15-17 summarize the incoming message count from all vehicles, for
all message types (MOOS variables). A bad message is one that is
improperly formed or missing required fields.

\vspace{0.1in}
\noindent
Lines 19-26 provide outgoing message statistics {\em per
  vehicle}. Note the total messages sent in the second column is 114,
the same total number given oin line 12. Note that comms from
\var{abe} to \var{deb} seems to result in far fewer messages requiring
a re-send. Column five shows the average time for a message to be
sent and received {\em on the first try}. This value may be useful in
setting the configuration parameter \pvar{resend\_thresh}, discussed
in Section \ref{sec_pmed_rthresh}.

\vspace{0.1in}
\noindent
The output in lines 24-26 in column six is the most direct confirmation
that no messages have been lost, even though a re-send was required
in several instances.


\vspace{0.2in}
\begin{listing}{Example \app{UFldObstacleSim} console output}
\label{lst_pmed_appcast}
\footnotesize
\begin{verbatim}
 1  ================================================================
 2  pMediator abe                                          0/0(1582)
 3  ================================================================
 4  Config:                             
 5    ReSend thresh: 3
 6        Max Tries: 6
 7      Named mates: 
 8            mates: ben,cal,deb
 9      No_ack_vars: CONVOY_STAT_RECAP_ALLY
10  
11  Stats (outgoing):                  
12    Out Msg Count: 114
13    Ack Msg Count: 66
14  
15  Stats (incoming):                  
16    Rcv Msg Count: 107
17    Bad Msg Count: 0
18  
19  Outgoing stats: (0)
20  ----------------------------
21        Msgs  Msgs     Avg Msgs  Avg First  Msgs
22  Mate  Sent  Re-Sent  Re-Sent   Interval   Dropped
23  ----  ----  -------  --------  ---------  -------
24  ben   39    11       0.282     1.821      0
25  cal   36    12       0.333     1.799      0
26  deb   39    1        0.026     1.672      0
27  
28  Outgoing stats: (Per Variable)
29  ------------------------------
30  Snds  ReSnds  Freq  Var                     Dest(s)
31  ----  ------  ----  ----------------------  -----------
32  48    0*      6.95  CONVOY_STAT_RECAP_ALLY  ben,cal,deb
33  6     1       1.37  MUSTER                  ben,cal,deb
34  36    11      5.91  MUSTER_COLLAB           ben,cal,deb
35  18    9       2.49  TASK_BID                ben,cal,deb
36  6     3       1.37  UP_MUSTER               ben,cal,deb
37  
38  Incoming stats: 
39  ----------------------------
40        Acks  Acks     Avg Acks
41  Mate  Sent  Re-sent  Re-sent
42  ----  ----  -------  --------
43  ben   27    1        0.037
44  cal   31    4        0.129
45  deb   35    9        0.257
46  
47  ================================================================
48  Most Recent Events (8):
49  ================================================================
50  [424.82]: Completed msg id: [abe_107], elapsed=1.705
51  [418.54]: Completed msg id: [abe_105], elapsed=4.562
52  [416.01]: Completed msg id: [abe_106], elapsed=2.03
53  [405.94]: Completed msg id: [abe_104], elapsed=1.752
54  [405.94]: Completed msg id: [abe_103], elapsed=1.752
55  [405.36]: Completed msg id: [abe_102], elapsed=1.174
56  [395.36]: Completed msg id: [abe_96], elapsed=8.266
57  [389.05]: Completed msg id: [abe_97], elapsed=1.957
\end{verbatim}
\end{listing}
\normalsize

\vspace{0.1in}
\noindent
In Lines 28-36, a summary of statistics is shown sorted on the
message type (MOOS variable). In the first column the total
attempted sends is given, followed by the number of re-sends that
were needed. (If \pvar{max\_tries=5} then column two can be at most
five times greater than column one.) The frequency value shown in
column three is {\em sends per minute}. The frequency calculation
does {\em not} include re-sends. In other words, the frequency value
will be unchanged under perfect or lossy comms since it only counts
the initial attempted send for each unique inter-vehicle message.
Not the asterisk in column 2 of line 32. This indicates that the
zero re-sends value is due to this variable being on the
\pvar{no\_ack\_vars} list.

\vspace{0.1in}
\noindent
Lines 38-45 summarize the acks sent to other vehicles upon incoming
messages. Column one is the name of the vehicle to which the ack is
sent. Column two is the number of acks that needed to be sent (one per
incoming unique message), and column three is the number of additional
acks that needed to be sent. Recall that re-sending an ack is
triggered by the original message arriving as a re-send. 


%=================================================================
\section{Implementation Notes}
%=================================================================

o The NodeMessage class is in \var{lib\_mbutil}. The serialization
functions for converting to a string and unpacking from a string
are defined on this class. There is no MediatedMessage class. The
NodeMessage class also serves this purpose and had two additional
fields, the ack id, and the ack=bool fields. They are simply unused
and not serialized if they have not been set.


\end{document}

</pre></body></html>