Sockets no bloqueantes en Python

Hola a todos. El uso de sockets es sin duda uno de los recursos más utilizados que hay, y también uno de los peor utilizados.

Los sockets pueden configurarse como bloqueantes (por defecto) o hacerlos no bloqueantes mediante "fcntl" con el "flag" O_NONBLOCK. Y la diferencia es brutal.

Un socket bloqueante detendrá la ejecución del programa cuando se haga una llamada a "recv" y no haya datos para recibir. Y cuando se reciban los datos la ejecución continuará.

Mientras que un socket bloqueante, al hacer "recv" si hay datos se obtienen y si no los hay se devuelve una excepción con un valor "errno" de 11 (EAGAIN), que nos indicará básicamente un "prueba otra vez".

Pues bien, en un programa con sockets supuestamente bloqueantes vi que se comportaban como no bloqueantes sin razón aparente y he tardado 3 días en encontrar la solución.

El problema era debido al "timeout" por defecto. Me explico. En Python el "timeout" por defecto para los sockets está establecido a "None". Esto significa que si se intenta establecer una conexión con un host remoto y la conexión no se establece vaya usted a saber por qué, el programa se queda esperando indefinidamente ya que no hay un timeout.

Así, que en su día hice el cambio de establecer un "timeout" por defecto de 30 segundos. Y un tiempo después (hace 3 días), se detectó un problema derivado de esta decisión.

Y es que al establecer el timeout los sockets se vuelven no bloqueantes. Pero es más, muchos ni siquiera esperan esos 30 segundos.

¿Que cómo es esto posible? Porque no todos los sockets son del mismo tipo ni se usan para lo mismo.

Los sockets que establecen una conexión con un host remoto sí funcionan correctamente (con su timeout de 30 segundos), pero los sockets que se utilizan para la comunicación entre procesos con la librería "multiprocessing", estos funcionan como sockets no bloqueantes y no respetan el timeout de 30 segundos.

Así que la comunicación entre procesos "con multiprocessing.Pipe", y "multiprocessing.Listener" (usado dentro "multriprocessing,reduce_handle"), sencillamente no funcionaba.

Con lo que el resultado es que he tenido que quitar el timeout por defecto de 30 segundos, dejarlo como "None", y poner el timeout de 30 segundos sólo a aquellos sockets que me interesaban.

RESUMIENDO: No se puede establecer un timeout por defecto si usas comunicación entre procesos con la librería "multiprocesing"

Salu2 a to2

La seguridad en Java

Hola chicos, desde que Oracle absorvió a Sun Microsystems la seguridad de Java no para de ponerse en entre dicho y por supuesto de incrementarse.

La cuestión es que mes tras mes se encuentran vulnerabilidades en Java, y mes tras mes los chicos de Oracle no sólo arreglan estos problemas, sino que están endureciendo las medidas de seguridad para paliar los que puedan aparecer en el futuro.

Así, mientras que en Java 7 había 3 niveles seguridad: baja, media y alta. En Java 8 tenemos: media, alta y muy alta. Con lo que en Java 9 tendremos: alta, muy alta y Fernando Romay.

¿Y cuál es el problema de todo esto? Que nos obliga a los programadores a ir modificando los applets de Java según endurecen las políticas de seguridad.

Como ya no valen los certificados autofirmados, se necesita un certificado firmado por una entidad aseguradora de confianza (que hay que pagar). Además, el fichero "Manifest" del interior del JAR tiene varios campos donde hay que especificar la URL de la web donde estará el applet. Y como se pueden poner "*", pues se acabó el compilar una vez y utilizarlo donde quieras. Ahora hay que firmar cada applet para cada web.

 http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html

Y si ha esto le añadimos la seguridad de HTTPS, os daréis cuenta de que el applet no se descarga de una web cuyo certificado HTTPS no sea correcto.

Así que el aumento de la seguridad de Java es un engorro para los programadores, pero también para los usuarios. Usuarios que ven que se les obliga a actualizar la máquina virtual Java cada mes. Usuarios que ven como sus páginas web que están un poco desfasadas dejan de funcionar al no poderse ejecutar los applets. Y usuarios que al fin y al cabo no tienen los conocimientos informáticos necesarios para entender a qué viene tanto problema de seguridad.

Y para dar una nota de humor me gustaría colgar aquí el mítico video de "Javapocalypse":

RESUMIENDO: Vaya coñazo que es tener que actualizar Java y los applets cada dos por tres.

Salu2 a to2

Wine para windows?

Hola a todos, recientemente he visto que ciertas personas han empezado un proyecto para portar Wine a Windows.

¿Para qué? Pues para lograr una mejor compatibilidad con aplicaciones "legacy" de la que tiene WoW64.

La verdad es que me parece una gran idea y pienso que merece la pena echarle de cuando en cuando un ojo a este proyecto a ver qué tal evoluciona.

Hoy por hoy parece que las opciones para utilizar en un Windows moderno (como Windows 7) aplicaciones legacy que funcionaban en un Windows XP son:

• WoW64 (incluido en Windows de 64 bits)
• Windows XP mode (se instala un Virtual PC y se ejecuta la aplicación en él)
• Herramientas de virtualización de aplicaciones tipo Ulteo OVD

El uso de herramientas tipo Ulteo OVD puede servir si la aplicación se puede ejecutar bajo Wine en Linux. Es una buena solución ya que no tendría coste de licencias.

Salu2 a to2