Wiele połączeń z siecią WWW

Question

Czy istnieją zalety posiadania dwóch różnych połączeń websocket do tego samego serwera od tego samego klienta? Dla mnie wydaje się to złym wyborem projektu, ale czy istnieje jakikolwiek powód, dla którego/gdzie powinien on działać lepiej?

Answer 1

Istnieje kilka powodów, dlaczego może chcą zrobić, ale prawdopodobnie nie są zbyt często (przynajmniej jeszcze nie):

• masz zarówno szyfrowane i nieszyfrowane dane, które wysyłasz/odbieranie (np. niektóre dane są nieporęczne, ale nie są wrażliwe).
• Masz dane transmisji strumieniowej i wrażliwości na opóźnienia: wyobraź sobie interaktywną grę, która czasami przesyłała strumieniowo wideo w grze. Nie chcesz, aby duże strumienie multimediów opóźniały odbiór normalnych komunikatów o wrażliwości na opóźnienia.
• Masz zarówno tekstowych (na przykład komunikaty kontrolne JSON) oraz dane binarne (wpisywanych tablic lub Blobs) i nie chcą zajmować się dodając własne warstwy protokołu do odróżnienia od WebSocket już robi to za ciebie.
• mieć wiele websocket sub-protokoły (opcjonalne ustawienie po URI), które wspierają i strona chce uzyskać dostęp do więcej niż jednego (każde połączenie websocket jest ograniczona do jednego sub-protocol).
• Masz kilka różnych usług WebSocket znajdujących się za tym samym serwerem WWW i portem. Sposób, w jaki klient wybiera połączenie, może zależeć od ścieżki URI, schematu URI (ws lub wss), pod-protokołu, a może nawet od pierwszej wiadomości od klienta do serwera.

Jestem pewien, że istnieją inne powody, ale to wszystko, co mogę myśleć z góry mojej głowy.

Answer 2

Obecnie szukam rozwiązania dla dwóch połączeń z tym samym websem. Mój powód:

• napisałem przypadek testowy w QUnit i chcę symulować wielu klientów i sprawdzić różnych klientów do poprawnych odpowiedzi

Answer 3

stwierdziliśmy, że może to zrobić logiki klienta znacznie prostsze, kiedy subskrybują tylko aktualizacje niektórych obiektów zarządzanych przez serwer. Zamiast opracowywać niestandardowy protokół subskrypcji dla pojedynczego kanału, wystarczy otworzyć gniazdo dla każdego elementu.

Powiedzmy, że uzyskuje się zbiór elementów za pomocą REST API w

http://myserver/api/some-elements 

Można zapisać się do aktualizacji jednego elementu przy użyciu adresu URL gniazdo tak:

ws://myserver/api/some-elements/42/updates 

Oczywiście jednym może argumentować, że nie jest to skalowalne dla złożonych stron. Jednak w przypadku małych i prostych aplikacji może to znacznie ułatwić życie.