Tamaño de read/write
Alberto Giménez
Estoy haciendo una práctica en la cual se "simula" el comportamiento del
protocolo send & wait, programada con sockets y todo eso.
Tenemos que enviar tramas con cabeceras, números de secuencia y al final
de la trama 2 bytes de CRC.
El caso es que cuando el tamaño de trama es de 32768 (0x8000) bytes o
más, me empieza a fallar el read, leyéndome un par de bytes de menos *a
veces* (o sea, que CRC a tomar por culo).
El 'bug' no es reproducible, me pasa cuando le da la gana y a veces no
pasa, es bastante raro. En el man del read he visto que si el argumento
que indica el tamaño es mayor que SSIZE_MAX, el comportamiento es
indefinido, pero esta constante yo la tengo como 2 mil millones y pico
(creo que como un long). La verdad es que no sé por dónde van los
tiros...
He pensado que no es normal que por una interfaz loopback haya fallos de
ese tipo, y lo que más me extraña es que de 32768 para abajo funciona
*siempre* a la perfección. A ver si alguno sabéis de que va... ¡Gracias!
--
Luis Alberto Giménez
JabberID: SimM...@amessage.de
GnuPG ID: 0x3BAABDE1
Pascal Bourguignon
Se puede que tienes que leer la trama en dos partes.
Un read(2) no tiene que retornar todo de un solo golpe.
Igual, un write(2) no tiene que toma todo de un solo golpe.
Por eso, retornan el número de octetos leído o escrito.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
Alberto Giménez
> Un read(2) no tiene que retornar todo de un solo golpe.
Vaya! Es exactamente eso que tú dices. Ya he sustituido el read por un
"bucle de lectura" y ya mefunciona todo correcto. Se dejaba unos cuantos
bytes en el tintero para poder seguir leyéndolos después.
La verdad es que me quitas un peso de encima porque llevo ya tres días
con el problemita... y la solución era así de simple... XD
Es que con read tenía la mentalidad de leer de fichero, que siempre lee
todo el trozo que le indicas excepto la última lectura, si quedan menos
bytes, y no se me ha ocurrido que por lo que sea la recepción mediante
un socket pueda ser "troceada" (porque yo el write lo hago todo de una
vez también, y no me ha dado ningún problema). Bueno, gracias otra vez
;)
Saludos
Pascal Bourguignon
Igual por los fichero, no siempre lee todo de un solo golpe. Cuando
hay un interrupción (un signal) por ejemplo, tambien read(2) puede
retornar con un resultado parcial.
Comprobalo, encuentraras una "bucle de lectura" en las fuentes de
fread en glibc...