HTTP VIM Server: XSystem.connect() robustification

[Mike A]

I have been helping out a company experiencing some problems
connecting from the C XAM Library to the Reference VIM using the HTTP
VIM Stack. During the process of looking at logs, we found that the
HTTP C VIM being used is horribly broken and is sending malformed
initialization field information to the HTTP VIM Server. When these
malformed strings are passed over, the HTTP VIM Server barfs with a
ConnectException( 1025 ) and fails the connect. This is a fatal
error.

Since this made debugging difficult, I modified the HTTP VIM Server to
treat this as a non-fatal error, and complaining in the log about the
malformed initialization strings. This enabled the connect to
potentially succeed, although the remote VIM still may not work
correctly if the XSystem properties are not propogated correctly.

An example of the malformed intitialization property looks like:
FINEST: Initialization
protocol .xam.log.path.type=xam_string.xam.log.format.value=00000000000000000001
decodes to name value.xam.log.path.type
xam_string.xam.log.format.value=00000000000000000001

What should have been sent looks like:

FINEST: Initialization protocol .xam.log.path.type=xam_string decodes
to name value.xam.log.path.type xam_string

Note that the broken version seems to have slammed the next property
together with the previous. This may be a result of some compilation
flag or something like that. More debugging is required to see if the
fault is in the sender or in the interpretation side of things in the
HTTP Protocol VIM.

No defect has been file with SNIA about this.


Diffs for this code (HTTP_Protocol_VIM):
===================================================================
--- src/org/snia/xam/vim/isolation/server/http/handlers/
XSystemConnect.java (revision 499)
+++ src/org/snia/xam/vim/isolation/server/http/handlers/
XSystemConnect.java (working copy)
@@ -157,6 +157,7 @@
XSystemCache xsc = XSystemCache.getInstance();

handle = xsc.addXSystem(xri, xs);
+ logger.info( "Return XSystem handle: " + handle );

