SocketServer and a Java applet listener

[Steve Horsley]

google at phaedro.com wrote:
> Steve Horsley schreef:
> 
> 
>>Probably the same problem. If you didn't send a 2 byte length
>>indicator first, then java's readUTF() will have tried to
>>interpret the first 2 bytes that you did actually send as the
>>string length, and may well simply be waiting patiently for the
>>rest to arrive.
>>
> 
> I just couldn't get read/writeUTF and python unicode to interface, so I
> refactored the applet's socketlistener to convert the
> socket.getInputStream to a BufferedInputReader on which I call the
> readline() method.
> I still skip the first two bytes in the python receiver which seems
> harmless since python doesn't use the byte length.
> On both sides I have other way to know when the end-of-message has been
> reached. A timeout mechanism provides some safety for partial
> transmission handling.
> 

I would encourage you to re-think this.

There are two normal ways to delineate messages in the 
byte-stream: An explicit length indication up front (which java 
read/writeUTF chooses), or a unique end-of-message indication at 
the end such as your readline() for strings that end in linefeed.

HTTP is an interesting mixture of these - the header contains a 
content-length line telling you how long the payload is, but the 
header itslef is variable length, terminated by a blank line. In 
chunked encoding, there is a variable number of chunks, and the 
last chunk is marked as such in the header.

Anyway, either approach is good. But using timing to separate 
messages is Bad. There is always the chance that you will get 
bitten by strange timings happening later on.

If you choose to go for the java read/writeUTF approach, the 
2-byte length indicator goes Most Significant Byte first, so a 
100 char string would be preceded by 00 64 ... Also, the 
indicator gives the number of bytes after encoding, not the 
number of characters before encoding.

Steve