woshihuangrulin / openjaus Goto Github PK

What is the issue?

Eliminate the use of the custom component interface. Components should
check in/out and query the NM via the regular JUDP loopback interface.
Generate new JAUS messages / protocol and submit to working group for review. 

What is the issue?

This defect causes NodeManagerComponent? not to create a report
configuration for query configuration messages with a subsystem query.

NodeManagerComponent??.cpp, Line 1319.

The following line;

    jausAddressCopy(txMessage->destination, reportConf->source);

should be corrected as;

    jausAddressCopy(txMessage->destination, queryConf->source);

What is the issue?

Hi - I've been having some issues with the latest release of OpenJAUS (3.3)
on Mac OS X 10.5. The issues mainly deal with the static Makefiles included
in the release, so I replaced it with xCode project files, the default IDE
on Mac OS X. I don't know if anyone is currently using Mac OS X to develop
OpenJAUS - if there are, then this might be of some interest to you. 

What is the issue?

queryVksObjectsMessage.c line:146 line:302 line:442

the incorrect bit is being used on these lines VKS_PV_QUERY_OBJECTS_REGION_BIT

it should be this bit instead VKS_PV_QUERY_OBJECTS_BUFFER_BIT 

What is the issue?
A bug in my ready state callback caused it to take longer then the update
interval of the component. As a result, every call to
nodeManagerTimedReceive was passed a calculated timeLimitSec that was less
than ojGetTimeSec(). nodeManagerTimedReceive would always return
NMI_RECEIVE_TIMED_OUT, and the component stopped receiving messages from
it's queue.

Obviously, I shouldn't be doing something that time consuming in a ready
state callback. But it makes me wonder if this is the desired behavior of
nodeManagerTimedRecieve. Would it make more sense for
nodeManagerTimedRecieve to first check the queue size and return a message
if it is nonzero first, and then go ahead and check the timeout value?
Basically reverse the order of the two conditionals to ensure it returns a
message if one exists.

reported by jpulver 06/11/09 11:40:35 

What is the issue?
The JAUS_EXPORT define is missing from the jausInteger.h header in front of
the jausIntegerToBuffer function. 

What is the issue?
Need to include for ack/nak responses in node manger and node manger
interface. These services should nak if at any point in the routing process
there is a problem. This feature should also be user controlled with at
least a simple enable/disable config. 

What is the issue?

Hi,

I coded this small patch for an easier management of the config file. It
works as follows:

   1. if you give a path as an argument, then it takes this path as the
configuration file for the node manager
   2. otherwise:
         1. check if you have a nodeManager.conf file in the current directory
         2. if not load the file from a standard repository (this should be
changed to a coherent directory) 

Cheers,

Ugo 

What is the issue?

There is a typo in the scManagerReceiveServiceConnection() function in the
scManager.c file at line 959. The mutex is never locked in this function.

pthread_mutex_unlock(&nmi->scm->mutex);

should be:

pthread_mutex_lock(&nmi->scm->mutex); 

What is the issue?

Need to go through all the new C/C++ code and document it using the doxygen
style of code comments. This will allow us to generate better documentation
of the code for our users. 

What is the issue?
deleteVksObjectsMessage.c
line 113
JAUS_BYTE_SIZE_BYTES should be JAUS_UNSIGNED_SHORT_SIZE_BYTES

line 138, line 289, line 423
VKS_PV_DELETE_OBJECTS_REGION_BIT should be VKS_PV_DELETE_OBJECTS_BUFFER_BIT 

What is the issue?

There is a return in the run() method of OjUdpComponentInterface? if the
componentId is out of range. The return should be changed to a break.

A single event is generated, and the node manager no longer receives local
component connections: ERROR (virtual void
OjUdpComponentInterface::run():219): Invalid Component Id (0) trying to
check in. 

What is the issue?

In jausCommandValueFromBuffer, case TYPE_CODE_STRING, the buffer pointer
needs to move after reading the string length from the buffer. (buffer +=
JAUS_UNSIGNED_SHORT_SIZE_BYTES;)

