Skip to main content

Issue with Nokia HttpConnection.flush()

5 replies [Last post]
Anonymous

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Chris B

content-length: -1 (although I explicitly set it to the byte array length)
connection: close (implicitly set)
content-type: application/x-www-form-urlencoded (explicitly set)
transfer-encoding: chunked (implicitly set)

you cant have a chunked with a content length! it's one or the other.

----- Original Message -----
From: Ricardo Scholz
To: KVM-INTEREST@JAVA.SUN.COM
Sent: Monday, June 22, 2009 9:25 PM
Subject: Issue with Nokia HttpConnection.flush()

Hello everybody,

I've been trying to implement a client-server application that exchanges byte arrays through a HTTP connection. My client-server application works fine with a Motorola V3, but when I try to connect from a Nokia 5310 XpressMusic, the input stream in the server cannot be read (it comes empty). I used a software that receives the connection and forwards the request to the server, to see some information about what was being sent by the clients, so I got the information below:

In the successful Motorola version, the header parameters are:

content-length: -1 (although I explicitly set it to the byte array length)
connection: close (implicitly set)
content-type: application/x-www-form-urlencoded (explicitly set)
transfer-encoding: chunked (implicitly set)

and the actual data sent has the chunked formatting (the chunk size prepended and a zeroed chunk size to inform the end of the chunks sequence), as below:

29
3333223cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š›
0

In the other hand, the unsuccessful Nokia version has the following header parameters:

content-length:
(explicitly set)
connection: keep alive (implicitly set)
content-type: application/x-www-form-urlencoded (explicitly set)

and the actual data sent does not have the chunked formating, as below:

3333223cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š›

I used pretty much the networking implementation as defined in the API. In addition, as far as I could understand, the call to HttpConnection.flush() sets the transfer-encoding header parameter to chunked, but it only works for the Motorola version. Without it, none of the two versions works fine, as it seems that the server can only deal with chunked data.

I've tried to find something in the Forum Nokia, KVM-Interests archives and Google, but without actual success.

If you guys have any idea on how to work this around, either in the client application or in the server application, I'd appreciate.

Many thanks.

Best regards,

Ricardo Scholz.

--
ricardo]scholz
meantime]mobile.creations
+55[81]8664.8665
=========================================================================== To unsubscribe, send email to listserv@java.sun.com and include in the body of the message "signoff KVM-INTEREST". For general help, send email to listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Ricardo Scholz

Hi All,

There's a mistake in the first message, when I said HttpConnection.flush() I
meant OutputStream.flush().

Hi Chris,

Thanx for your reply. Yes, you're right. Setting the content-length makes no
sense if the chunked protocol prepends each chunk length at the beginning of
the chunks. The Motorola version content-length is overwritten to -1, and
works fine.

My question is: why the Nokia version does not overwrite the content-length
property to -1 when I call OutputStream.flush() [what seems to be the method
that makes transfer-encoding be changed to chunked in the Motorola version]?
Also, this method does not make the transfer-encoding be changed to chunked,
nor actually includes the prepended chunks length in the message body [it
seems to infuence both in the Motorola version].

I can't underestand how to get control of 'chunking' turnning on/off. (I
don't even know whether it is possible or not).

I'll try without setting the content-length (as setting it is useless and
makes no sense anyway ;)

Best regards,

Ricardo.

On Mon, Jun 22, 2009 at 11:21 PM, Chris B wrote:

> content-length: -1 (although I explicitly set it to the byte array
> length)
> connection: close (implicitly set)
> content-type: application/x-www-form-urlencoded (explicitly set)
> transfer-encoding: chunked (implicitly set)
>
>
> you cant have a chunked with a content length! it's one or the other.
>
>
> ----- Original Message -----
> *From:* Ricardo Scholz
> *To:* KVM-INTEREST@JAVA.SUN.COM
> *Sent:* Monday, June 22, 2009 9:25 PM
> *Subject:* Issue with Nokia HttpConnection.flush()
>
> Hello everybody,
>
> I've been trying to implement a client-server application that exchanges
> byte arrays through a HTTP connection. My client-server application works
> fine with a Motorola V3, but when I try to connect from a Nokia 5310
> XpressMusic, the input stream in the server cannot be read (it comes empty).
> I used a software that receives the connection and forwards the request to
> the server, to see some information about what was being sent by the
> clients, so I got the information below:
>
> In the successful Motorola version, the header parameters are:
>
> content-length: -1 (although I explicitly set it to the byte array length)
> connection: close (implicitly set)
> content-type: application/x-www-form-urlencoded (explicitly set)
> transfer-encoding: chunked (implicitly set)
>
> and the actual data sent has the chunked formatting (the chunk size
> prepended and a zeroed chunk size to inform the end of the chunks sequence),
> as below:
>
> 29
> 3333223 cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š›
> 0
>
> In the other hand, the unsuccessful Nokia version has the following header
> parameters:
>
> content-length:
(explicitly set)
> connection: keep alive (implicitly set)
> content-type: application/x-www-form-urlencoded (explicitly set)
>
>
> and the actual data sent does not have the chunked formating, as below:
>
> 3333223 cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š›
>
> I used pretty much the networking implementation as defined in the API. In
> addition, as far as I could understand, the call to HttpConnection.flush()
> sets the transfer-encoding header parameter to chunked, but it only works
> for the Motorola version. Without it, none of the two versions works fine,
> as it seems that the server can only deal with chunked data.
>
> I've tried to find something in the Forum Nokia, KVM-Interests archives and
> Google, but without actual success.
>
> If you guys have any idea on how to work this around, either in the client
> application or in the server application, I'd appreciate.
>
> Many thanks.
>
> Best regards,
>
> Ricardo Scholz.
>
> --
> ricardo]scholz
> meantime]mobile.creations
> +55[81]8664.8665
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

--
ricardo]scholz
+55[81]8664.8665

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Roger

Hi Ricardo,

no, You can't take influence on the transfer-encoding. Motorola uses
chunked, Nokia doesn't. So it's an absolute must to write the
content-length to the header for Nokia phones.

But why on earth do you set the content-type? In my opinion you should
leave it out unless you really encode you data properly before streaming it.

flush() doesn't influence the transfer-encoding at all. It simply
empties the internal buffer. Besides flush ist called automatically,
when closing a connection.

Do you close the connection? If the header says "connection:
keep-alive", you have to do so. Otherwise the server ist waiting for
content until tomorrrow.

Best,

Roger

Ricardo Scholz schrieb:
> Hi All,
>
> There's a mistake in the first message, when I said
> HttpConnection.flush() I meant OutputStream.flush().
>
> Hi Chris,
>
> Thanx for your reply. Yes, you're right. Setting the content-length
> makes no sense if the chunked protocol prepends each chunk length at
> the beginning of the chunks. The Motorola version content-length is
> overwritten to -1, and works fine.
>
> My question is: why the Nokia version does not overwrite the
> content-length property to -1 when I call OutputStream.flush() [what
> seems to be the method that makes transfer-encoding be changed to
> chunked in the Motorola version]? Also, this method does not make the
> transfer-encoding be changed to chunked, nor actually includes the
> prepended chunks length in the message body [it seems to infuence both
> in the Motorola version].
>
> I can't underestand how to get control of 'chunking' turnning on/off.
> (I don't even know whether it is possible or not).
>
> I'll try without setting the content-length (as setting it is useless
> and makes no sense anyway ;)
>
> Best regards,
>
> Ricardo.
>
> On Mon, Jun 22, 2009 at 11:21 PM, Chris B > > wrote:
>
> content-length: -1 (although I explicitly set it to the byte array
> length)
> connection: close (implicitly set)
> content-type: application/x-www-form-urlencoded (explicitly set)
> transfer-encoding: chunked (implicitly set)
>
>
> you cant have a chunked with a content length! it's one or the other.
>
>
> ----- Original Message -----
> *From:* Ricardo Scholz
> *To:* KVM-INTEREST@JAVA.SUN.COM
>
> *Sent:* Monday, June 22, 2009 9:25 PM
> *Subject:* Issue with Nokia HttpConnection.flush()
>
> Hello everybody,
>
> I've been trying to implement a client-server application that
> exchanges byte arrays through a HTTP connection. My
> client-server application works fine with a Motorola V3, but
> when I try to connect from a Nokia 5310 XpressMusic, the input
> stream in the server cannot be read (it comes empty). I used a
> software that receives the connection and forwards the request
> to the server, to see some information about what was being
> sent by the clients, so I got the information below:
>
> In the successful Motorola version, the header parameters are:
>
> content-length: -1 (although I explicitly set it to the byte
> array length)
> connection: close (implicitly set)
> content-type: application/x-www-form-urlencoded (explicitly set)
> transfer-encoding: chunked (implicitly set)
>
> and the actual data sent has the chunked formatting (the chunk
> size prepended and a zeroed chunk size to inform the end of
> the chunks sequence), as below:
>
> 29
> 3333223 cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š›
> 0
>
> In the other hand, the unsuccessful Nokia version has the
> following header parameters:
>
> content-length:
(explicitly set)
> connection: keep alive (implicitly set)
> content-type: application/x-www-form-urlencoded (explicitly set)
>
>
> and the actual data sent does not have the chunked formating,
> as below:
>
> 3333223 cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š›
>
> I used pretty much the networking implementation as defined in
> the API. In addition, as far as I could understand, the call
> to HttpConnection.flush() sets the transfer-encoding header
> parameter to chunked, but it only works for the Motorola
> version. Without it, none of the two versions works fine, as
> it seems that the server can only deal with chunked data.
>
> I've tried to find something in the Forum Nokia, KVM-Interests
> archives and Google, but without actual success.
>
> If you guys have any idea on how to work this around, either
> in the client application or in the server application, I'd
> appreciate.
>
> Many thanks.
>
> Best regards,
>
> Ricardo Scholz.
>
> --
> ricardo]scholz
> meantime]mobile.creations
> +55[81]8664.8665
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com
> and include in the body of the
> message "signoff KVM-INTEREST". For general help, send email
> to listserv@java.sun.com and
> include in the body of the message "help".
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com
> and include in the body of the
> message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include
> in the body of the message "help".
>
>
>
>
> --
> ricardo]scholz
> +55[81]8664.8665
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body of the message "signoff KVM-INTEREST". For general help, send
> email to listserv@java.sun.com and include in the body of the message
> "help".

