zócalo java writeUTF() y readUTF()

Question

He estado leyendo un fragmento de código del zócalo Java y adivino un hecho que en la comunicación del zócalo, para enviar mensajes en secuencia, no es necesario separarlos a mano, el secuencia de escritor/lector hacer las cosas automáticamente para usted. Aquí hay un ejemplo:

writer.java 
writeUTF("Hello"); 
writeUTF("World"); 


reader.java 
String a=readUTF(); // a=Hello 
String a=readUTF(); // b=World 

He intentado este fragmento de código y funciona bien. Sin embargo, me pregunto si se supone que este tipo de estilo de codificación funciona bien. ¿Hay algún riesgo potencial de usar el flujo de socket en secuencia sin separar explícitamente cada segmento?

Answer 1

De acuerdo con la documentación, los métodos readUTF y writeUTF funcionan con una versión modificada de UTF8 que también agrega la longitud del carácter que se leerá al principio.

Esto debería significar que la operación de lectura esperará hasta que se hayan obtenido suficientes caracteres antes de devolver la cadena ... esto significa que en realidad también están segmentados si no lo ve, ya que simplemente decora las secuencias del socket con el DataInputStream y DataOutputStream.

En conclusión, sí, debería ser bastante seguro, ya que la propia API se ocupará de separar los mensajes individuales.

Answer 2

writeUTF() y readUTF() escriben la longitud de la Cadena (en bytes, cuando se codifica como UTF-8), seguido de los datos, y usan una codificación modified UTF-8. Así que hay algunos problemas potenciales:

• La longitud máxima de cadenas que puede ser manejado de esta manera es 65535 para ASCII puro, menos si se utilizan caracteres no ASCII - y no se puede predecir fácilmente el límite en ese caso, además de asumir de manera conservadora 3 bytes por carácter. Entonces, si estás seguro de que nunca enviarás cadenas de más de 20k, estarás bien.
• Si la aplicación alguna vez necesita comunicarse con otra cosa (eso no está escrito en Java), la otra parte puede tener dificultades para manejar el UTF-8 modificado. Para la comunicación interna de la aplicación, no tienes que preocuparte.

Answer 3

java.net.Socket funciona bien, la corriente de espera readUTF();

Pero cuando se utiliza de CumulativeProtocolDecoder, no será, lanza java.io.EOFException