Pokoje socket.io czy przestrzeń nazw?

Badam nodejs / socket.io pod kątem czatu w czasie rzeczywistym i potrzebuję porady dotyczącej wdrażania pokoi.

Co jest lepsze, używając przestrzeni nazw lub funkcji pokoju, aby całkowicie odizolować grupy rozmówców od siebie?

jaka jest prawdziwa różnica techniczna między pokojami a przestrzenią nazw?

Czy jest jakaś różnica w wykorzystaniu zasobów?

Oto, co mają wspólne przestrzenie nazw i pokoje (socket.io v0.9.8 - należy pamiętać, że wersja 1.0 wymagała całkowitego przepisania, więc wszystko mogło się zmienić):

• Po stronie serwera tworzone są zarówno przestrzenie nazw ( io.of ('/ nsp') ), jak i pokoje ( socket.join ('pokój') )
• Wiele przestrzeni nazw i wiele pokoi korzysta z tego samego połączenia (WebSocket)
• Serwer będzie przesyłał wiadomości przez sieć tylko do tych klientów, którzy połączyli się z / dołączyli do nsp / pokoju, tj. Nie jest to tylko filtrowanie po stronie klienta

Te różnice :

• przestrzenie nazw są połączone przez klienta za pomocą io.connect(urlAndNsp)(klient zostanie dodany do tej przestrzeni nazw tylko wtedy, gdy istnieje już na serwerze)
• pokoje można łączyć tylko po stronie serwera (chociaż utworzenie API po stronie serwera, aby umożliwić dołączanie klientów, jest proste)
• przestrzenie nazw mogą być chronione autoryzacją
• autoryzacja nie jest dostępna dla pokoi , ale można dodać autoryzację niestandardową 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 jest to „globalna” przestrzeń nazw)
• przestrzenie nazw są zawsze zakorzenione w zakresie globalnym

Aby nie mylić pojęcia z nazwą (pomieszczeniem lub przestrzenią nazw), użyję przedziału, aby odnieść się do pojęcia, a pozostałe dwie nazwy dla implementacji tego pojęcia. Więc jeśli ty

• wymagają autoryzacji na przedział , przestrzenie nazw mogą być najłatwiejszą drogą
• jeśli chcesz mieć przedziały z hierarchicznymi warstwami (maksymalnie 2 warstwy), użyj kombinacji przestrzeń nazw / pomieszczenie
• Jeśli aplikacja po stronie klienta składa się z różnych części, które (same w sobie nie dbają o przedziały, ale) muszą być od siebie oddzielone, użyj przestrzeni nazw.

Przykładem tego ostatniego może być duża aplikacja kliencka, w której różne moduły, być może opracowane oddzielnie (np. Strony trzeciej), z których każdy niezależnie korzysta z socket.io, są używane w tej samej aplikacji i chcą współużytkować pojedyncze połączenie sieciowe.

Nie mając tego do czynienia z testem porównawczym, wydaje mi się, że jeśli potrzebujesz w swoim projekcie tylko prostych przedziałów do oddzielania i grupowania wiadomości, jeden z nich jest w porządku.

Nie jestem pewien, czy to odpowiada na twoje pytanie, ale badania prowadzące do tej odpowiedzi przynajmniej pomogły mi lepiej zrozumieć.

To stare pytanie, ale po przeprowadzeniu badań na ten temat stwierdzam, że zaakceptowana odpowiedź nie jest jasna w ważnym punkcie. Według samego Guillermo Raucha ( patrz link ): chociaż teoretycznie możliwe jest dynamiczne tworzenie przestrzeni nazw w działającej aplikacji, używasz ich głównie jako wstępnie zdefiniowanych 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 korzystać z pokoi.

To zależy od tego, co chcesz zrobić.

Główna różnica polega na tym, że pomieszczenia są trudniejsze do wykonania. Musisz określić metodę dołączania do pokoi przy każdym przeładowaniu strony.

Dzięki przestrzeniom nazw wystarczy napisać var example = io.connect('http://localhost/example');w swoim kliencie javascript, a klient zostanie automatycznie dodany do przestrzeni nazw.

Przykład wykorzystania:

• pokoje: czat prywatny.
• przestrzenie nazw: czat strony.

Pokoje i przestrzenie nazw segmentują komunikację i grupują pojedyncze gniazda.

Transmisja do pokoju lub przestrzeni nazw nie dotrze do wszystkich, tylko do członków.

Różnica między przestrzeniami nazw a pokojami jest następująca:

• Przestrzenie nazw: są zarządzane w interfejsie użytkownika, co oznacza, że ​​użytkownik lub atakujący łączy się przez interfejs użytkownika, a łączenie i rozłączanie jest zarządzane tutaj.
• Pokoje: są zarządzane w zapleczu, co oznacza, że ​​serwer przypisuje dołączanie i opuszczanie pokoi.

Różnica polega głównie na tym, kto nimi zarządza

Aby zdecydować, czego użyć, musisz zdecydować, czy segmentacja ma być zarządzana w interfejsie użytkownika, czy w zapleczu

Przestrzenie nazw umożliwiają tworzenie obiektów o tej samej nazwie, ale byłyby one oddzielne, ponieważ będą znajdować się w różnych przestrzeniach nazw, zwanych inaczej zakresami.

To jest ten sam proces myślowy, który powinieneś mieć z przestrzeniami nazw Socket.IO. Jeśli budujesz modułową aplikację internetową Node, będziesz chciał określić przestrzeń nazw różnych modułów. Jeśli spojrzysz wstecz na nasz kod przestrzeni nazw, zobaczysz, że mogliśmy nasłuchiwać dokładnie tych samych zdarzeń w różnych przestrzeniach nazw. W Socket.IO zdarzenie connection w domyślnym połączeniu i zdarzenie połączenia w przestrzeni nazw / xxx są różne. Na przykład, jeśli masz czat i system komentarzy w swojej witrynie i chcesz, aby oba działały w czasie rzeczywistym, możesz dla nich przestrzeń nazw. Pozwala to na zbudowanie całej aplikacji Socket.IO, która żyje tylko w swoim własnym kontekście.

Byłoby to również prawdą, gdybyś tworzył coś do spakowania i zainstalowania. Nie możesz wiedzieć, czy ktoś już używa pewnych zdarzeń w domyślnej przestrzeni nazw, więc powinieneś utworzyć własne i tam słuchać. Dzięki temu nie nadepniesz na żaden programista, który korzysta z Twojego pakietu.

Przestrzenie nazw pozwalają nam podzielić połączenia na różne konteksty. Możemy to porównać do pokoi, które pozwalają nam grupować połączenia, a następnie możemy połączyć to samo połączenie również z innymi pokojami.

Przestrzenie nazw umożliwiają tworzenie różnych kontekstów, w których Socket.IO będzie działać. Pokoje umożliwiają grupowanie połączeń klientów w tych kontekstach.