--
/**************************
* Roger F. Hösl
* ...
**************************/

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Ricardo Scholz

Hi all, it worked. Thank you all guys for your quick replies and attention.

Roger, thanx for the information. It worked for both versions (Motorola and
Nokia) by leaving the "content-type" out, seting the "content-length"
properly and setting the "connection" property to "close".

Just for the records, in case someone else has a similar problem:

no, You can't take influence on the transfer-encoding. Motorola uses
> chunked, Nokia doesn't. So it's an absolute must to write the content-length
> to the header for Nokia phones.
>

So, as far as I could understand, it's up to the kvm implementation (for
instance, manufacturers) to define the transfer-encoding when implementing
the HttpConnection. I have no control over it.

> But why on earth do you set the content-type? In my opinion you should
> leave it out unless you really encode you data properly before streaming it.
>

I don't know why I set the content-type. During debug phase I've tried
several approaches, and at some point, someone suggested me to set it to
"application/x-www-urlencoded".

> flush() doesn't influence the transfer-encoding at all. It simply empties
> the internal buffer. Besides flush ist called automatically, when closing a
> connection.
>

Yes, that's what I read from the docs. But when I took away the 'flush()'
call in the Motorola version, the packages started being transfered in a
non-chunked way. Maybe I had changed something else at the same time that
I'm missing now, and then I misinterpreted the results.

> Do you close the connection? If the header says "connection: keep-alive",
> you have to do so. Otherwise the server ist waiting for content until
> tomorrrow.
>

Now I set the "connection" parameter to close, and I close the OutputStream
before calling HttpConnection.getResponseCode().

Thanx again.

Best regards,

Ricardo.

