Subir archivos con Java mediante HTTP y tratamiento con PHP

Más de una vez me ha surgido la necesidad de subir varios archivos al servidor asíncronamente y de tal forma que muestre al detalle el total de archivos subidos, progreso, tamaño total ,etc.
Pues bien, en uno de mis experimentos, me decidí a desarrollar mi propio uploader en Java, que es lo que voy a tratar de explicar aquí. Para ello analizaremos los paquetes que son enviados al servidor mediante el protocolo HTTP, oséase al servidor web y así poder implementar dicho protocolo en Java.

La subida de archivos por el protocolo HTTP mediante PHP y un servidor web tal como APACHE, para un programador experimentado es bien conocida, no obstante, vamos a repasar algunos conceptos de cómo se hace con este método tan rudimentario y tan usado por muchos.

upload.html

Tenemos preparado el documento html para la entrada de datos, una vez que se pulsa el botón "Subir!", la petición se redirige al script especificado en el atributo "action", en este caso vamos a parar a "tratar-upload.php".

tratar-upload.php
Bien, ya tenemos todo listo, ahora nos toca analizar cómo hace intrínsicamente la operación de subir archivos. Para ello nos valemos de un analizador de protocolos de red tal como wireshark. Ponemos a la escucha en el interfaz de red pertinente, seleccionamos archivos en el documento html y pulsamos el botón "Subir!".

Análisis de subida de archivos por el protocolo HTTP usando el método POST.

Petición HTTP
Quiero hacer una objeción respecto a -RETORNO DE CARRO + SALTO DE LINEA-. Indica que existen 2 bytes no visibles adicionales para el salto a la siguiente línea. Véase más sobre secuencias de escape, pero para el ejemplo sólo usaremos dos:

Retorno de carro:\r
Salto de línea: \n

Donde se indica "2 x", es que existen dos saltos.
Pasemos a analizar paso a paso cada campo de la cebecera de la petición.

Realizamos petición para "mandar, fijar, poner" en el script "tratar-upload.php" los datos de la petición.

POST tratar-upload.php HTTP/1.1

Dirección completa del servidor desde donde realizamos la petición.

Host: localhost

Agente-navegador usado desde donde realizamos la petición.

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.16)

Tipos de datos que acepta el agente-navegador para procesar la respuesta una vez concluida la petición.

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Lenguajes aceptados para la respuesta por parte del navegador.

Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3

Tipos de codificación aceptados para la respuesta por parte del navegador.

Accept-Encoding: gzip,deflate

Conjunto de carácteres aceptados para la respuesta por parte del navegador.

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Representa el número máximo de segundos entre envío y respuesta de paquetes sobre una conexión persistente.

Keep-Alive: 300

Indica que el navegador soporta conexiones persistentes sobre una misma conexión TCP.

Connection: keep-alive

Indica desde donde procede la petición.

Referer: http://localhost/upload.html

Muy Importante.
Establece que la petición puede estar formada por diferentes partes de datos y se indica el separador (límite) entre las partes involucradas. Oséase, que cada archivo debe estar separado convenientemente por el límite establecido boundary. La serie numérica que le sigue está formada aleatoriamente y no sigue ningún tipo de lógica.

Content-Type: multipart/form-data; boundary=---------------------------265001916915724

Tamaño en bytes del conjunto de datos que vamos a enviar excluyendo la cabecera.

Content-Length: total_bytes_de_los_ficheros_incluyendo_los_delimitadores<2 x RETORNO DE CARRO + SALTO DE LINEA>

A continuación voy a explicar las partes de cada archivo que enviamos al servidor.

Indica el comienzo de una parte, osea, los datos de un archivo

-----------------------------265001916915724

Aquí se establece el nombre del campo del fichero especificado en el form y el nombre del archivo que vamos a enviar.

Content-Disposition: form-data; name="f1"; filename="archivo1.ext"

Tipos de datos que contiene el archivo. Normalmente binarios.

Content-Type: application/binary<2 x RETORNO DE CARRO + SALTO DE LINEA>

Los datos en bruto del fichero son colocados aquí, acabamos con un salto de línea.

Para terminar la retransmisión de datos hacia el servidor, debemos indicarlo con el siguiente campo.

-----------------------------265001916915724--

(nótese que acaba con dos guiones -- más retorno de carro y el salto de línea correspondiente.)

Ya creo que estamos listos para ver el código fuente del programa que desarrollé en Java para la subida de ilimitado número de archivos. El código se corresponde con la clase más significativa del programa, el uploader. He suprimido algunas partes del código para exponer más claramente lo que estamos tratando aquí.

