Re: [python] Roboti, REST, Flask?

2015-09-29 Tema obsahu Petr Messner 
Zajímavý kus kódu. Co se stane, když se server restartuje, zůstane stav
zámků zachován? Co se stane, když klient požádá o acquire a musí čekat,
protože zámek má již někdo jiný, ale zrovna v tu chvíli vypadne síť,
spojení se ukončí a recv() vrátí prázdný řetězec?

Když už řešit zamykání takhle síťově, tak aspoň pořádně :) Viz např. Redis (
http://antirez.com/news/77) Apache Zookeeper, Apache Helix...

Bohužel, distribuované algoritmy nejsou tak jednoduché, že by do
"normálního" algoritmu stačilo přidat sokety.

PM

Dne 29. září 2015 15:30 Pavel Schön  napsal(a):

> Ahoj,
>
> dovolim si navrhnout pure python reseni na strane serveru zalozene na
> threadingu a lockach. Kdysi jsem napsal jednoduchy lock manager. Viz:
>
>
> http://code.activestate.com/recipes/578194-distributed-lock-manager-for-python/
>
> Ve zkratce:
>
> - na serveru bezi TCP daemon (./dlm.py), ktery obsluhuje klienty.
> - na klienty umistis tentyz soubor dlm.py, ktery si klientska aplikace
> importne a vola podle potreby.
>
> Aplikace potom funguje velmi podobne, jako bys programoval s mutexy.
> ___
> Python mailing list
> python@py.cz
> http://www.py.cz/mailman/listinfo/python
>
> Visit: http://www.py.cz
>
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

2015-09-29 Tema obsahu Pavel Schön 
Ahoj,

dovolim si navrhnout pure python reseni na strane serveru zalozene na 
threadingu a lockach. Kdysi jsem napsal jednoduchy lock manager. Viz:

http://code.activestate.com/recipes/578194-distributed-lock-manager-for-python/

Ve zkratce:

- na serveru bezi TCP daemon (./dlm.py), ktery obsluhuje klienty.
- na klienty umistis tentyz soubor dlm.py, ktery si klientska aplikace importne 
a vola podle potreby.

Aplikace potom funguje velmi podobne, jako bys programoval s mutexy.
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

2015-09-29 Tema obsahu Honza Král 
Psal jsem to tehdy, pisu to i ted - tohle reseni je naprosto nevhodne,
nema zadne reseni konkurentniho pristupu. Neni thread safe napriklad,
coz ho naprosto diskvalifikuje jako implementace zamku. Nehlede na to,
ze je to reimplementace kola.
Honza Král
E-Mail: honza.k...@gmail.com
Phone:  +420 606 678585


2015-09-29 15:30 GMT+02:00 Pavel Schön :
> Ahoj,
>
> dovolim si navrhnout pure python reseni na strane serveru zalozene na 
> threadingu a lockach. Kdysi jsem napsal jednoduchy lock manager. Viz:
>
> http://code.activestate.com/recipes/578194-distributed-lock-manager-for-python/
>
> Ve zkratce:
>
> - na serveru bezi TCP daemon (./dlm.py), ktery obsluhuje klienty.
> - na klienty umistis tentyz soubor dlm.py, ktery si klientska aplikace 
> importne a vola podle potreby.
>
> Aplikace potom funguje velmi podobne, jako bys programoval s mutexy.
> ___
> Python mailing list
> python@py.cz
> http://www.py.cz/mailman/listinfo/python
>
> Visit: http://www.py.cz
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

2015-09-29 Tema obsahu Pavel Schön 
Moje knihovna nikdy nebyla nasazena v produkci, je to ciste experimentalni 
zalezitost, hricka pro studijni ucely. Autor puvodniho dotazu hleda neco pro 
studijni a vyukove ucely, pokud se nepletu.

Server si v zadnem pripade nepamatuje stav zamku pri restartu, klientska cast 
neresi vypadky spojeni, neimplementuje reconnect apod. Pokud nastane chyba v 
TCP, na strane klienta se vyhodi vyjimka socket.error a je jen na nem, jak se 
zachova. 

Knihovna take neresi deadlock, ale to ani normalni threading neresi deadlocky. 
Jejich predchazeni je uz mimo ramec teto diskuze.

BTW, nad jednoduchym lockem lze stavet vyssi primitiva, semafory apod.


Dne úterý 29. září 2015 15:51:15 UTC+2 Petr Messner napsal(a):
> Zajímavý kus kódu. Co se stane, když se server restartuje, zůstane stav zámků 
> zachován? Co se stane, když klient požádá o acquire a musí čekat, protože 
> zámek má již někdo jiný, ale zrovna v tu chvíli vypadne síť, spojení se 
> ukončí a recv() vrátí prázdný řetězec?
> 
> 
> Když už řešit zamykání takhle síťově, tak aspoň pořádně :) Viz např. Redis 
> (http://antirez.com/news/77) Apache Zookeeper, Apache Helix...
> 
> 
> Bohužel, distribuované algoritmy nejsou tak jednoduché, že by do "normálního" 
> algoritmu stačilo přidat sokety.
> 
> 
> PM
> 
> 
> Dne 29. září 2015 15:30 Pavel Schön  napsal(a):
> Ahoj,
> 
> 
> 
> dovolim si navrhnout pure python reseni na strane serveru zalozene na 
> threadingu a lockach. Kdysi jsem napsal jednoduchy lock manager. Viz:
> 
> 
> 
> http://code.activestate.com/recipes/578194-distributed-lock-manager-for-python/
> 
> 
> 
> Ve zkratce:
> 
> 
> 
> - na serveru bezi TCP daemon (./dlm.py), ktery obsluhuje klienty.
> 
> - na klienty umistis tentyz soubor dlm.py, ktery si klientska aplikace 
> importne a vola podle potreby.
> 
> 
> 
> Aplikace potom funguje velmi podobne, jako bys programoval s mutexy.
> 
> 
> 
> ___
> 
> Python mailing list
> 
> pyt...@py.cz
> 
> http://www.py.cz/mailman/listinfo/python
> 
> 
> 
> Visit: http://www.py.cz

___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

2015-09-29 Tema obsahu Honza Král 
2015-09-29 16:28 GMT+02:00 Pavel Schön :
> Moje knihovna nikdy nebyla nasazena v produkci, je to ciste experimentalni 
> zalezitost, hricka pro studijni ucely. Autor puvodniho dotazu hleda neco pro 
> studijni a vyukove ucely, pokud se nepletu.

Obzvlast pro vyukove ucely je skutecne vhodne vybrat dobra reseni, v
tomto pripade tedy neco ze std knihovny nebo neco co funguje a plni
sliby

Nejhorsi co se muze stat je, ze se nekdo nauci spatne postupy a
principy, proto je vzdy dulezite, obcas i za cenu komplexity (django
vs flask) nebo extra zavislosti (gunicorn nebo twisted na normalni
server vs custom tcp socket), zvolit reseni ktere podporuje dobre
navyky. V tomhle pripade je dobry navyk i nevynalezat kolo.

> Server si v zadnem pripade nepamatuje stav zamku pri restartu, klientska cast 
> neresi vypadky spojeni, neimplementuje reconnect apod. Pokud nastane chyba v 
> TCP, na strane klienta se vyhodi vyjimka socket.error a je jen na nem, jak se 
> zachova.
>
> Knihovna take neresi deadlock, ale to ani normalni threading neresi 
> deadlocky. Jejich predchazeni je uz mimo ramec teto diskuze.
>
> BTW, nad jednoduchym lockem lze stavet vyssi primitiva, semafory apod.
>
>
> Dne úterý 29. září 2015 15:51:15 UTC+2 Petr Messner napsal(a):
>> Zajímavý kus kódu. Co se stane, když se server restartuje, zůstane stav 
>> zámků zachován? Co se stane, když klient požádá o acquire a musí čekat, 
>> protože zámek má již někdo jiný, ale zrovna v tu chvíli vypadne síť, spojení 
>> se ukončí a recv() vrátí prázdný řetězec?
>>
>>
>> Když už řešit zamykání takhle síťově, tak aspoň pořádně :) Viz např. Redis 
>> (http://antirez.com/news/77) Apache Zookeeper, Apache Helix...
>>
>>
>> Bohužel, distribuované algoritmy nejsou tak jednoduché, že by do 
>> "normálního" algoritmu stačilo přidat sokety.
>>
>>
>> PM
>>
>>
>> Dne 29. září 2015 15:30 Pavel Schön  napsal(a):
>> Ahoj,
>>
>>
>>
>> dovolim si navrhnout pure python reseni na strane serveru zalozene na 
>> threadingu a lockach. Kdysi jsem napsal jednoduchy lock manager. Viz:
>>
>>
>>
>> http://code.activestate.com/recipes/578194-distributed-lock-manager-for-python/
>>
>>
>>
>> Ve zkratce:
>>
>>
>>
>> - na serveru bezi TCP daemon (./dlm.py), ktery obsluhuje klienty.
>>
>> - na klienty umistis tentyz soubor dlm.py, ktery si klientska aplikace 
>> importne a vola podle potreby.
>>
>>
>>
>> Aplikace potom funguje velmi podobne, jako bys programoval s mutexy.
>>
>>
>>
>> ___
>>
>> Python mailing list
>>
>> pyt...@py.cz
>>
>> http://www.py.cz/mailman/listinfo/python
>>
>>
>>
>> Visit: http://www.py.cz
>
> ___
> Python mailing list
> python@py.cz
> http://www.py.cz/mailman/listinfo/python
>
> Visit: http://www.py.cz
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

2015-09-29 Tema obsahu Pavel Schön 
V tom se asi neshodneme. Nespatřuji nic špatného na tom napsat si vlastní TCP 
protokol založený na socketu z stdlib.

Zastávám názor, že je dobré rozumět a učit se věci pěkně odspodu. Ono i to 
Django nebo Flask takto vznikl. Na začátku nebylo nic a potom byl framework.

Uvedu vlastní zkušenost. Ve svém stávajícím zaměstnání jsem čekal několik 
měsíců na memcached (z legal důvodů). Bylo rychlejší napsat si vlastní 
memcached-like service (dva dny práce) a až mi byl memcached dodán, bylo snadné 
je prohodit.

Nechme na tazateli, jestli si vybere all-in-one řešení na jednoduchou věc, nebo 
si vytvoří vlastní "from scratch" a přitom se třeba i něco naučí. Ani jedna 
cesta není špatná.


> Obzvlast pro vyukove ucely je skutecne vhodne vybrat dobra reseni, v
> tomto pripade tedy neco ze std knihovny nebo neco co funguje a plni
> sliby
> 
> Nejhorsi co se muze stat je, ze se nekdo nauci spatne postupy a
> principy, proto je vzdy dulezite, obcas i za cenu komplexity (django
> vs flask) nebo extra zavislosti (gunicorn nebo twisted na normalni
> server vs custom tcp socket), zvolit reseni ktere podporuje dobre
> navyky. V tomhle pripade je dobry navyk i nevynalezat kolo.
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Roboti, REST, Flask?

2015-09-29 Tema obsahu Jan Bednařík 
2015-09-11 10:29 GMT+02:00 Marek Nožka :

> Ahoj
>
> Potřeboval bych malou radu. Učím programování(Python) na SŠ. Takže jsem
> vymyslel(okoukal), že si budeme hrát na Roboty. Bude to tahová hra.
> Jednotliví roboti(studenti) se připojí k serveru a budou mezi sebou
> soutěžit
> o nejlepší algoritmus, který projde bludištěm podle zadaných pravidel.
>
> Na serverovou část jsem chtěl použít Flask a vytvořit jednoduché REST API.
> Řeším ale jak mám obsloužit více klientů tak, aby na sebe navzájem počkali.
> Každý klient by měl říct, kam táhne. Ale odpověď můžu poslat až potom, co
> všichni pošlou požadavek. Napadli mě dvě řešení.
>
> 1) Klient pošle požadavek a čeká na odpověď. Stream odpovědi se ale zastaví
>a čeká se až se ozvou další klienti. Tohle nevím jak bych ve Flasku
>udělal -- pokud to tedy vůbec jde. Pokoušel jsem se to vygooglit ale na
>nic kloudného jsem nepřišel.
>