>
>
> Ricardo Scholz schrieb:
>
> Hi All,
>
> There's a mistake in the first message, when I said HttpConnection.flush()
> I meant OutputStream.flush().
>
> Hi Chris,
>
> Thanx for your reply. Yes, you're right. Setting the content-length makes
> no sense if the chunked protocol prepends each chunk length at the beginning
> of the chunks. The Motorola version content-length is overwritten to -1, and
> works fine.
>
> My question is: why the Nokia version does not overwrite the content-length
> property to -1 when I call OutputStream.flush() [what seems to be the method
> that makes transfer-encoding be changed to chunked in the Motorola version]?
> Also, this method does not make the transfer-encoding be changed to chunked,
> nor actually includes the prepended chunks length in the message body [it
> seems to infuence both in the Motorola version].
>
> I can't underestand how to get control of 'chunking' turnning on/off. (I
> don't even know whether it is possible or not).
>
> I'll try without setting the content-length (as setting it is useless and
> makes no sense anyway ;)
>
> Best regards,
>
> Ricardo.
>
> On Mon, Jun 22, 2009 at 11:21 PM, Chris B wrote:
>
>> content-length: -1 (although I explicitly set it to the byte array
>> length)
>> connection: close (implicitly set)
>> content-type: application/x-www-form-urlencoded (explicitly set)
>> transfer-encoding: chunked (implicitly set)
>>
>>
>> you cant have a chunked with a content length! it's one or the other.
>>
>>
>> ----- Original Message -----
>> *From:* Ricardo Scholz
>> *To:* KVM-INTEREST@JAVA.SUN.COM
>> *Sent:* Monday, June 22, 2009 9:25 PM
>> *Subject:* Issue with Nokia HttpConnection.flush()
>>
>> Hello everybody,
>>
>> I've been trying to implement a client-server application that exchanges
>> byte arrays through a HTTP connection. My client-server application works
>> fine with a Motorola V3, but when I try to connect from a Nokia 5310
>> XpressMusic, the input stream in the server cannot be read (it comes empty).
>> I used a software that receives the connection and forwards the request to
>> the server, to see some information about what was being sent by the
>> clients, so I got the information below:
>>
>> In the successful Motorola version, the header parameters are:
>>
>> content-length: -1 (although I explicitly set it to the byte array length)
>> connection: close (implicitly set)
>> content-type: application/x-www-form-urlencoded (explicitly set)
>> transfer-encoding: chunked (implicitly set)
>>
>> and the actual data sent has the chunked formatting (the chunk size
>> prepended and a zeroed chunk size to inform the end of the chunks sequence),
>> as below:
>>
>> 29
>> 3333223 cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š›
>> 0
>>
>> In the other hand, the unsuccessful Nokia version has the following header
>> parameters:
>>
>> content-length:
(explicitly set)
>> connection: keep alive (implicitly set)
>> content-type: application/x-www-form-urlencoded (explicitly set)
>>
>>
>> and the actual data sent does not have the chunked formating, as below:
>>
>> 3333223 cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š›
>>
>> I used pretty much the networking implementation as defined in the API. In
>> addition, as far as I could understand, the call to HttpConnection.flush()
>> sets the transfer-encoding header parameter to chunked, but it only works
>> for the Motorola version. Without it, none of the two versions works fine,
>> as it seems that the server can only deal with chunked data.
>>
>> I've tried to find something in the Forum Nokia, KVM-Interests archives
>> and Google, but without actual success.
>>
>> If you guys have any idea on how to work this around, either in the client
>> application or in the server application, I'd appreciate.
>>
>> Many thanks.
>>
>> Best regards,
>>
>> Ricardo Scholz.
>>
>> --
>> ricardo]scholz
>> meantime]mobile.creations
>> +55[81]8664.8665
>> ===========================================================================
>> To unsubscribe, send email to listserv@java.sun.com and include in the
>> body of the message "signoff KVM-INTEREST". For general help, send email to
>> listserv@java.sun.com and include in the body of the message "help".
>>
>> ===========================================================================
>> To unsubscribe, send email to listserv@java.sun.com and include in the
>> body of the message "signoff KVM-INTEREST". For general help, send email to
>> listserv@java.sun.com and include in the body of the message "help".
>
>
>
>
> --
> ricardo]scholz
> +55[81]8664.8665
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
>
> --
> /**************************
> * Roger F. Hösl
> * ...
> **************************/
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>

--
ricardo]scholz
+55[81]8664.8665

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Chris B

If in doubt write the headers and body out manually with DataOutputStream.
----- Original Message -----
From: Ricardo Scholz
To: KVM-INTEREST@JAVA.SUN.COM
Sent: Tuesday, June 23, 2009 3:49 PM
Subject: Re: Issue with Nokia HttpConnection.flush()

Hi all, it worked. Thank you all guys for your quick replies and attention.

Roger, thanx for the information. It worked for both versions (Motorola and Nokia) by leaving the "content-type" out, seting the "content-length" properly and setting the "connection" property to "close".

Just for the records, in case someone else has a similar problem:

no, You can't take influence on the transfer-encoding. Motorola uses chunked, Nokia doesn't. So it's an absolute must to write the content-length to the header for Nokia phones.

So, as far as I could understand, it's up to the kvm implementation (for instance, manufacturers) to define the transfer-encoding when implementing the HttpConnection. I have no control over it.

But why on earth do you set the content-type? In my opinion you should leave it out unless you really encode you data properly before streaming it.

I don't know why I set the content-type. During debug phase I've tried several approaches, and at some point, someone suggested me to set it to "application/x-www-urlencoded".

flush() doesn't influence the transfer-encoding at all. It simply empties the internal buffer. Besides flush ist called automatically, when closing a connection.

Yes, that's what I read from the docs. But when I took away the 'flush()' call in the Motorola version, the packages started being transfered in a non-chunked way. Maybe I had changed something else at the same time that I'm missing now, and then I misinterpreted the results.