In jausCommandValueToBuffer, case TYPE_CODE_STRING, the buffer pointer
needs to move after writing the string length to the buffer. (buffer +=
JAUS_UNSIGNED_SHORT_SIZE_BYTES;)

The bug is also present in jausInformationValueFromBuffer and
jausInformationValueToBuffer 

What is the issue?
The following cases are missing from the jausCommandCodeString() function.

    case JAUS_QUERY_MISSION_STATUS:

        return "JAUS_QUERY_MISSION_STATUS";

    case JAUS_QUERY_SPOOLING_PREFERENCE:

        return "JAUS_QUERY_SPOOLING_PREFERENCE";

    case JAUS_QUERY_SUBSYSTEM_LIST:

        return "JAUS_QUERY_SUBSYSTEM_LIST";

    case JAUS_REPORT_MISSION_STATUS:

        return "JAUS_REPORT_MISSION_STATUS";

    case JAUS_REPORT_SPOOLING_PREFERENCE:

        return "JAUS_REPORT_SPOOLING_PREFERENCE";

    case JAUS_REPORT_VKS_DATA_TRANSFER_TERMINATION:

        return "JAUS_REPORT_VKS_DATA_TRANSFER_TERMINATION";

    case JAUS_REPORT_SUBSYSTEM_LIST:

        return "JAUS_REPORT_SUBSYSTEM_LIST:";

    case JAUS_SET_SELECTED_DATA_LINK_STATE:

        return "JAUS_SET_SELECTED_DATA_LINK_STATE";

    case JAUS_SET_VELOCITY_STATE:

        return "JAUS_SET_VELOCITY_STATE";

    case JAUS_RUN_MISSION:

        return "JAUS_RUN_MISSION";

    case JAUS_ABORT_MISSION:

        return "JAUS_ABORT_MISSION";

    case JAUS_SPOOL_MISSION:

        return "JAUS_SPOOL_MISSION";

    case JAUS_REPLACE_MESSAGES:

        return "JAUS_REPLACE_MESSAGES";

    case JAUS_RESUME_MISSION:

        return "JAUS_RESUME_MISSION";

    case JAUS_PAUSE_MISSION:

        return "JAUS_PAUSE_MISSION";

    case JAUS_REMOVE_MESSAGES:

        return "JAUS_REMOVE_MESSAGES";

    case JAUS_SET_VKS_FEATURE_CLASS_METADATA:

        return "JAUS_SET_VKS_FEATURE_CLASS_METADATA";

    case JAUS_TERMINATE_VKS_DATA_TRANSFER:

        return "JAUS_TERMINATE_VKS_DATA_TRANSFER";

What is the issue?

Need to change message to use temp variables while unpacking 

What is the issue?

To better support development, it would be advantageous to add a toString
style function to all message structures and other data structures. 

The OpenJAUS logo in the header should link back to the Home page.

The background color does not blend properly into the background image.

What is the issue?

Add a command line interface to the ojNodeManager. Include new commands and
options in the node manager that will improve usability and usefulness.

What is the issue?
In the SetCameraCapabilities.c file, the
JAUS_SET_CAMERA_CAPABILITIES_PV_FRAME_RATE_BIT bit is used improperly to
control the packing and unpacking of the ShutterSpeed, ImageControl, and
AudioControl fields. This error repeats in dataFromBuffer, dataToBuffer,
dataToString and dataSize. 

What is the issue?
While cloning the individual components in SystemTree::replaceSubsystem,
the node identification string is being copied into each components
identification string. This could cause the bug described in closed Ticket
#52 as well.

    Change the line that reads

        sprintf(cloneCmpt->identification, "%s", currentNode->identification);

    to

        sprintf(cloneCmpt->identification, "%s", currentCmpt->identification);

On Windows, compiled witH MSVC2008 or MSVC2005, this bug will cause heap
error dialogs to appear periodically if the node identification string is
longer then the component identification string. On Linux, I think this is
responsible for a segmentation fault that occurred on an ojNodeManager when
I stopped an ojVehicleSim on another subsystem. 