Ahoj. Tohle se ti ve Flasku, Djangu, aj. synchronních frameworcích bude
dělat špatně. Použiješ-li asynchronní aiohttp, můžeš efektivně obsluhovat
všechny requesty z Robotů "paralalně" (můžou paralelně čekat s odpovědí).
Složitost implementace s aiohttp je zhruba stejná jako ve Flasku.

http://aiohttp.readthedocs.org/en/stable/



Nicméně na tento problém se REST, respektive HTTP, zrovna moc nehodí (leda
ty websockety). Vhodnější by bylo použít Pub/Sub. Měly by stačit dva topicy
(channely), něco jako:

1. Round
 - hra na něj dělá publish povelu, že je možné táhnout další kolo
 - všichni roboti sem dělají subscribe a reagují na povel

2. Move
 - hra se sem dělá subscribe a reaguje na tahy robotů
 - roboti sem dělají publish tahů

Pro jednoduchost rozchození můžeš použít jako Pub/Sub broker třeba Redis.
Má dobrou knihovnu jak pro asynchronní Pyhon aioredis, stejně tak pro
klasický synchronní přístup redis-py.

https://github.com/aio-libs/aioredis
https://github.com/andymccurdy/redis-py

Honza



2) Klient pošle požadavek a za nějakou chvilku se zeptá jestli má
>server už odpověď. To je zase více složitosti na straně klienta.
>
> Protože jsem nic podobného zatím nikdy nedělal, budu vděčný za každou
> připomínku, poznámku nebo radu. Co za knihovnu/framework byste mi
> doporučovali.
>
> Dky
>Marek
>
> --
>  @ @ @ Marek Nožka
>  '.@
>  :*`@   email: marek <@t> tlapicka  net
>  `*'   jabber: tlapicka <@t> mitranet  cz
>   ::  web: http://tlapicka.net/
>   `'
>   `'   Powered by Debian GNU/Linux
>   `.**'
> ¨¨
> ___
> Python mailing list
> python@py.cz
> http://www.py.cz/mailman/listinfo/python
>
> Visit: http://www.py.cz
>
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz