Jun 21

JPcap vs JNetPcap

No hace mucho comentaba que me había puesto a partir paquetes IP a bajo nivel, usando JPcap. Haciéndolo encontré un pequeño bug en la librería, el campo offset de la cabecera IP no se rellenaba correctamente, por lo que tuve que hacerme mi pequeño arreglo. Una vez hecho, todos felices y contentos.

Pero me ha salido un nuevo problema. Cuando el sistema operativo recibe los fragmentos IP de un paquete grande, tiene un pequeño timeout en el que espera recibir todos esos paquetes (creo que de 1 minuto aproximadamente). Si en 1 minuto no recibe todos los fragmentos, desecha el paquete y no lo entrega a las aplicaciones. En windows ese timeout se controla ¿cómo no?, con un valor del registro, en concreto IpReassemblyTimeout. Pero mira tú que 1 minuto me resulta escaso (tenemos un canal de comunicación muy lento, casi como un antiguo RS-232 de 9600 baudios y encima compartido) y no todas las versiones de windows hacen caso de ese valor de registro (casualmente la que nosotros usamos no lo hace).

Así que me toca reconstruir también los fragmentos con JPcap. Y me pongo a ello…. y encuentro un nuevo bug. Hay un flag en la cabecera IP que indica si ese fragmento es el último o hay más. Pues bien, JPcap no rellena bien en recepción ese flag ni los otros dos flags que le acompañan. Poniendo el arreglo del enlace ya se arregla el tema de los flags. Pero me sale un nuevo problema … no recibo el último fragmento … hasta que  llega un mensaje. Es como si JPcap se quedara el último paquete recibido y no lo entregara a la aplicación hasta que reciba uno nuevo. No sé si es eso, pero el caso es que si sólo envio un gran paquete UDP fragmentado, no recibo el último fragmento y no puedo recomponer el paquete UDP.

Así que me pongo a buscar alternativas a JPcap y me encuentro con JNetPcap. Con esta librería sólo he probado la reconstrucción de paquetes, pero me ha funcionado bien a la primera (o casi). La librería es un pelín más compleja de usar que JPcap, pero viene bastante mejor documentada en su página web, con más ejemplos y lo más importante, parece que funciona mejor.

De momento no voy a migrar el envío de fragmentos, pero creo que sí voy a reconstruirlos con esta librería, afortunadamente, ambas son compatibles y una misma aplicación puede usarlas simultáneamente.

Jun 03

Chrome vs Explorer

 Como he comentado más veces, estamos haciendo un portal web con mapa (Geoserver + Openlayers). En ese mapa debemos pintar las posiciones de los barcos (algo similar a http://www.localizatodo.com/mapa/ ). Geoserver ofrece dos tipos de Web Service para obtener los barcos y poder pintarlos en el mapa. Ojo, Geoserver no sabe los datos de los barcos, simplemente los lee de su base de datos y algún proceso externo tiene que rellenar dicha base de datos.

Uno de ellos, WFS, consiste en que a través del WebService y en formato XML te da los datos de los barcos (posición, velocidad, rumbo, nombre del barco, tipo de barco, etc). Es el navegador con javascript (y en concreto la librería OpenLayers), la encargada de dibujar los barcos sobre el mapa.

Pues bien, con esta aproximación y con sólo unos tres mil barcos para probar (la base de datos contiene algo menos de treinta mil), Chrome funciona perfectamente. Se puede hacer zoom en el mapa, desplazarlo y jugar con él sin notar ningún retraso importante en los refrescos. Pero Internet Explorer es otra cosa. Con tres mil barcos…. se queda colgado el navegador entero. En cuanto haces zoom, intentas mover el mapa o cualquier cosa, deja de refrescarse, deja de contestar y ni siquiera puedes abrir otras pestañas, cerrarlas, o cerrar el navegador. En fin, una diferencia importante de eficiencia de javascript entre internet explorer 8 y Chrome.

La solución al final usar el otro Web Service que ofrece Geoserver, el WMS. En este Web Service es el mismo Geoserver (el servidor), el que hace unas imágenes jpg (o el formato que elijamos) con el mapa y los barcos pintados encima. Esta imagen se sirve al explorador cuya única tarea consiste en pintarla. Aun así, Chrome sigue funcionando perfectamente, mientra que con internet explorer ya se puede trabajar sin problemas, pero se le sigue notando más "pastoso" a la hora de mover el mapa y hacer zoom.

Una pena que al ser el navegador más usado por la gente profana, nuestro requisito sea que funcione bien con internet explorer.