SocketServer and a Java applet listener
steve.horsley at gmail.com
Mon Aug 29 13:19:37 CEST 2005
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.
More information about the Python-list