Uploader.java

Si estás interesado en todo el desarrollo del applet, puedes ponerte en contacto conmigo.
Para poder usarlo correctamente, el applet está firmado para poder explorar el disco duro del cliente con los archivos que desea subir al servidor.

Implementando cliente DNS para resolver servidores MX (MAIL EXCHANGE) con C

A continuación listo el codigo fuente totalmente comentado para resolver servidores de correo saliente a partir de un email, un servidor DNS y el puerto usado por el servidor (normalmente el 53 por UDP).

Uso del programa:

DNS-MX.exe <Email> <Servidor DNS> <Puerto servidor DNS>

DNS-MX.c

Analizando la respuesta DNS

Procederemos a analizar la respuesta que nos devuelve el servidor DNS.

Voy a pasar a comentar sólo algunos campos que nos resultan de interés para la práctica que estamos realizando.

• Transaction ID: Como vemos, coincide el ID de la consulta con la de la respuesta.
• Answer RRs: Nos indica que el número de servidores tipo MX resueltos.
• Additional RRs: Son campos adicionales donde se muestran las direcciones IP de cada servidor MX resuelto.

Ahora vamos a desglosar los campos Answers donde se encuentran los servidores MX resueltos por el servidor DNS.

Datos de la estructura Answers:

• Name: gmail.com = 0xc00c. c0 indica que hay compresión y el siguiente byte establece el byte de desplazamiento donde se encuentra la información, osea: 0c, que en decimal se traduce a 12. En la posición 12 de la respuesta se encuentra lo que buscamos. Los primeros 12 bytes de la respuesta corresponden a parámetros de la consulta, el byte siguiente, osea, el 13, nos deja justo en el campo Name de la estructura Queries, que es nada más ni nada menos que: gmail.com. Todo este procedimiento se traduce como compresión.
• Type: MX = 0x000f. Indica el tipo de servidor (servidor de correo saliente)
• Class: IN = 0x0001. Indica la clase de servidor (servidor de internet)
• Time to live: 47 minutes, 52 secons = 0x00000b38. Marca de tiempo que establece el tiempo que puede ser el servidor cacheado hasta vovler a interrogar para resolverlos de nuevo.
• Data length: 27 = 0x000b. Indica el tamaño de la cadena en bytes del servidor resuelto.
• Preference: 5 = 0x0005. Indica preferencia de uso del servidor entre los resueltos.
• Mail exchange: gmail-smtp-in.l.google.com

Nos detenemos en el campo Mail exchange ya que merece la pena para analizar la compresión.

Este tipo de procedimiento se repite una y otra vez mientras se pueda hacer uso de la compresión.
Como ya dije, se hace uso de la compresión para dar una rápida respuesta y demorar lo menos posible en resolver las consultas de los clientes. Es un buen mecanismo pero un tanto engorroso, se deben de tener bien claros los conceptos porque en el capítulo siguiente veremos la implementación de un cliente DNS para resolver servidores tipo Mail exchange.

Analizando la consulta DNS

Hace algún tiempo, desarrollé un cliente DNS para resolver consultas tipo MX(MAIL EXCHANGE), que no son más que consultas para resolver  servidores de correo saliente a partir de un nombre de dominio.

Para obtener más información sobre DNS RFC 1035

La siguiente captura está realizada con wireshark para ilustrar un poco que campos intervienen a la hora de realizar una consulta DNS.

Voy a explicar un poco que significan los siguientes campos.

• Transaction ID (2 bytes): Identifica la consulta del cliente que debe conincidir con la respuesta del servidor.
• Flags (2 bytes): Son parámetros para la consulta a realizar, si es una consulta inversa, el mensaje está truncado, etc. De momento nos basta saber que la consulta a que hemos realizado es recursiva, es decir, si el servidor DNS al que hemos realizado la consulta no contiene la información que necesitamos, éste acude a otros servidores para obtener la respuesta.
• Questions (2 bytes): Número de consultas a realizar, por defecto sólo una.
• Answer RRs (2 bytes): Número de entradas que aparecen en la sección de respuesta, siempre a cero en la consulta.
• Authority RRs (2 bytes): Número de entradas que aparecen en la sección de autoridad, siempre a cero en la consulta.
• Additional RRs (2 bytes): Número de entradas que aparecen en la sección adicional, siempre a cero en la consulta.
• Queries
  Este campo especifica las consultas a realizar.
  En este caso es de 15 bytes
