Rzuciłbym okiem na evserver (http://code.google.com/p/evserver/) jeśli potrzebujesz tylko komety.

"obsługuje [] mało znane asynchroniczne rozszerzenie WSGI" i jest zbudowane wokół libevent. Działa jak czar i wspiera django. Rzeczywisty kod obsługi jest trochę brzydki, ale skaluje się dobrze, tak jak naprawdę jest asynchroniczny.

Użyłem evserver i obecnie przenoszę się na cyclone (tornado na twisted), ponieważ potrzebuję trochę więcej niż evserver offserów. Potrzebuję prawdziwego dwukierunkowego io (myśl socket.io (http://socket.io/)) i chociaż evserver mógł go obsługiwać, to myślałem, że łatwiej jest go reimplementować socket.io w cyclone (zdecydowałem się na cyclone zamiast tornado, ponieważ cyklon jest zbudowany na twisted, co pozwala na więcej transportów, które nie są zaimplementowane w twisted (i.C. zeromq)) Socket.io obsługuje websockets, Comet style polling i, znacznie więcej interseting, websockets opartych flash. Myślę, że w większości praktycznych sytuacji websockets + flash oparte websockets są wystarczająca do obsługi 99% (Wg adobe flash penetracja wynosi ok. 99% (http://www.adobe.com/products/player_census/flashplayer/version_penetration.html)) odwiedzający stronę (tylko osoby nie korzystające z Flasha muszą wrócić do jednego z socket.io its (less perfomant and resource hogging) Backup transports)

Należy jednak pamiętać, że websockets nie są transportem http dlatego umieszczenie ich za serwerami proxy bazującymi na http (np. haproxy w trybie http) przerywa połączenie. Lepiej podawać je na alternatywny adres ip lub port umożliwiający proxy w trybie tcp (np. haproxy w trybie tcp).

Aby odpowiedzieć na twoje pytania: (1) Jeśli nie potrzebujesz dwukierunkowego transportu longpolling oparte rozwiązania są wystarczająco dobre (wszystko, co robią, to utrzymać połączenie Otwarte). Sprawy stają się niepewne, gdy potrzebujesz, aby Twoje połączenie było stanowe lub musisz być w stanie zarówno wysyłać, jak i odbierać dane. W tym drugim przypadku socket.io pomaga. Jednak websockets są wykonane dla tego scenariusza i przy wsparciu Flasha jego dostępne do większość witryn internetowych (poprzez socket.io lub samodzielne, jednak socket.io ma dodatkową zaletę transportów kopii zapasowych dla osób, które nie chcą instalować Flasha)

(2) jeśli potrzebujesz tylko push, evserver jest najlepszym rozwiązaniem. Używa tych samych skryptów JavaScript po stronie klienta, co orbited. Else look at socket.io (wymaga to również serwera wspierającego, jedynym dostępnym Pythonem jest tornado.)

(3) to tylko jedna implementacja innego serwera. Jeśli dobrze przeczytałem, to tylko push. przesyłanie danych do klienta odbywa się poprzez wykonanie http equest z aplikacji na serwer nginx. (nginx wtedy dba o to, aby dotarli do klienta). Jeśli jesteś zaintrygowany w tym, spójrz na kundel2 (http://mongrel2.org/home) ma nie tylko obsługę longpolling, ale także websockets.(zamiast wysyłać żądanie http do kundla, tym razem korzystasz z obsługi ZeroMQ, aby przesłać dane do serwera kundla) (zwróć uwagę na brak entuzjazmu programisty dla websocketów i websocketów opartych na flashu. Szczególnie biorąc pod uwagę, że protokół websocket ma tendencję do ewolucji, w pewnym momencie możesz potrzebować przekodować obsługę WebSocket kungrel2 samodzielnie, zachowaj wsparcie dla WebSocket)

(4) wszystkie rozwiązania oprócz evserver zastępują wsgi czymś innym. Chociaż większość serwerów ma również wsparcie wsgi na szczycie tego "czegoś innego". Bez względu na to, jakie rozwiązanie wybierzesz, uważaj, aby jedno żądanie blokowania CPU lub w inny sposób io nie blokowało serwera. (albo potrzebujesz wielu instancje lub wątki).

(5) niezbyt istotne. Wszystkie rozwiązania zależą od niektórych niestandardowych programów obsługi do wysyłania (i, jeśli ma to zastosowanie, odbierania) danych do klienta. Wszystkie rozwiązania, o których wspomniałem, pozwalają na pisanie tych obsługi w Pythonie. Jeśli chcesz użyć zupełnie innego frameworka (node.js) następnie trzeba zważyć łatwość węzła.js (zakłada się, że jest łatwy, ale jest też raczej eksperymentalny, i znalazłem bardzo mało bibliotek, które są rzeczywiście stabilne) przeciwko wygody korzystania z twojego istniejąca baza kodu i dostępne biblioteki (np. jeśli Twoja aplikacja potrzebuje bloga, jest mnóstwo blogów django, które możesz podłączyć, ale żadnych dla node.js) nie patrz też na statystyki wydajności. jeśli nie planujesz wypchnąć głupich predefiniowanych danych (co robią wszystkie benchmarki) do klienta, przekonasz się, że rzeczywiste przetwarzanie danych dodaje dużo więcej kosztów niż nawet najgorsza implementacja io asynchroniczna. (Ale nadal chcesz korzystać z serwera opartego na asynchronicznych io, jeśli planujesz mieć wiele jednoczesnych klientów, threading po prostu nie ma na celu utrzymania tysięcy połączeń przy życiu)

(6) websockets oferuje dwukierunkową komunikację, long polling / comet tylko wypycha dane, ale nie akceptuje zapisów. (Socket.io symuluje to dwukierunkowe wsparcie za pomocą dwóch żądań http, jednego do longpoll, drugiego do wysyłania danych. Śledzi ich współzależność przez id (session), który jest częścią łańcucha zapytań obu żądań). websockets oparte na flash są podobne do rzeczywistych websockets (różnica polega na tym, że ich implementacja jest w pliku swf, a nie w przeglądarce). Ponadto protokół WebSocket nie jest zgodny z protokołem http; longpolling / Comet stuff robi (technicznie klient websocket wysyła żądanie aktualizacji do serwera websocket, zaktualizowany protokół nie jest już http)

Istnieje wsparcie dla WebSockets z django-websocket , ale niestety są z nim poważne problemy, aby go uruchomić; oto cytat z tej strony:

Disclaimer (co powinieneś wiedzieć używając django-websocket)

BIG FAT DISCLAIMER - w tej chwili jej technicznie Nie możliwe w jakikolwiek sposób, aby użyć websocket z WSGI. Jest to znany problem, ale nie można go obejść w sposób czysty z powodu niektórych decyzja projektowa, która została podjęta podczas pisania WSGI stadard. W tym czasie rzeczy takie jak Websockets itp. nie istniały i nie były przewidywalne.

...

Ale nie tylko WSGI jest czynnikiem ograniczającym. Samo Django zostało zaprojektowane wokół prostego scenariusza request to response bez Websockets. Oznacza to również, że dostarczenie standardowej implementacji websocket nie jest teraz możliwe dla django. Jednak działa to jakoś w niezbyt ładny sposób. Więc bądź świadomy że gniazda tcp mogą być torturowane podczas używania django-websocket.

Więc w tej chwili WSGI: no go; Django: prawie żadnego go, nawet z django-websockets; Zobacz także komentarz w oryginalnej Zapowiedzi autora :

Nie mogę powiedzieć, że to dobry pomysł. Wykonujesz długotrwałe połączenia w sposób, który będzie wymagał gwintowania. django-websocket wymaga konfiguracji wątków i nie będzie działać, jeśli masz procesy (bo po prostu masz za dużo procesy) ale wątki nie będą skalowane dla wielu połączeń w tym samym czasie, albo, więc to tylko fałszywe bezpieczeństwo. Potrzebujesz asynchronicznej platformy do długotrwałych rzeczy, a ja robię to, robiąc moją aplikację w Django i moją comet i websocket w Node.js

Osobiście, próbując użyć WebSockets (co spodziewam się w przyszłym roku), najpierw spróbowałbym kombinacji Twistedi Cyclone. Są zaprojektowane tak, aby radzić sobie z Websocketami i dobrze skalować. Jeśli napiszesz swoje poprawny kod aby usunąć niepotrzebne zależności od Django, powinieneś być w stanie użyć dużej części swojego kodu w pokręconym systemie. Jest to bardzo wyraźna przewaga nad używaniem węzła.js lub Comet lub dowolnego systemu w innym języku. Możesz również wykonać proste pchnięcie

Wreszcie, możesz również po prostu zdecydować, że jest to zbyt trudne i skorzystać z zewnętrznej usługi, aby zapewnić wsparcie push. To staje się kwestią wysłania prostego żądania JSON na ich serwery, zamiast martwić się o to, jak zrobić połączenie i jak będzie działać współbieżność i takie tam. Oczywiście, będziesz musiał za to zapłacić (choć obecnie może być za darmo w wersji Beta), ale nie musisz się martwić o szczegóły implementacji; nie będziesz miał pełnej mocy WebSockets w ten sposób - wystarczy wcisnąć wsparcie.

Re pytanie # 2, niedawno dostałem wycieczkę po wewnętrznej aplikacji Django, która używa komety w dużym stopniu, a Orbita była rozwiązaniem, które wybrali.