Do you close the connection? If the header says "connection: keep-alive", you have to do so. Otherwise the server ist waiting for content until tomorrrow.

Now I set the "connection" parameter to close, and I close the OutputStream before calling HttpConnection.getResponseCode().

Thanx again.

Best regards,

Ricardo.

Ricardo Scholz schrieb:
Hi All,

There's a mistake in the first message, when I said HttpConnection.flush() I meant OutputStream.flush().

Hi Chris,

Thanx for your reply. Yes, you're right. Setting the content-length makes no sense if the chunked protocol prepends each chunk length at the beginning of the chunks. The Motorola version content-length is overwritten to -1, and works fine.

My question is: why the Nokia version does not overwrite the content-length property to -1 when I call OutputStream.flush() [what seems to be the method that makes transfer-encoding be changed to chunked in the Motorola version]? Also, this method does not make the transfer-encoding be changed to chunked, nor actually includes the prepended chunks length in the message body [it seems to infuence both in the Motorola version].

I can't underestand how to get control of 'chunking' turnning on/off. (I don't even know whether it is possible or not).

I'll try without setting the content-length (as setting it is useless and makes no sense anyway ;)

Best regards,

Ricardo.

On Mon, Jun 22, 2009 at 11:21 PM, Chris B wrote:

content-length: -1 (although I explicitly set it to the byte array length)
connection: close (implicitly set)
content-type: application/x-www-form-urlencoded (explicitly set)
transfer-encoding: chunked (implicitly set)

you cant have a chunked with a content length! it's one or the other.

----- Original Message -----
From: Ricardo Scholz
To: KVM-INTEREST@JAVA.SUN.COM
Sent: Monday, June 22, 2009 9:25 PM
Subject: Issue with Nokia HttpConnection.flush()

Hello everybody,

I've been trying to implement a client-server application that exchanges byte arrays through a HTTP connection. My client-server application works fine with a Motorola V3, but when I try to connect from a Nokia 5310 XpressMusic, the input stream in the server cannot be read (it comes empty). I used a software that receives the connection and forwards the request to the server, to see some information about what was being sent by the clients, so I got the information below:

In the successful Motorola version, the header parameters are:

content-length: -1 (although I explicitly set it to the byte array length)
connection: close (implicitly set)
content-type: application/x-www-form-urlencoded (explicitly set)
transfer-encoding: chunked (implicitly set)

and the actual data sent has the chunked formatting (the chunk size prepended and a zeroed chunk size to inform the end of the chunks sequence), as below:

29
3333223 cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š›
0

In the other hand, the unsuccessful Nokia version has the following header parameters:

content-length:
(explicitly set)
connection: keep alive (implicitly set)
content-type: application/x-www-form-urlencoded (explicitly set)

and the actual data sent does not have the chunked formating, as below:

3333223 cdefghijkb–Ÿ5©¦œ“6“”•–<“”•–—˜r™š›

I used pretty much the networking implementation as defined in the API. In addition, as far as I could understand, the call to HttpConnection.flush() sets the transfer-encoding header parameter to chunked, but it only works for the Motorola version. Without it, none of the two versions works fine, as it seems that the server can only deal with chunked data.

I've tried to find something in the Forum Nokia, KVM-Interests archives and Google, but without actual success.

If you guys have any idea on how to work this around, either in the client application or in the server application, I'd appreciate.

Many thanks.

Best regards,

Ricardo Scholz.

--
ricardo]scholz
meantime]mobile.creations
+55[81]8664.8665

=========================================================================== To unsubscribe, send email to listserv@java.sun.com and include in the body of the message "signoff KVM-INTEREST". For general help, send email to listserv@java.sun.com and include in the body of the message "help".
=========================================================================== To unsubscribe, send email to listserv@java.sun.com and include in the body of the message "signoff KVM-INTEREST". For general help, send email to listserv@java.sun.com and include in the body of the message "help".

--
ricardo]scholz
+55[81]8664.8665
=========================================================================== To unsubscribe, send email to listserv@java.sun.com and include in the body of the message "signoff KVM-INTEREST". For general help, send email to listserv@java.sun.com and include in the body of the message "help".

--
/**************************
* Roger F. Hösl
* ...
**************************/=========================================================================== To unsubscribe, send email to listserv@java.sun.com and include in the body of the message "signoff KVM-INTEREST". For general help, send email to listserv@java.sun.com and include in the body of the message "help".

--
ricardo]scholz
+55[81]8664.8665
=========================================================================== To unsubscribe, send email to listserv@java.sun.com and include in the body of the message "signoff KVM-INTEREST". For general help, send email to listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]