> What about the fact that you could have more than one message in the
incming
> buffer ? In this case, you have to loop until all the messages has been
> processed.
it's looped outside of that method in a seperate thread:
public void run() {
while (true) {
Message message = in.read();
// process the message
}
}
there may be chance that ObjectInputStream.readObject internally reads two
objects and caches them (so as i only read one object, others are skipped)
but i dont know if that's possible. my server encoder writes one object at
a time. it seems reading two objects without reading size of block (first 4
bytes) is impossible.
odd thing :/
On Sun, Jan 10, 2010 at 10:48 PM, Emmanuel LŽcharny <[email protected]>
wrote:
> hakan eryargi a écrit :
>>
>> ok but DataInputStream.readInt(), ObjectInputStream.readObject() and
>> similar
>> methods take care of that, right ? they block until necessary amount of
>> data
>> is available in the underlying stream. that's why i
>> used DataInputStream.readInt() to skip size block instead of read(new
>> byte[4]).
>>
>
> Hmmm... I have overlooked this part of your code
>>
>> the thing here is, DataInputStream or ObjectInputStream somehow skips a
>> *full
>> *block in stream. it's a full block othrwise we would get a
>> StreamCorrupted
>> or similar exceptions..
>>
>
> What about the fact that you could have more than one message in the
incming
> buffer ? In this case, you have to loop until all the messages has been
> processed.
>
>