What is the issue?
It seems that when extremely large messages are sent (~100k) message loss
starts to occur. At ~100k we are talking ~25 different messages/packets
that are needed to send the 1 message. It appears that the send is too fast
for the receiver to handle and maybe there is a buffer overflow problem and
the additional messages are lost? If I slow down the send by putting a
sleep between each send in largeMessageHandlerSend() then the problem
starts occurring with larger messages. Maybe threading the
largeMessageHandler will alleviate this problem as it will lessen the time
between pulling datagram packets off the socket. There is probably no way
to completely fix this problem without some sort of rate/flow control but
it would be nice to quantify the limit when the problem will occur.

I am running the code under Ubuntu 8.04, all on the same machine with only
component communication enabled. 

What should we do about it?

Please address in next design cycle

What is the issue?
The use of Bit Fields in JausMessage? to define the properties will not
provide a predictable bit packing. The result will depend upon both the
operating system, processor, AND compiler.

The following code has not been tested, but should be enough to convey the
general approach to getting a platform neutral packing algorithm.

    quint16 properties = 0;
    // start at bit 0                                                     

    quint16 priority = m_properties.priority;                             

    // start at bit 4                                                     

    quint16 ackNak   = (m_properties.ackNak << 4);                        

    // start at bit 6                                                     

    quint16 scFlag   = (m_properties.scFlag << 6);                        

    // start at bit 7                                                     

    quint16 expFlag  = (m_properties.expFlag << 7);                       

    // start at bit 8                                                     

    quint16 version  = (m_properties.version << 8);                       

    // start at bit 14                                                    

    quint16 reserved = (m_properties.reserved << 14);                     


    properties = priority | ackNak | scFlag | expFlag | version | reserved;   

    // then copy properties directly without swapping bytes


To read the data back

    quint16 properties; // raw data

    m_properties.priority = properties & 0x000F;
    m_properties.ackNak   = (properties >> 4)  & 0x0003;
    m_properties.scFlag   = (properties >> 6)  & 0x0001;
    m_properties.expFlag  = (properties >> 7)  & 0x0001;
    m_properties.version  = (properties >> 8)  & 0x0063;
    m_properties.reserved = (properties >> 14) & 0x0003;

What is the issue?

HTML API documentation has already been generated, this needs to be made
available online. 

What is the issue?
Error in the rendering of the main menu element on OJ.com (see file)

What should we do about it?
Figure out what is causing this...

What is the issue?
The OpenJAUS framework supplies support for the core messages as service
connections, however support for the JAUS_REPORT_COMPONENT_CONTROL message
is not provided.

What should we do about it?
Add support to the nodeManagerSendCoreServiceConnections() function for the
service connection. Patch for this against the 3.3.0b branch is attached.

What version of OpenJAUS are you using?
v3.3.0b (I see the problem still exists in trunk as well)

What is your system setup? (OS, Mutli/Single Subsystem, Multi/Single Node,
etc...)
Multi Subsystem, Multi Node

Please provide any additional information below:
In the SystemTree class there are 3 places that could call strlen(NULL) and 
segmentation fault. I noticed the problem while debugging a multiple node, 
multiple subsystem setup.  A report configuration (NODE) arrived before the 
report identification (NODE), and I segfaulted in call to replaceNode.  

In SystemTree::replaceNode (trunk line 1450)
  -- need to add an if (currentNode->identification) check before the 
cloning the identification

In SystemTree::getSubsystemIdentification (trunk line 1567)
  -- should be if (subs && subs->identification)

In SystemTree::getNodeIdentification (trunk line 1594)
  -- should be if (node && node->identification)

What is the issue?
The dataDestroy method of set / query / report PayloadDataElementMessage?
fails to free memory allocated for the indexes buffer. There's a ! symbol
in there that should be removed.

    Change:

        if (!message->indexes) free(messages->indexes)

    To:

        if (message->indexes) free(messages->indexes)

Excerpt:

...
// Test if objectCount is specified
if(jausByteIsBitSet(message->presenceVector, VKS_PV_QUERY_OBJECTS_ID_BIT))
{
  // Request Id
  if(!jausUnsignedShortFromBuffer(&message->objectCount, buffer+index,
bufferSizeBytes-index)) return JAUS_FALSE;
    index += JAUS_BYTE_SIZE_BYTES;
...

Should be:
    index += JAUS_UNSIGNED_SHORT_SIZE_BYTES;

What is the issue?
Build hooks into the Node Manager (probably at the transport layer) to
support discovery of other JAUS nodes and Subsystems across the internet. 

What is the issue?
When a set state message is received (e.g. standbyMessage, resetMessage,
resumeMessage), the defaultJausMessageProcessorNoDestroy function updates
ojCmpt->jaus->state only (and not ojCmpt->state). This is a problem because
the callback's function upon change state are determined according to
ojCmpt->state. 

Browser: Firefox 3.5.3
When clicking on the OJ DevCon banner, there appears a faint box around the
whole header area, this does not appear in the previous default template.

Browser: IE
In IE, the behavior is similar, but different. Here the box shows up, but
only around the smaller banner graphic.

What is the issue?

In reportEventMessage.h there are extra * in reportEventMessageStruct's
data members.

JausByte *presenceVector;
JausUnsignedShort *messageCode;
JausByte *eventType;
JausByte *eventBoundary;
JausByte *limitDataField;
JausEventLimit *lowerLimit;
JausEventLimit *upperLimit;
JausEventLimit *stateLimit;
JausByte *eventId;
JausMessage *queryMessage;

Instead of:

JausByte presenceVector;
JausUnsignedShort messageCode;
JausByte eventType;
JausByte eventBoundary;
JausByte limitDataField;
JausEventLimit lowerLimit;
JausEventLimit upperLimit;
JausEventLimit stateLimit;
JausByte eventId;
JausMessage queryMessage;

What is the issue?

In multicastSocketRecv it is possible to loose packets if both a unicast
and multicast packet are received at the same time. 

What is the issue?
When setting the defaultValue of a Double or Float in the fields2cpp
package, the value output into the generated code is incorrect.

For example, the Double value "17356.387876" is output as "17,356.387"

What should we do about it?
Write our own function to transform the Double and Float values to the
proper character strings.

What is the issue?
We have about 5 different fonts currently on the new website. We should get
this down to probably two: 1 with serif that looks like the OJ logo and one
that is sans-serif.

What is the issue?

In CommunicatorComponent::sendSubsystemChangedEvents the memory for
txMessage is allcoated inside a loop ( txMessage =
eventMessageToJausMessage(eventMessage); ) and freed outside the loop (
jausMessageDestroy(txMessage); ).

If the loop runs through multiple iterations, only the final alloc will get
freed. Move the call jausMessageDestroy(txMessage) to the bottom of the loop.

This bug / memory leak is present in the following locations

CommunicatorComponent::sendSubsystemChangedEvents()
CommunicatorComponent::sendSubsystemShutdownEvents()
NodeManagerComponent::sendSubsystemChangedEvents()
NodeManagerComponent::sendSubsystemShutdownEvents()
NodeManagerComponent::sendNodeChangedEvents()
NodeManagerComponent::sendNodeShutdownEvents() 

What is the issue?
The report image data buffer memory needs to be allocated prior to the
memcpy operation that stores the data. The allocated buffer also needs to
be destroyed in the dataDestroy function. 

What is the issue?
While porting OpenJaus? to QNX I found the following problem:

In the function nodeManagerTimedReceive in nodeManagerInterface.c a mutex
is created locally. However pthread_mutex_destroy() is not called on this
mutex before the routine exits.

This causes a leak of system resources under QNX until the
pthread_mutex_lock() and pthread_cond_timedwait() calls fail.

The fix is to add a pthread_mutex_destroy() call before every return statement.

If anyone is interested in the QNX port of the code I can provide the list
of changes to the Makefiles and source code.

Tim 

What is the issue?
We need an email account that can forward [email protected] to us.

The Set Joint Motions message needs this patch:

// Destructs the message-specific fields
static void dataDestroy(SetJointMotionMessage message)
{
    int pose;

    // Free message fields
    if(message->poseTime != NULL)
    {
        free(message->poseTime);
    }

    if(message->position != NULL)
    {
        for(pose=0; pose<message->numPoses; pose++)
        {
            free(message->position[pose]);
        }

        free(message->position);
    }

    if(message->maxVelocity != NULL)
    {
        for(pose=0; pose<message->numPoses; pose++)
        {
            free(message->maxVelocity[pose]);
        }

        free(message->maxVelocity);
    }

    if(message->maxAcceleration != NULL)
    {
        for(pose=0; pose<message->numPoses; pose++)
        {
            free(message->maxAcceleration[pose]);
        }

        free(message->maxAcceleration);
    }

    if(message->maxDeceleration != NULL)
    {
        for(pose=0; pose<message->numPoses; pose++)
        {
            free(message->maxDeceleration[pose]);
        }

        free(message->maxDeceleration);
    }

}

// Return boolean of success
static JausBoolean dataFromBuffer(SetJointMotionMessage message, unsigned 
char *buffer, unsigned int bufferSizeBytes)
{
    int index = 0;
    int pose;
    int joint;
    JausUnsignedInteger tempUInt;

    if(bufferSizeBytes == message->dataSize)
    {
        // Unpack Message Fields from Buffer

        if(!jausByteFromBuffer(&message->numJoints, buffer+index, 
bufferSizeBytes-index)) return JAUS_FALSE;
        index += JAUS_BYTE_SIZE_BYTES;

        if(!jausByteFromBuffer(&message->numPoses, buffer+index, 
bufferSizeBytes-index)) return JAUS_FALSE;
        index += JAUS_BYTE_SIZE_BYTES;

        message->poseTime = (JausDouble 
*)malloc(sizeof(JausDouble)*message->numPoses);
        message->position = (JausDouble 
**)malloc(sizeof(JausDouble*) * message->numPoses);
        message->maxVelocity = (JausDouble 
**)malloc(sizeof(JausDouble*) * message->numPoses);
        message->maxAcceleration = (JausDouble 
**)malloc(sizeof(JausDouble*) * message->numPoses);
        message->maxDeceleration = (JausDouble 
**)malloc(sizeof(JausDouble*) * message->numPoses);

        for(pose=0; pose<message->numPoses; pose++)
        {
            if(!jausUnsignedIntegerFromBuffer(&tempUInt, 
buffer+index, bufferSizeBytes-index)) return JAUS_FALSE;
            index += JAUS_UNSIGNED_INTEGER_SIZE_BYTES;
            message->poseTime[pose] = 
jausUnsignedIntegerToDouble(tempUInt, 0, 6000);

            message->position[pose] = (JausDouble 
*)malloc(sizeof(JausDouble) * message->numJoints);
            message->maxVelocity[pose] = (JausDouble 
*)malloc(sizeof(JausDouble) * message->numJoints);
            message->maxAcceleration[pose] = (JausDouble 
*)malloc(sizeof(JausDouble) * message->numJoints);
            message->maxDeceleration[pose] = (JausDouble 
*)malloc(sizeof(JausDouble) * message->numJoints);

            for(joint=0; joint<message->numJoints; joint++)
            {

if(!jausUnsignedIntegerFromBuffer(&tempUInt, buffer+index, bufferSizeBytes-
index)) return JAUS_FALSE;
                index += JAUS_UNSIGNED_INTEGER_SIZE_BYTES;
                message->position[pose][joint] = 
jausUnsignedIntegerToDouble(tempUInt, -8*JAUS_PI, 8*JAUS_PI);


if(!jausUnsignedIntegerFromBuffer(&tempUInt, buffer+index, bufferSizeBytes-
index)) return JAUS_FALSE;
                index += JAUS_UNSIGNED_INTEGER_SIZE_BYTES;
                message->maxVelocity[pose][joint] = 
jausUnsignedIntegerToDouble(tempUInt, -10*JAUS_PI, 10*JAUS_PI);


if(!jausUnsignedIntegerFromBuffer(&tempUInt, buffer+index, bufferSizeBytes-
index)) return JAUS_FALSE;
                index += JAUS_UNSIGNED_INTEGER_SIZE_BYTES;
                message->maxAcceleration[pose][joint] = 
jausUnsignedIntegerToDouble(tempUInt, -10*JAUS_PI, 10*JAUS_PI);


if(!jausUnsignedIntegerFromBuffer(&tempUInt, buffer+index, bufferSizeBytes-
index)) return JAUS_FALSE;
                index += JAUS_UNSIGNED_INTEGER_SIZE_BYTES;
                message->maxDeceleration[pose][joint] = 
jausUnsignedIntegerToDouble(tempUInt, -10*JAUS_PI, 10*JAUS_PI);

            }
        }

        return JAUS_TRUE;
    }
    else
    {
        return JAUS_FALSE;
    }
}

What is the issue?
56  56          ReleaseComponentControlMessage releaseComponentControl; 
57  57          RejectComponentControlMessage rejectComponentControl; 
58  58          ConfirmComponentControlMessage confirmComponentControl; 
    59          ReportComponentControlMessage reportComponentControl; 
59  60          ReportComponentAuthorityMessage reportComponentAuthority; 
60  61          ReportComponentStatusMessage reportComponentStatus; 
61  62          ReportIdentificationMessage reportIdentification; 
… …  
242 243                         } 
243 244                         break; 
244 245  
    246                 case JAUS_QUERY_COMPONENT_CONTROL: 
    247                         reportComponentControl =
reportComponentControlMessageCreate(); 
    248                         if(reportComponentControl) 
    249                         { 
    250                                 if(cmpt->controller.address) 
    251                                 { 
    252                                        
reportComponentControl->subsystemId = cmpt->controller.address->subsystem; 
    253                                        
reportComponentControl->nodeId = cmpt->controller.address->node; 
    254                                        
reportComponentControl->componentId = cmpt->controller.address->component; 
    255                                        
reportComponentControl->instanceId = cmpt->controller.address->instance; 
    256                                 } 
    257                                 else 
    258                                 { 
    259                                        
reportComponentControl->subsystemId = 0; 
    260                                        
reportComponentControl->nodeId = 0; 
    261                                        
reportComponentControl->componentId = 0; 
    262                                        
reportComponentControl->instanceId = 0; 
    263                                 } 
    264                                 reportComponentControl->authorityCode
= cmpt->controller.authority; 
    265  
    266                                
jausAddressCopy(reportComponentControl->source, cmpt->address); 
    267                                
jausAddressCopy(reportComponentControl->destination, message->source); 
    268  
    269                                 txMessage =
reportComponentControlMessageToJausMessage(reportComponentControl); 
    270                                 nodeManagerSend(nmi, txMessage); 
    271                                 jausMessageDestroy(txMessage); 
    272  
    273                                
reportComponentControlMessageDestroy(reportComponentControl); 
    274                         } 
    275                         break; 
    276  
