Tal como ya había comentado en un post anterior, TCP es un Protocolo de Control de Flujo de Datos, no de Mensaje de Datos por lo que es necesario implementar un separador de Mensajes sobre TCP. ¿Qué exactamente Hace un Separador de Mensajes? Un separador de Mensajes es un conjunto de reglas que se aplican sobre la transmisión de datos para saber de que parte de que flujos comienzan o finalizan los mensajes, casi siempre el Separador de Mensajes se implementa con un Encabezado y un Contenido donde una de las múltiples funciones del encabezado es el de informar del tamaño total del cuerpo del mensaje en caso de que exista. Protocolos como HTTP implementan su propio separador de Mensajes. Ejemplo:
HTTP/1.1 POST /
Content-Length:16
txtNombre=Johan
El ejemplo anterior es un mensaje HTTP, se compone de un encabezado y un cuerpo. El encabezado se compone de un conjunto de Líneas separadas por un tabulado LFCR?? Que se separa del cuerpo del mensaje por una línea en blanco. Si el encabezado contiene una línea Content-Length entonces después de la línea en blanco se recibirá como cuerpo del mensaje el número total de bytes que se especifico en la línea Content-Length, si no se especifica Content-Length, entonces el mensaje se compone solo del encabezado y los siguientes bytes recibidos después de la línea en blanco son tomados como el Encabezado de otro Mensaje.
Para el ejemplo del Mensaje HTTP que se mostro anteriormente corresponde a el siguiente conjunto de bytes:
72, 84, 84, 80, 47, 49, 46, 49, 32, 80, 79, 83, 84, 32, 47, 10,13,67, 111, 110, 116, 101, 110, 116, 45, 76, 101, 110, 103, 116, 104, 58, 49, 54,10,13,10,13,116, 120, 116, 78, 111, 109, 98, 114, 101, 61, 74, 111, 104, 97, 110
Debido a que el encabezado del Mensaje HTTP es siempre ASCII cada byte del encabezado corresponde a un carácter ASCII, la combinación de byte 10(LF, Representado en Espace Unicode de C# como ‘\n’) y 13(CR, Representado en Escape Unicode de C# como ‘\r’) indican que finaliza una Linea del Encabezado HTTP. El dato binario anterior compone un mensaje HTTP completo pero ese dato binario puede recibirse en multiples flujos de datos TCP de cualquier tamaño, Es decir, que podríamos recibir:
72, 84, 84, 80, 47, 49, 46, 49, 32, 80, 79, 83, 84, 32, 47, 10
13,67, 111, 110, 116, 101, 110, 116, 45, 76
101, 110, 103, 116, 104, 58, 49, 54,10,13,10,13,116, 120, 116
78, 111, 109, 98, 114, 101
61, 74, 111, 104, 97, 110
Cuando se está percibiendo datos TCP y haciendo un parsing para Formatear Mensajes, se tiene que saber que bytes corresponden a el encabezado del mensaje actual, el contenido del mensaje actual o el encabezado de los siguientes mensajes que se recibirán. Las operaciones a realizar son las siguientes:
Leer todas las líneas del encabezado hasta encontrar una línea en blanco, que equivale a encontrar la secuencia de bytes 10,13,10,13.
Si el encabezado contiene una sentencia Content-Length y su valor es mayor a 0, entonces después del encabezado se tomaran cuantos bytes se reciban como contenido del Mensaje hasta agotar la cantidad especificada. Ejemplo: Si se recibe en el encabezado la línea ‘Content-Length:3563’, entonces se tomaran los 3563 bytes que se reciban en uno o más flujos de datos después de encontrar la secuencia 10,13,10,13.
Ejemplo:
| Ultima Línea del Encabezado | Fin de Línea en Blanco |
|
| 56 | 34 | 673 | 10 | 13 | 10 | 13 | 43 | 48 | 34 |
| Final de Encabezado HTTP | Contenido |
En una proxima entrega explicare como se ha implementado este Procolo en C#.
Actualmente estoy trabajando con PHP Symfony y instalado un proyecto en Redhat que fue generado y construido en Ubuntu por lo que al instalar el symfony usando pear(al igual que ubuntu) la ruta de los archivos de symfony es diferente y al ejecutar cualquier comando de symfony('symfony cc' por ejemplo) ocurren errores al hacer los includes.
Ejemplo:
