[pyar] Presentación y consulta (Sockets -> envío de datos )

[nicopixel]

> Es es el contexto que me falta.
>
> Por ejemplo, en un caso que me toco en el siglo pasado, se podia apagar
> los colectores. Pero lo importante no era la perdida de los mensajes que
> estaban en la cola en memoria. El problema era que las maquinas productoras
> de mensajes (centrales telefonicas) tenian un buffer limitado, y si la
> maquina colectora se apagaba, por digamos, n minutos, se perdian los
> mensajes PRODUCIDOS desde entonces por las maquinas productoras de
> mensajes, y lo que se perdia por estar en memoria y haber sido recibido
> ANTES del corte era infimo
>
> Como es tu contexto?
>
>

El contexto es el mismo que el tuyo, Centrales telefónicas! jaja
Lo que sucede es que hay varios modelos que ni siquiera tienen un buffer
para
almacenar llamadas mientras el colector se encuentra apagado.

Al momento de descargar los datos de la central telefonica, éstos dejan de
estar
en la maquina. Si en ese momento el colector se apaga y los datos no fueron
reenviados ni estan persistidos,
los mismos se pierden y ha pasado de que el cliente necesite cierta llamada
que....... 'se perdió'.
Y luego.. a buscar excusas :-)

A veces esos logs se necesitan para investigar ciertos hechos políticos por
ejemplo por lo que habría
que reducir la perdida de datos a la menor cantidad posible.

Actualmente el modulo que tengo en C  guarda todo lo recibido en un un
archivo "salida.txt". Luego hay
otra aplicacion "sender" que mueve salida.txt  a tmp.txt y lo intenta
enviar por completo,
si no envia todos los datos hasta el final del fichero, intenta enviar todo
nuevamente.
A todo esto el colector ya generó otro salida.txt y el sender repetirá el
proceso cada 1 segundo.

Funciona! pero me gustaría empezar a hacer las cosas de la mejor manera
posible
y en Python.









> Que recuerde, tu contexto tambien pedia la persistencia de lo recibido (en
> mi caso, se necesitaba que los mensajes enviados por las centrales
> telefonicas se grabaran en algun lado). En mi caso, dividimos el tema
>
> - Persistir el mensaje recibido para que no se pierda y sirva para
> analisis posterior
> del tema
> - El mensaje recibido debo enviarlo a algun lado para procesarlo en este
> momento
>
> Me imagino que un contexto moderno seria:
>
> - Estoy recolectando mensajes de Twitter.
> - Los que puedo recolectar, los persisto, para analisis posterior
> - Mientras, tambien los envio para procesar en tiempo real a algun lado
> - Si se apaga algun recolector, Lola Mento  :-)
>
> Nos leemos!
>
> Angel "Java" Lopez
> @ajlopez
>
>
>
> 2013/5/20 nicopixel <nicopixel en gmail.com>
>
>>
>>  Entonces, los productores encolan los datos y se olvidan, con lo que
>>> nunca se bloquean.
>>> El consumidor los levanta de esas colas y los guarda en la base. Yo
>>> haría que ese mismo hilo tome el más antiguo
>>> lo envíe y lo elimine.
>>>
>>
>> Si, me encantaría, el tema es que necesito que las colas esten
>> persistidas en el disco
>> ya que los dispositivos que tienen los "colectores" de datos pueden
>> llegar a ser apagados/reiniciados
>> y perderia la cola si ésta se encuentra en memoria. De ahi el tema de
>> persistir los datos.
>> Con sqlite intenté hacer eso, que un hilo colecte datos, los guarde y
>> otro hilo tome el mas antiguo,
>> lo envie, pero al intentar eliminarlo.... explota! (de allí mi problema
>> con la concurrencia).
>>
>>
>> > O mejor todavía, dependiendo de lo que signifique "enviar", lo encole
>> para que otro hilo lo envíe.
>>
>> "Enviar" es enviar a un servidor remoto. La aplicacion se conecta a
>> servidores, recibe datos y los reenvia
>> a otro lado. El tema es que no se pueden perder los datos recibidos y al
>> reenviarse deben recibir un ack.
>> Si no lo recibe, se queda reintentando.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>> Al quedar todas las operaciones en un solo hilo, las realizás en orden,
>>> los hilos que juntan datos nunca
>>> bloquean, y listo. El *peor* de los casos es que si el acceso a la base
>>> de datos es muy lento, se te van
>>> a ir encolando muchos datos, pero tener concurrencia probablemente no te
>>> solucionaría ese problema, tan sólo
>>> haría que sea más difícil de ver :-)
>>>
>>> Acá tenés un ejemplito:
>>>
>>>
>>> http://smherwig.blogspot.com.ar/2012/09/producer-consumer-model-with-python.html
>>>
>>> _______________________________________________
>>> pyar mailing list pyar en python.org.ar
>>> http://listas.python.org.ar/listinfo/pyar
>>>
>>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>>
>>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>>> Argentina - http://www.usla.org.ar
>>>
>>
>>
>> _______________________________________________
>> pyar mailing list pyar en python.org.ar
>> http://listas.python.org.ar/listinfo/pyar
>>
>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> Argentina - http://www.usla.org.ar
>>
>
>
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20130520/c71e3706/attachment.html>