245 277                 case JAUS_CONFIRM_SERVICE_CONNECTION: 
246 278                         confScMsg =
confirmServiceConnectionMessageFromJausMessage(message); 
247 279                         if(confScMsg) 

What is the issue?

Occasionally when starting the ojNodeManager project all components would
timeout and would not be able to communicate with each other. I tracked the
problem down to the interfaceMap in JausComponentCommunicationManager?.cpp.
Addresses are being adding to this from at least two threads and
occasionally these additions occur simultaneously and corrupt the map. I
added a mutex around the inserts and reads of this map and my startup
problem are now resolved. 

What is the issue?

File: reportPayloadDataElementMessage.c/.h

Details:

    In the procedure dataFromBuffer in the .c file, the
jausPayloadInterface field is used to move the received data for the
payload data element into the associated information interface. However,
when dataFromBuffer is called from the procedure
reportPayloadDataElementMessageFromJausMessage, the user does not have the
opportunity to initialise this field as the reportPayloadDataElementMessage
is created within the reportPayloadDataElementMessageFromJausMessage
procedure. Thus, a means to initialise this field must be supplied.

Suggested Changes:

    1) Change Interface. Add parameter JausPayloadInterface?
jausPayloadInterface.

    2) Add initialisation of message->jausPayloadInterface from
jausPayloadInterface prior to call to dataFromBuffer.

NOTE:

    This update is not required in the
reportPayloadDataElementMessageFromBuffer because the user creates the
ReportPayloadDataElementMessage? structure prior to calling that procedure
and so has the opportunity to initialise said field beforehand.

What is the issue?
While unpacking an Event Message, the report message destination address is
never set. The source address is copied twice.

In eventMessage.c dataFromBuffer, the lines that read:

    if(!jausAddressCopy(message->reportMessage->source, message->source))
return JAUS_FALSE;

    if(!jausAddressCopy(message->reportMessage->source, message->source))
return JAUS_FALSE;

should probably read:

    if(!jausAddressCopy(message->reportMessage->source, message->source))
return JAUS_FALSE;

    if(!jausAddressCopy(message->reportMessage->destination,
message->destination)) return JAUS_FALSE;

[deleted issue]

What is the issue?

Problem 1 - Writing to unallocated memory ¶

The call to unpack a JAUS_REPORT_PAYLOAD_INTERFACE_MESSAGE writes to
unallocated memory. The structure variable message->jausPayloadInterface is
never allocated, but dataFromBuffer tries to write to it. This is similar
to how the unpack of a REPORT_IMAGE message never allocates memory for the
image data. A simple solution is to allocate the memory in the
dataFromBuffer function (or in reportPayloadInterfaceFromJausMessage before
calling dataFromBuffer), but this leads to the question of who's
responsibility is it to free that memory (ie, should it be freed in
dataDestroy?).

I chose to allocate the memory for the jausPayloadInterface in the
dataFromBuffer call, and the caller of this function needs to free the
memory for the payload interface when they are done with it. Most likely
when they call reportPayloadInterfaceMessageDestroy.
Problem 2 - strncpy error ¶

The strncpy calls in dataFromBuffer are writing past the end of the
identifierString buffer. The value len+1, should be passed as the third
parameter, not bufferSizeBytes-index (looks like a copy and paste error
while changing dataToBuffer into dataFromBuffer). This bug appears twice.
First in unpacking the command elements identifierString, and again in
unpacking the information elements indentifierString.

Fixing problem 2 leads to another memory question. The identifier string
memory is allocated here in the dataFromBuffer method, but that memory is
never freed. Should the memory be freed in the jausCommandInterfaceDestroy
and jausInformationInterfaceDestroy?

Another suggestion. There are 4 strcpy that can be easily switched to
strncpys. They are for dealing with the enumeration strings. 

What is the issue?
The nodeManagerGetComponentAddressList() method does not actually return an 
address list but instead always returns the first address that is found in
the system tree. There is no guarantee where this component will exist
(different subsystem, different node, different instance). The function
should return a complete list addresses for matching components on the system.

What should we do about it?
Requires updates to the nodeManager interface messages which can now be of
variable length. Not sure the best approach to resolving this issue.

What is the issue?
It is not possible to create a SC to a different subsystem. If a subsystem
is specified no SC will ever be created because the
scManagerCreateServiceConnection method sees the sc->address->subsystem
value as non-zero and attempts to send the CreateServiceConnectionMessage
although the address is not valid.
If the subsystem is not specified the code forces the SC to be from the
same subsystem.

What should we do about it?
Update the scManager.c : scManagerCreateServiceConnection method to check
for a valid jaus address instead of just a value for the subsystem octet.
Change the lookup code to allow look up on a different subsystem. Users can
still limit the lookup to be on their subsystem by setting the
sc->address->subsystem value but it also allows for SCs across subsystems.
Most users probably don't use subsystem to subsystem communication and will
not be affected by this change. Attached is the method with the suggested
updates.

What is the issue?

NodeManager should have an option to run as a service or daemon in the
background. It's basically an operating system facility for doing JAUS.

If NodeManager is still in Java, we should look at either:

    * Apache's Daemon, or
    * Java Service Wrapper