• Name (11 bytes): Nombre del dominio a consultar para obtener los servidores de correo saliente para enviar el mensaje
• Type (2 bytes): Tipo de consulta a realizar. En este caso es 0x000f para especificar que es tipo MX.
• Class (2 bytes): El tipo de consulta pertenece a internet, la más usada.

A excepción del campo Queries, la cabecera de la consulta DNS tiene siempre una constante de 12 bytes.
Vamos a ver al detalle el campo Name que contiene el dominio a consultar ya que resulta un tanto interesante en la forma en la que lo hace.

1	2	3	4	5	6	7	8	9	10	11
05	g	m	a	i	l	03	c	o	m	00

El dominio es gmail.com, y como vemos en la anterior tabla, los puntos '.' los sustituye por un campo numérico que indica la longitud del siguiente campo. El final de la cadena siempre acaba en cero.

Parece fácil, no?

En el siguiente capítulo veremos la respuesta que nos devuelve el servidor DNS y veremos también la compresión de los mensajes que es utilizada para ahorrar tamaño en el paquete y por consiguiente demorar lo menos posible para obtener un respuesta rápida.

Cómo emitir imágenes con la webcam en tu página web con PHP

El procedimiento que voy a explicar va a consistir en la captura de imágenes de la webcam cada X segundos y la posterior subida de la imagen a un servidor mediante FTP.

La receta:

• Yawcam (software para captura imágenes de la web cam)
• Máquina virtual de java (para Yawcam, ya que está desarrollado en Java)
• Servidor FTP.
• Y por supuesto, PHP ;)

Una vez te hayas hecho con todo, hay que configurar en Yawcam el intervalo de las capturas cada 5 segundos (a tu gusto) y el acceso al FTP.

Si ha detectado correctamente tu webcam, accede a Configuración->Editar configuración->Salida->FTP

