Comet server w pythonie
Michal M
Chciałbym aby można było też grać z przeglądarki. Potrzebna więc
technologia HTTP push czyli inaczej Comet.
Można to zrobić albo
1. Zaimplementować wszystko w pythonie
2. Comet server uruchomiony osobno działający jako proxy do servera
telnet (lub servera HTTP?)
Pierwsze byłoby lepsze. Jest ktoś w stanie coś na ten temat napisać
lub podać linki do jakichś materiałów?
Jeśli pierwsze jest poza zasięgiem to pozostaje opcja druga.
Znalazłem link jak uruchomić to jako proxy http://www.rkblog.rk.edu.pl/w/p/django-and-comet/
ale ja to muszę połączyć z grą, nie mam Django.
Jak widać w temacie jestem dość ciemny. Mógłby ktoś rzucić na to
trochę światła?
Pozdrawiam
Michał
Jan Kaliszewski
> Sprawa wygląda tak. Mam grę, która udostępnia dane przez telnet.
> Chciałbym aby można było też grać z przeglądarki. Potrzebna więc
> technologia HTTP push czyli inaczej Comet.
Jakiego typu interakcji (między userem-klientem a silnikiem na
serwerze) wymaga ta gra? Tzn. co sprawia, że uważasz, iż potrzeba
aż HTTP push, a nie tradycyjnej komunikacji HTTP? Pytam na
wypadek, gdyby miało się okazać, że jednak na ostatnia wystarczy.
pozdrawiam,
*j
Michal M
Generalnie myślę, że odpytywanie serwera 2 razy na sekundę przez
każdego klienta nie wchodzi w grę. :)
Na razie chcę mieć mud'a dostępnego przez www, ew. dorobić jakieś
graficzne detale (typu mapa).
Docelowo coś w tym guście http://www.ape-project.org/demos/7/mmorpg.html
Artur Lew
> Je�li pierwsze jest poza zasi�giem to pozostaje opcja druga.
Co do pierwszego to np tutaj widac ze da sie to zrobic dosc prosto:
http://stackoverflow.com/questions/1520953/basic-comet-in-python-using-just-std-lib
Drugie jednak jest lepsze bo standardowe ;)
Ja tez ostatnio implementuje cos co wymaga komunikacji serwer->przegladarka.
Tak sie sklada ze implementacja tego dzieki Orbited byla kiedys banalna.
Teraz chlopaki znacznie podniosly poprzeczke.
Na tyle ze nie znalazlem dobrego opisu zeby uruchomic najnowsza wersje
pod Windows :(
Dlatego zaczalem ogladac tez alternatywne rozwiazania.
Niestety ale WSGI nie pozwala na implementacje tego mechanizmu (a
chcialem cos w rodzaju kolejnej aplikacji zeby wpiac to w stos w Pylons)
wiec zostalo mi do wyboru albo Tornado (http://www.tornadoweb.org/) albo
web2py (http://www.web2py.com/).
> ale ja to musz� po��czy� z gr�, nie mam Django.
Django nie ma nic do tego.
Podpiecie sie do tego od strony dowolnego frameworka to cos w rodzaju
plastra :D
Sam generalnie wyslucham z zainteresowaniem czy ktos tutaj ma
doswiadczenie z czyms wiekszym wykorzystujacycm COMET.
--
Pozdrawiam
Artur Lew
arturdotlewatgmaildotcom
Michal M
> W dniu 2009-12-31 12:41, Michal M pisze:> Jeśli pierwsze jest poza zasięgiem to pozostaje opcja druga.
>
> Co do pierwszego to np tutaj widac ze da sie to zrobic dosc prosto:http://stackoverflow.com/questions/1520953/basic-comet-in-python-usin...
O! Super, być może to wystarczy. Jest jednak mały problemik. To nie
jest tylko wysyłanie do klienta. Ja muszę odpowiadać na zapytania. Tak
więc jak napisać, aby nie zamykał połączenia ale też żeby odpowiadał
na zapytania (POST)? Odpalić drugi na drugim wątku?
>
> Drugie jednak jest lepsze bo standardowe ;)
> Ja tez ostatnio implementuje cos co wymaga komunikacji serwer->przegladarka.
> Tak sie sklada ze implementacja tego dzieki Orbited byla kiedys banalna.
> Teraz chlopaki znacznie podniosly poprzeczke.
> Na tyle ze nie znalazlem dobrego opisu zeby uruchomic najnowsza wersje
> pod Windows :(
> Dlatego zaczalem ogladac tez alternatywne rozwiazania.
> Niestety ale WSGI nie pozwala na implementacje tego mechanizmu (a
> chcialem cos w rodzaju kolejnej aplikacji zeby wpiac to w stos w Pylons)
> wiec zostalo mi do wyboru albo Tornado (http://www.tornadoweb.org/) albo
> web2py (http://www.web2py.com/).
Fajna rzecz to też APE
> doswiadczenie z czyms wiekszym wykorzystujacycm COMET.
>
> --
> Pozdrawiam
> Artur Lew
> arturdotlewatgmaildotcom
Ja nie potrzebuję nic 'większego'. Na początek wystarczy proste.
Dziękuję za odpowiedź i pozdrawiam.
Bart Ogryczak
> Sprawa wygląda tak. Mam grę, która udostępnia dane przez telnet.
> Chciałbym aby można było też grać z przeglądarki.
http://pypi.python.org/pypi/orbited
Michal M
Tak, to było pierwsze co przeglądałem. Ale dla mnie wygląda zbyt
skomplikowanie i ma jakieś dziwne wymagania.
Patrzałem jeszcze na diesel ale goście napisali "comet" w tytule
nigdzie tego nie implementując (sami to przyznają).
Ostatnie co wygląda obiecująco to Tornado. I to mi się podoba oprócz
tego, że nie odpalę pod windą. Póki co do testów więc napisałem swój,
a na produkcyjnym (linuks) spróbuję Tornado.
Pozdrawiam.
Bart Ogryczak
> On 4 Sty, 16:24, Bart Ogryczak <b.ogryc...@gmail.com> wrote:
>
> > On Dec 31 2009, 12:41 pm, Michal M <mier...@swietochlowice.org> wrote:
>
> > > Sprawa wygląda tak. Mam grę, która udostępnia dane przez telnet.
> > > Chciałbym aby można było też grać z przeglądarki.
>
> >http://pypi.python.org/pypi/orbited
>
> Tak, to było pierwsze co przeglądałem. Ale dla mnie wygląda zbyt
> skomplikowanie
Eh? Skoro masz już wersję na TCP (telnet), to w czym problem? Orbited
daje ci dostęp do TCP z poziomu przeglądarki.
http://cometdaily.com/2008/07/01/sockets-in-the-browser/
> i ma jakieś dziwne wymagania.
AFAIR, wymaga Twisted, co jest bardzo standardowym frameworkiem.
Michal M
> Eh? Skoro masz już wersję na TCP (telnet), to w czym problem? Orbited
> daje ci dostęp do TCP z poziomu przeglądarki.http://cometdaily.com/2008/07/01/sockets-in-the-browser/
Problem taki, że wtedy to jest proxy do telneta. Nie daje to takich
możliwości (chyba) co wbudowany serwer.
Takie "TCP socket" (co jest tylko chwytliwą nazwą) to napisałem sam,
więc nie potrzebuję koniecznie.
Gdybym stawiał a proxy to raczej użyłbym APE. Wyglądało mi na lepiej
udokumentowane (dla mnie przyjaźniej).
> > i ma jakieś dziwne wymagania.
>
> AFAIR, wymaga Twisted, co jest bardzo standardowym frameworkiem.
Próbowałem się zaprzyjaźnić z Twisted ale bez wzajemności. Nie widzę
potrzeby włączania takiego rozbudowanego modułu.