Libertonia || Comments || No me gustan la Sindicación (los RSS)


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

No me gustan la Sindicación (los RSS) | 15 comentarios (15 temáticos, editoriales, 0 ocultos)

If-Modified-Since y Last-Modified. Poll y más (none / 0) (#1)
por jorginius ("jorginius" en Google Mail) a las Fri May 21st, 2004 at 08:16:29 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Esto significa que estamos bajandonos a nuestro equipo resumenes que en la mayoría de los casos no varía con respecto lo que ya teníamos.

No te los bajas de nuevo, a menos que el programador del cliente de sindicación y/o el administrador de la web sindicado hayan metido la pata. Se espera que con la sindicación uses GET condicionado a la fecha del último cambio en el resumen.

Del lado del cliente descargas la primera vez y de la respuesta que te da el servidor te quedas con la cabecera Last-Modified. Al siguiente intento, el cliente debería incluir en su petición una cabecera If-Modified-Since con el último valor de Last-Modified que obtuvo: en caso de que no haya habido cambios desde entonces, el servidor responderá con un 302 y no despachará de nuevo el resumen.

Esa es la idea, pero puede que el cliente esté mal escrito ignore las pistas que le da el servidor y se empeñe en volver a descargar lo que ya tiene. También puede ocurrir que el servidor esté mal configurado y o bien no incluya Etag y Last-Modified en sus respuestas o bien mienta en esos campos. Esto último es bastante común en todos esos servidores configurados mal apropósito para ¿boicotear? el proxy transparente de Telefónica (y cualquier otro proxy, de paso).

Por otra parte, la puntilla pedante:

El poll es bastante simple de utilizar. Aunque tiene 2 inconvenientes: el micro deja de trabajar para consultar cosas (perdida de potencia) y los buses de comunicaciones se llenan de mensajes del tipo: "¿tienes algo para mí?", "no".

Depende, no siempre "se pierde potencia". En ocasiones el mecanismo de poll es el más eficiente. Una interrupción implica un cambio de contexto y los cambios de contexto son caros en tiempo. En un sistema monoproceso gana de calle el polling frente a las interrupciones (quizás no en consumo, pero si en velocidad de respuesta) y en un sistema multiproceso puede que el polling sea una buena idea si el dispositivo es más rápido que un cambio de contexto, o si es crítico actualizar una salida lo más deprisa posible en función de lo que leamos de un dispositivo.

Perdón, perdón. Donde dije 302... (none / 0) (#3)
por jorginius ("jorginius" en Google Mail) a las Fri May 21st, 2004 at 08:38:01 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

...Sustituid mentalmente por 304. 302 es "Moved temporarily" y 304 es "Not modified" (que es de lo que se trata).

[ Padre ]

El fondo, mira el fondo B-) (none / 0) (#4)
por jamarier a las Sat May 22nd, 2004 at 12:13:23 AM CET
(Información Usuario) http://barbacana.net/blog/

Siempre es de agradecer las notas tecnológicas. Efectivamente, el proceso que he descrito es burdo y acepta optimizaciones. No es necesario bajarse el fichero si miramos las fechas (suponiendo que estén bien configuradas).

De todas formas aunque sea menor el tránsito, sigue existiendo el mismo. Sigue siendo una conexión abierta que el servidor ha de atender y si se hace una consulta cada media hora es un trasiego. Un usuario normal, a menos que sea muy ansioso, visita las páginas una vez al día o una cada dos dias. (De hecho, antes de usar RSS, usaba websec para que me avisase de las modificaciones en las páginas y lo activaba con cron una vez a la semana).

Respecto a lo de poll e interrupción, habría tanto que discutir ;-) depende de la complejidad del periférico, del controlador, potencia del controlador, de la frecuencia de barrido de periféricos (la del poll), de la frecuencia de la producción de la interrupción, coste de la subrutina de encuesta, coste de la entrada de la interrupción...

Simplemente lo que quería decir es que la idea es buena (la de la sindicación) pero que la implementación no es para tirar cohetes. Si yo me suscribo a una revista no es para tener que ir cada 30 minutos a preguntarle al quiosquero si ha llegado (por poco que tarde en hacerlo). Es para que cuando salga la revista me la lleven a casa.

-----
- Porque mañana será un gran día.
[ Padre ]

¿La alternativa? (none / 0) (#6)
por jorginius ("jorginius" en Google Mail) a las Sat May 22nd, 2004 at 11:13:11 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

De todas formas aunque sea menor el tránsito, sigue existiendo el mismo. Sigue siendo una conexión abierta que el servidor ha de atender y si se hace una consulta cada media hora es un trasiego.

Cierto, pero es que usando sólo HTTP como protocolo de transporte no se puede hacer mucho más. A menos que el servidor pueda iniciar conexiones de notificación en los clientes (y eso supone abrir puertos y olvidarse de nat), eso es lo que hay.

En cuanto al sistema de suscripción y notificiación que propones, la implementación que se me ocurre es usar un servicio universal que permita broadcast de mensajes, como Jabber. La sindicación funcionaría de esta manera: añades a tu roster el bot de tal o cual página y éste te avisa si estás presente, avisa a todo su roster, haciendo broadcast de mensajito de tipo "headline" ("headline" es una extensión del mensaje estándar que soportan algunos clientes como Jarl. Screenshot de Jarl leyendo headlines).

Desde el lado del cliente es perfecto, pero desde el lado del servidor no sé si sería muy adecuado (vaya por delante que no soy un experto en Jabber):

Supongamos un sitio web de noticias con un nivel medio de lectores de RSS (unos 10.000 distintos a diario). Eso supone un roster de 10.000 entradas.

El servidor Jabber mantiene una conexión abierta por cada servidor par en el que tengamos al menos un contacto en el roster pero esto no es lo peor, lo peor son los mensajes de presencia: cada vez que enviemos un titular, tendremos el tráfico de sendos mensajes XML (petición/respuesta) por cada contacto disponible en el roster, con sus esperas y la carga despachar 10.000 mensajes distintos en un lapso de tiempo pequeño. Cuando tengamos las respuestas de presencia, empieza el broadcast del mensaje headline (eso sin contar con que es "pseudo-broadcast").

En realidad no sé si esto supondría un problema para el servidor Jabber. JabberRss soporta algo parecido pero no sé su número de usuarios ni que hardware ni que tráfico mueve). Puede que sea peor el remedio que la enfermedad.

Por otra parte, el peso de un mensaje de presencia Jabber es similar al de una petición HTTP o al de una respuesta HTTP que no sirva página (como 304), luego si el tiempo de actualización del sitio es pequeño (Tipo Slashdot, por ejemplo) nos estamos complicando la vida con otro protocolo y otro servidor (desplazando la carga del servidor HTTP al de Jabber) para quedarnos igual que estábamos. Ahora estaremos en el caso en que es más eficiente el polling... Siempre que se haga con GET condicional.

Quizás dependiendo del sitio (SI tiene un número de visitas menos que X... SI tiene servidor de Jabber propio...) un sistema de suscripción como el que describo, "por interrupción", fuera útil. Habría que verlo, pero de todas formas ya no estamos usando sólo HTTP y eso puede ser un problema (cortafuegos que sólo dejan conexiones al puerto 80, tener que desplegar un servidor Jabber, etc).

[ Padre ]

No me gustan la Sindicación (los RSS) | 15 comentarios (15 temáticos, editoriales, 0 ocultos)

Menu

· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login


Nueva cuenta
Usuario:
Contraseña:

Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda