Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!news-1.dfn.de!news.dfn.de!news.informatik.hu-berlin.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: =?ISO-8859-1?Q?Ronny_Sch=FCtz?= <usenet.r96@gishpuppy.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: Buffered reading seems to corrupt data stream
Date: Mon, 03 Oct 2011 17:54:33 +0200
Lines: 25
Message-ID: <pe2pl8-h72.ln1@groombridge34.de>
References: <y4Cdne-uvN4kUBTTnZ2dnUVZ_hWdnZ2d@westnet.com.au> <IfmdnSISO4_8SRTTnZ2dnUVZ_qmdnZ2d@westnet.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: individual.net GLemzmTRaRYvO5zhFwKyHwMJRXCDJdXzfmVt5Y2XRM4HxEbVXRgN8a2A==
X-Orig-Path: groombridge34.de!not-for-mail
Cancel-Lock: sha1:EUmtx0GyjO0mTWnQ5RgOEp4yE0U=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
In-Reply-To: <IfmdnSISO4_8SRTTnZ2dnUVZ_qmdnZ2d@westnet.com.au>
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8492

>> The problem is that for the second or third read, the size variable is
>> coming back as garbage (extremely high or even negative value) and the
>> reading of the byte array blocks as it waits for a large amount of
>> data to be received or crashes with the invalid negative size even
>> though the previous size value and the previous bytes themselves are
>> correct. However, if I remove the BufferedInputStream wrapping of
>> stream, it works perfectly.
>>
>> Why would that be?
> 
> I forgot to mention that there is only *one* input stream (is) and
> output stream (os) being used in to the above code. Once the connection
> between client and server is established I repeatedly send the fixed
> byte array data (fixed for testing purposes) on the connected stream.

It might be, that the BufferedInputStream used for the first read
already read data belonging to the second message, that will get lost
when you dispose the BufferedInputStream and will be missing from the
next read call. The garbage size read is most likely actually a part of
the payload bytes. Try to synchronize server and client somehow to
verify. Better reuse the complete stream chain.

Ronny