socket.io pokoje czy przestrzenie nazw?
Badam nodejs/socket. io na czacie w czasie rzeczywistym i potrzebuję porady przy wdrażaniu pokojów.
Który jest lepszy, używając przestrzeni nazw lub korzystając z funkcji pokoju, aby całkowicie odizolować od siebie rozmówców?
Jaka jest prawdziwa techniczna różnica między pokojami a przestrzenią nazw?
Czy jest jakaś różnica w wykorzystaniu zasobów?
3 answers
To właśnie przestrzenie nazw i pokoje mają wspólne (socket.io v0.9. 8-zauważ, że v1. 0 wymagało kompletnego przepisania, więc coś mogło się zmienić):
- obie przestrzenie nazw (io.of ('/nsp') ) i rooms (socket.join ('pokój')) są tworzone po stronie serwera
- wiele przestrzeni nazw i wiele pomieszczeń współdzielą to samo (WebSocket) połączenie
- serwer będzie przesyłać wiadomości przez przewód tylko do tych klienci , którzy połączyli się z / dołączyli do pokoju nsp/, tzn. nie jest to tylko filtrowanie po stronie klienta
Różnice :
-
przestrzenie nazw są połączone przez Klienta za pomocą
io.connect(urlAndNsp)(Klient zostanie dodany do tej przestrzeni nazw tylko wtedy, gdy już istnieje na serwerze) - Pokoje mogą być łączone tylko po stronie serwera (chociaż tworzenie API po stronie serwera, aby umożliwić klientom łączenie się, jest proste)
- przestrzenie nazw mogą być autoryzacja chroniona
- autoryzacja nie jest dostępna z pokojami , ale autoryzacja niestandardowa może być dodana do wyżej wymienionego, łatwego do utworzenia API na serwerze, w przypadku, gdy ktoś chce korzystać z pokoi
- Pokoje są częścią przestrzeni nazw (domyślnie 'globalna' przestrzeń nazw)
- przestrzenie nazw są zawsze zakorzenione w globalnym zasięgu
Aby nie mylić pojęcia z nazwą (pokój lub Przestrzeń nazw), użyję enklawa odnosząca się do pojęcia, a pozostałe dwie nazwy dla implementacji pojęcia. Więc jeśli
- potrzebujesz autoryzacji dla przedziału , przestrzenie nazw mogą być najłatwiejszą drogą do pokonania Jeśli chcesz hierarchicznie ułożone przedziały (maksymalnie 2 warstwy), użyj kombinacji przestrzeni nazw/pokoju
- Jeśli aplikacja po stronie klienta składa się z różnych części ,które (same nie dbają o przedziały, ale) muszą być oddzielone od siebie, użyj przestrzeni nazw.
Przykładem dla tego ostatniego byłaby duża aplikacja kliencka, w której różne moduły, być może opracowane osobno (np. socket.io niezależnie, są używane w tej samej aplikacji i chcą współdzielić jedno połączenie sieciowe.
Nie mając tego w rzeczywistości, wydaje mi się, że jeśli potrzebujesz tylko prostych przedziałów w swoim projekcie do oddzielania i grupowania wiadomości, oba są w porządku.
Nie wiem, czy to odpowiada twoje pytanie, ale badania prowadzące do tej odpowiedzi przynajmniej pomogły mi zobaczyć jaśniej.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-08-20 01:49:26
To stare pytanie, ale po przeprowadzeniu pewnych badań na ten temat stwierdzam, że przyjęta odpowiedź nie jest jasna w ważnym punkcie. Według samego Guillermo Raucha (zobacz link ): chociaż teoretycznie możliwe jest dynamiczne tworzenie przestrzeni nazw w uruchomionej aplikacji, używasz ich głównie jako predefiniowanych oddzielnych sekcji aplikacji. Jeśli z drugiej strony musisz tworzyć przedziały ad hoc, w locie, aby pomieścić grupy użytkowników / połączeń, najlepiej jest użyć pokoje.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-06-24 13:40:21
To zależy, co chcesz zrobić.
Główną różnicą jest to, że pokoje są trudniejsze do wdrożenia. Musisz zrobić metodę łączenia pokoi z każdym przeładowaniem strony.
Z przestrzeniami nazw wystarczy wpisać var example = io.connect('http://localhost/example'); w swoim kliencie javascript, a Klient zostanie automatycznie dodany do przestrzeni nazw.
Przykład wykorzystania:
- pokoje: prywatny czat.
- przestrzenie nazw: czat strony.