// Process the incoming buffer and write new fields to the
XSystem
ByteBuffer[] bbs = bufferList.getBuffers();
@@ -177,6 +178,7 @@
} catch (XAMException ex) {
status = ex.getStatusCode();
statusMsg = ex.getMessage();
+ logger.log( Level.SEVERE, "XAM Exception" + ex.getMessage
(), ex );
} catch( Exception e ) {
status = XAMException.sXAM_INVALID_HANDLE;
statusMsg = ProtocolConstants.UNEXPECTED_EXCEPTION;
@@ -222,36 +224,38 @@
while( keys.hasMoreElements() )
{
InitializationRecord ir = props.get(keys.nextElement());
+ logger.log( Level.INFO, "Init Param " + ir.name + "/" +
ir.type );
if( ir.type.equals(ProtocolConstants.XAM_BOOLEAN))
try { xs.createProperty( ir.name, ir.binding,
Boolean.parseBoolean(ir.value)); }
catch( FieldExistsException fee ) { xs.setProperty
( ir.name, Boolean.parseBoolean(ir.value)); }

- else if( ir.type.equals(ProtocolConstants.XAM_DATETIME )) {
+ else if( ProtocolConstants.XAM_DATETIME.equals(ir.type)) {
Calendar value = GregorianCalendar.getInstance();
value.setTimeInMillis(new Long(ir.value).longValue());
try { xs.createProperty( ir.name, ir.binding, value); }
catch( FieldExistsException fee ) { xs.setProperty
( ir.name, value ); }
}

- else if( ir.type.equals(ProtocolConstants.XAM_DOUBLE))
+ else if( ProtocolConstants.XAM_DOUBLE.equals(ir.type))
try { xs.createProperty( ir.name, ir.binding,
Double.parseDouble(ir.value)); }
catch( FieldExistsException fee ) { xs.setProperty
( ir.name, Double.parseDouble(ir.value)); }

- else if( ir.type.equals(ProtocolConstants.XAM_INTEGER))
+ else if( ProtocolConstants.XAM_INTEGER.equals(ir.type))
try { xs.createProperty( ir.name, ir.binding,
Long.parseLong(ir.value)); }
catch( FieldExistsException fee ) { xs.setProperty
( ir.name, Long.parseLong(ir.value)); }

- else if( ir.type.equals(ProtocolConstants.XAM_STRING ))
+ else if( ProtocolConstants.XAM_STRING.equals(ir.type))
try { xs.createProperty( ir.name, ir.binding,
ir.value ); }
catch( FieldExistsException fee ) { xs.setProperty
( ir.name, ir.value ); }

- else if( ir.type.equals(ProtocolConstants.XAM_XUID))
+ else if( ProtocolConstants.XAM_XUID.equals(ir.type))
try { xs.createProperty( ir.name, ir.binding,
DefaultXUID.valueOf(ir.value) ); }
catch( FieldExistsException fee ) { xs.setProperty
( ir.name, DefaultXUID.valueOf(ir.value) ); }

else
- throw new ConnectException( "Unknown property type in
initialization protocol: " +
- ir.type + " for property " + ir.name );
+ {
+ logger.log( Level.SEVERE, "Unknown property TYPE " +
ir.type + " for property " + ir.name );
+ }
}
}

@@ -284,6 +288,7 @@
logger.log( Level.SEVERE, "Unsupported encoding in
XSystem.connect protocol", uee );
return;
}
+ logger.log( Level.FINEST, "Initialization protocol " + pair + "
decodes to name value" + name + " " + value );
int lastDot = name.lastIndexOf('.');
String propertyName = name.substring(0,lastDot);
InitializationRecord ir = props.get(propertyName);
@@ -299,7 +304,7 @@
else if( name.endsWith(TYPE))
ir.type = value;
else
- throw new ConnectException( "Unexpected initialization
property in connect protocol: " + name );
+ logger.log( Level.SEVERE, "Unexpected initialization
property in connect protocol: " + pair );
}

}

[Scott Ostapovicz]

What are the conditions in which the formatting fails?

[Michael J. Allison]

I don't know exactly. The client and server are both running on Windows XP SP3, Java 1.6.

I truly don't know where the error is occuring. All I do know is that by the time the HTTP VIM Server handler get's connect stream, the strings are malformed as below. I have not tried to reproduce this error. I know it would have been caught during development since we never would have gotten past the connect. 

One guess I have is that the Windows side could have been compile with MS Dev Studio set to UNICODE instead of MBCS, but even then that's just a real WAG. 

So this note is not a fix for the problem, but makes it less severe. I am thinking that malformed initialization strings should not cause the connect to fail. This is basically what this diff provides.

On Nov 3, 2009, at 12:00 PM, Scott Ostapovicz wrote:

What are the conditions in which the formatting fails?

On Tue, Nov 3, 2009 at 3:28 PM, Mike A <kn...@arrl.net> wrote:

I have been helping out a company experiencing some problems
connecting from the C XAM Library to the Reference VIM using the HTTP
VIM Stack. During the process of looking at logs, we found that the
HTTP C VIM being used is horribly broken and is sending malformed
initialization field information to the HTTP VIM Server. When these
malformed strings are passed over, the HTTP VIM Server barfs with a
ConnectException( 1025 ) and fails the connect. This is a fatal
error.

Since this made debugging difficult, I modified the HTTP VIM Server to
treat this as a non-fatal error, and complaining in the log about the
malformed initialization strings. This enabled the connect to
potentially succeed, although the remote VIM still may not work
correctly if the XSystem properties are not propogated correctly.

An example of the malformed intitialization property looks like:
FINEST: Initialization

protocol ..xam.log.path.type=xam_string.xam.log.format.value=00000000000000000001

[Michael J. Allison]

Oh, one other thing. The problem was encountered by a third party.
They mentioned that some code changes were required to get the C side
to compile. I didn't investigate those either, but the presence of
code changes of unknown scope makes me nervous.

Mike A

[Scott Ostapovicz]

So do you have the code changes that they made? It might help to review them to see what they needed to change.

[Michael J. Allison]

My mistake. The third party didn't change the HTTP C VIM. I'm back to guess as to what the real problem is. 

He did report that the HTTP C VIM project (MS Dev Studio) project preferences didn't have a character set chose, but I don't know what that means. 

I don't really know what's going on. I guess I fade back into the wood work.

Mike A