Bluetooth - OBEX Get command - Different behaviour at J2SE and J2ME

[Virago139]

Hi all.

I'm having a weird problem with the OBEX GET command using a Nokia X3-02

My system is formed by a server application running in a Mac OS X (Bluecove 2.1.0) and two different clients: one implemented with J2SE (same Bluecove version) and another one (J2ME) running at a Nokia X3-02 (S40). The weird thing is that, using the same code in both clients, the J2SE one runs properly but the J2ME one makes the server behave weird.

Here is the client code (same for both clients). This method asks the server for some user information:


public String pedirPerfil() throws IOException
{ String perfil = "?";

headerSet.setHeader(0x36, "1");

Operation op = conexion.get(headerSet);
InputStream in = op.openInputStream();

byte[] cadena = new byte[2048];
int cuantos = in.read(cadena);

// Traduzco lo que me ha llegado a caracteres.
char[] cadenaChar = new char[2048];
for ( int y=0; y<cadena.length; y++ )
cadenaChar[y] = (char)cadena[y];

in.close();
int responseCode = op.getResponseCode();
if ( responseCode == ResponseCodes.OBEX_HTTP_OK )
{ op.close();
perfil = String.valueOf(cadenaChar);
}
else
{ op.close();
throw new IOException( "Request failed. Response code: " +
ppal.traducirResponseCode(responseCode) );
}

return perfil;
}


----------

And here is the onGet method at the server:

public int onGet(Operation op)
{
try
{
OutputStream out = op.openOutputStream();
byte[] tmpBuf = ppal.respuestaOnGet( op.getReceivedHeaders() );

out.write( tmpBuf );
try
{
out.flush();
}
catch( IOException e2 )
{
return( ResponseCodes.OBEX_HTTP_TIMEOUT );
}
op.close();
return( ResponseCodes.OBEX_HTTP_OK );
}
catch( Exception e1 )
{
return( ResponseCodes.OBEX_HTTP_INTERNAL_ERROR );
}
}


When the J2SE client is requesting the info, the server method executes out.write(tmpBuf), out.flush(), and op.close() without problems. op.close() returns control to the client, which reads the transmitted data and asks the server for the responseCode; server returns OBEX_HTTP_OK and then client goes forward.

But, when it's the J2ME application requesting info, the server method executes out.write(tmpBuf) and out.flush. In that moment, control jumps back to the client (data contained at 'tmpBuf' is properly transmitted), but op.close() is never executed at the server. The client application continues executing, and it requests the responseCode; this is always 144 (OBEX_HTTP_CONTINUE), though this request never gets to the server. And then, after the timeout for the server has ended, the “out.flush()” line throws an IOInterruptedException.

I'm suspecting if it could be related with some particular behaviour of InputStream and/or OutputStream at the J2ME or at the Nokia phone. In fact, the (J2ME) received an empty string from the server until I added the "out.flush()" instruction at onGet, and this is not needed for J2SE (in that case, the "out.write()" instruction sends the tmpBuf content to the client).

Any idea? Any help or comment would be really appreciated. This problem is driving me nuts.

Thanks in advance,
Maria

[traud]

Please install the Xcode (Developer) tools. In the Developer folder on your disk, there is a PacketLogger. You can view the OBEX packet exchange with that. You might need the latest OBEX specification from IrDA.org.

However, I would not use the javax.obex package. All implementations I saw so far are terrible incompatible. Those packages are optimised for PUT operations, only. Furthermore, with large, very large objects you might fill up your heap. (Not in you case, because your strings seems to be small: Normally, instead of using a byte array, try to forward the stream to your callee classes.) Implement your own protocol on top of RFComm (SPP) or implement your own OBEX client. It is not that difficult; for me it was easier than to debug all those bugs especially because you cannot do much wrong/different when using the javax.obex package.

But …

headerSet.setHeader(0x36, "1");

What is this? This is a user defined header with a null terminated UTF-16 content. If both parts are Java, you can use the DataStreams and their UTF-8 method.

Are you sure, your in.close does not throw an exception?