Caso socket type=SOCK_STREAM / protocol=IPPROTO_TCP
En la tarea 1, al realizar la llamada recv
fue posible leer algunos bytes del STREAM, y analizarlos.
De esta forma es posible encontrar algun dato clave (por ejemplo el Content Lenght: en HTTP)
y luego realizar un segunda lectura por el largo deseado.
Esto es posible pues la lectura esta orienteada al STREAM (y no al paquete)
y solo consume a lo sumo la cantidad de bytes leidos.
Luego en la siguiente lectura se avanza en el stream
desde la lectura anterior en la cantidad deseada.
Esto tiene la ventaja de que es posible mantener el sincronismo
en las lecturas y no mezclar tramos de STREAM que pudieran
permanecer en el buffer y que corresponderian a diferentes mensajes capa de aplicacion.
Asimismo si los datos que esperamos vienen en camino es posible quedarse leyendo
de forma bloqueante hasta que los datos lleguen, pues anticipadamenete ya
calculamos cuandos bytes esperamos.
Para el caso socket type = SOCK_RAW / protocol=IPPROTO_RAW,
parece razonable intentar tambien una lectura de esta forma:
1) Leer solo un cabezal IP y verificar que es un header con nuestro protocolo PCT (255)
2) Luego analizar el cabezal IP y tomar el largo del paquete PCT
3) Por ultimo realizar una segunda lectura por el tramo restante
Sin embargo la primer lectura da por consumido todo el buffer
aunque intencionalmente se lea por un tamaño menor (ej 20)
que el largo total de los bytes en el buffer del socket.
Esto ocurre usando tanto recv() como recfvrom()
No seria correcto tampoco pensar que los paquetes son de largo
fijo.
Como el mecanismo planteado antes, no funciona,
entonces no será facil detectar, si la lectura esta completa.
Salvo que la semantica de la lectura del socket RAW tenga
implicita la atomicidad del paquete enviado.
De ser cierto esto ultimo entonces estaria aclarado.
Agradezco si algun docente pone luz en el tema, pues
google no lo ha hecho ;-) y queremos que la lectura
del buffer no se vea afectada de otros paquetes que puedan
estar alcazando la interfase de red.
Saludos y gracias desde ya
Jorge
En respuesta a Usuario eliminado
Re: Atomicidad de los paquetes en modo RAW
Espero que el estándar POSIX responda tu pregunta: http://pubs.opengroup.org/onlinepubs/009695399/functions/recvfrom.html
En otras palabras, lo más fácil desde mi punto de vista es que tengas un buffer temporal sobre 64kB del stack, y llames recvfrom sobre eso. Como estamos utilizando IPv4 tenemos la garantía de que no va a superar los 65535 bytes en ningún caso.
The recvfrom() function shall return the length of the message written to the buffer pointed to by the buffer argument. For message-based sockets, such as [RS] ![[Option Start]](http://pubs.opengroup.org/onlinepubs/009695399/images/opt-start.gif)
SOCK_RAW, ![[Option End]](http://pubs.opengroup.org/onlinepubs/009695399/images/opt-end.gif)
SOCK_DGRAM, and SOCK_SEQPACKET, the entire message shall be read in a single operation. If a message is too long to fit in the supplied buffer, and MSG_PEEK is not set in the flags argument, the excess bytes shall be discarded. For stream-based sockets, such as SOCK_STREAM, message boundaries shall be ignored. In this case, data shall be returned to the user as soon as it becomes available, and no data shall be discarded.
SOCK_RAW, SOCK_DGRAM, and SOCK_SEQPACKET, the entire message shall be read in a single operation. If a message is too long to fit in the supplied buffer, and MSG_PEEK is not set in the flags argument, the excess bytes shall be discarded. For stream-based sockets, such as SOCK_STREAM, message boundaries shall be ignored. In this case, data shall be returned to the user as soon as it becomes available, and no data shall be discarded.En otras palabras, lo más fácil desde mi punto de vista es que tengas un buffer temporal sobre 64kB del stack, y llames recvfrom sobre eso. Como estamos utilizando IPv4 tenemos la garantía de que no va a superar los 65535 bytes en ningún caso.
En respuesta a Francisco Castro Regueira
Re: Atomicidad de los paquetes en modo RAW
de Federico Rodriguez -
Primer elemento importante, los segmentos PCT tienen como máximo un largo definido por el cabezal, lo que indica que podrás leer un segmento entero con su cabezal IP asociado, seteando el tamaño de lectura.
Sobre el resto de los paquetes, consideren el valor de la MTU para considerar un valor razonable de lectura.
La idea es que reciban los datos y los "casteen" sacando la información requerida para su procesamiento. Deben verificar todo, dado que el RAW socket permite la visualización de todos los paquetes IP.
Federico.
NOTA: sobre la recepción tipo stream de datos, para poder resolver la situación propuesta se requiere de la implementación de frames que sean armados por el que envía y desarmados por quién lo recibe. En éste caso no se necesita, dado que se procesa por paquete recibido.
Sobre el resto de los paquetes, consideren el valor de la MTU para considerar un valor razonable de lectura.
La idea es que reciban los datos y los "casteen" sacando la información requerida para su procesamiento. Deben verificar todo, dado que el RAW socket permite la visualización de todos los paquetes IP.
Federico.
NOTA: sobre la recepción tipo stream de datos, para poder resolver la situación propuesta se requiere de la implementación de frames que sean armados por el que envía y desarmados por quién lo recibe. En éste caso no se necesita, dado que se procesa por paquete recibido.