• Tipo de archivo: JPG
• Calidad: 30% (no pongas un valor muy alto para que el tamaño de la imagen no sea excesivo
• Servidor FTP: mihosting.com
• Puerto: normalmente 21
• Usuario: miusuario
• Contraseña: micontraseña
• Directorio: /www/webcam (directorio absoluto)
• Nombre de archivo: webcam.jpg (el archivo se sube cada 5 segundos y sobreescribe el actual, si actualizamos la página que muestra el archivo de captura cada 5 segundos, obtenemos una secuencia casi real por streaming)
• Intervalo: 5 segundos (a tu gusto)

Bien, ya tenemos configurado el programa. Para activarlo, en el panel de control, FTP->Activar
Haz la prueba para ver si sube el archivo al servidor y se actualiza cada 5 segundos debidamente.

Ahora procederemos a crear el script PHP que se encargará de leer el archivo webcam.jpg y mostrarlo.

Aconsejo crear un archivo .htaccess en el directorio de las imagenes tomadas de la webcam sin permisos de lectura desde los clientes que intentan acceder al recurso donde se aloja el archivo webcam.jpg:

.htaccess

Order Deny,Allow
Deny from all
Options None
AllowOverride None

El siguiente script PHP va a leer el archivo webcam.jpg y lo va a devolver para insertarlo en una etiqueta img de html.

webcam.php

/**
* Aquí puedes incluir código para verificar si el cliente que está accediendo
* al recurso puede leer el archivo webcam.jpg o no
*/
$webcam = "webcam/webcam.jpg";
header("Content-Type: image/jpeg");
header("Content-Length: ".filesize($webcam));
readfile($webcam);

Ahora necesitamos el código html necesario para mostrar la imagen y que se actualice cada 5 segundos

webcam.html

<html>
<head>
<title>Probando webcam</title>
<!-- Le decimos al navegador que no almacene esta página en la caché -->
<meta http-equiv="Pragma" content="no-cache" />
<!-- No tiene fecha de expiración -->
<meta http-equiv="expires" content="-1" />
<!-- El navegador se refresca cada 5 segundos realizando peticiones una y otra vez a esta misma página para mostrar la imagen actualizada -->
<meta http-equiv="refresh" content="5" />
</head>
<body>
<img src="webcam.php" title="Sesión WebCam en directo" alt="Sesión WebCam en directo"/>
</body>
</html>

Y ya esta, es en esencia lo que necesitamos para poder emitir imágenes en semi-directo con nuestra webcam y verlas a través de nuestra página web.
Se puede elaborar de mejor forma dando acceso a usuarios registrados por ejemplo, para ello recurririamos a las variables de sesión para identificar si el usuario que solicita ver la webcam está logueado o no, pero bueno, eso os lo dejo a vosotros.

Espero os sea de utilidad.

Inyectar código directamente en la memoria de otro proceso con C

A continuación expongo el código fuente para cómo inyectar código directamente en la memoria de otro proceso remoto con C, se ha compilado con GNU GCC Compiler en el entorno Code::Blocks 8.02.

Me he tomado la molestia de comentar todo el código para que lo podáis perfeccionar, depurar, cambiar, etc, todo el procedimiento de inyección.

api.h

funcionInyectar.h

funcionInyectar.c


main.c


Espero os sea de utilidad.

Depurando pantallazos azules

En primer lugar, debemos de modificar el archivo boot.ini que se encuentra en la unidad raiz.

Los modificadores son parámetros para alterar la forma en la que inicia windows, a continuación muestro los que nos van a ser de utilidad

• /bootlog, crea un archivo de registro donde se almacena la secuencia de arranque de windows. El archivo se guarda en el directorio raiz de la instalación de windows y se llama ntbtlog.txt.


• /sos, nos muetra un listado de los drivers que va cargando en el arranque.

De tal forma que, nuestro boot.ini, quedará una cosa más o menos parecida a esta:

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect /bootlog /sos

(No copies lo anterior, es orientativo, tu sistema puede que no coincida con el anterior)

Otra forma de depurar pantallazos algo más engorrosa pero puede que más efectiva, es la que describo a continuación.

Este procedimiento es válido para analizar los archivos de volcado que windows genera al ocurrir una expceción grave en el sistema, que suelen encontrarse en %SystemRoot%\MEMORY.DMP

En primer lugar necesitamos el depurador de windows WinDbg y los símbolos de depuración para windows xp para que pueda determinar de que librería y función se trata cuando ocurre tal excepción.

Una vez nos hayamos hecho con el archivo de volcado:

• Abrimos WinDbg


• Cargamos volcado: "File -> Open Crash Dump"


• Especificamos el siguiente comando para que analice el archivo: !analyze -v

Nos arroja al detalle información de la excepción ocurrida, y es ahí donde debemos determinar que función y en que librería, driver, etc, se produce el error. Para ello basta con deshabilitar/desinstalar el componete que ocasiona el error y toca probar de nuevo.

Espero os sea de utilidad.

Descartando problemas de hardware/software comunes

Pues bien, estos problemas pueden ser debidos a:

1. Memoria RAM defectuosa.


2. Drivers incompatibles o inadecuados.


3. Programa del sistema básico de entradas y salidas erróneamente configurado, oséase, BIOS :P


4. Sobrecalentamiento del microprocesador o algún componente hardware.


5. Hardware defectuoso.


6. Software que realiza operaciones no permitidas o que llegan a desastibilizar el sistema.


7. Etc.

Ahora se nombrarán algunas posibles soluciones a los problemas anteriormente citados:

1. Realiza un chequeo de tus memorias RAM y asegurate de todas las direcciones se lean/escriban correctamente. Para ello, te recomiendo memtest86, es un programa gratuito diseñado para microprocesadores x86 que realiza un examen exhaustivo de todas las memorias RAM instaladas en el equipo.


2. Desinstala cualquier driver nuevo que hayas instalado. Hazlo bajo modo prueba de errores.


3. Restaura la configuración de la BIOS a su configuración original.


4. Observa la temperatura y voltajes del microprocesador y cercionate que son los valores adecuados. Comprueba que la fuente de alimentación está suministrando la energía necesaria al ordenador en sí. Realiza una limpieza interna e incluso ordena los cables para una correcta ventilación.


5. Si notas que algún componente falla en relación con alguna operación que realizas, desconéctalo.


6. Lo mismo que el paso anterior pero en relación con el software.


7. Si ya has hecho de todo y te has cercionado de que ningún componente está defectuoso, la única solución pasa por reinstalar tu sistema operativo o incluso algo mejor, formatear ^^. No obstante, puedes probar un comando que me ha sacado en más de una ocasión de un apuro,  sfc /scannow, comprueba que los archivos legítimos de windows siguen intactos y en sus versiones originales, para ello debes de insertar el cd de windows y posteriormente ejecutar el comando. Por probar que no quede!

Bueno, espero que te haya sido de utilidad, en el siguiente capítulo expondré como depurar los pantallazos azules de windows xp y poder orientarnos al error.