Implementacja serwera Web Sockets dla NodeJS

Question

Nie mogę oprzeć się wrażeniu, że trzeba gdzieś to odebrać, ale jestem przeklęty, jeśli mogę go znaleźć. Częścią problemu może być to, że po stronie klienta jest zbyt dużo dyskusji, aby zobaczyć drewno dla drzew.

W każdym razie, przepraszam na bok, oto, co chcę zrobić. Potrzebuję niezależnej od platformy implementacji WebSockets po stronie serwera. Chciałbym, żeby działał w NodeJS.

Teraz 99% z tego, co znalazłem na ten temat, mówi o socket.io. Ale o ile mogę powiedzieć, że to nie jest WebSockets, jest to specjalny "dodatkowy" protokół sam w sobie. Potrzebuję czegoś, co działa "według (jeszcze nie) standardu". Jest ku temu dobry powód, który nie podlega negocjacjom, zaufaj mi i oszczędzajmy przepustowość :)

Próbowałem więc WebSocket, ale to wymaga (lub prawdopodobnie wymaga zarówno Pythona, jak i gorzej, Visual Studio) do działania w systemie Windows. Potrzebuję czegoś, co jest niezależne od platformy i nie potrzebuje specjalnych rzeczy takich jak ta.

Próbowałem również node-websocket-server, ale nie mogę tego w ogóle uruchomić. Przykład na stronie głównej zawodzi mnie. Wygląda na to, że akceptuje połączenie, ale klient go nie widzi, żadna strona nie wysyła niczego, a klient natychmiast widzi połączenie jako zamknięte. Rzeczywiście, wszystko, co kiedykolwiek otrzymuję, to połączenie zwrotne "połączenie", a potem wydaje się, że umiera. Uruchomienie w trybie debugowania nie powiedziało mi nic przydatnego, z wyjątkiem jakiegoś błędu wewnętrznego dotyczącego jakiegoś obiektu lub innego, który nie ma metody flush(). W połowie podejrzewam, że jest to nieistniejący projekt?

Nie mam pomysłów. Czy można przekonać socket.io, aby działał wyłącznie przez (nie) specyfikację dla WebSockets? Czy istnieje sposób, aby zmusić serwer sieci-węzła do zachowania się, którego nie udało mi się znaleźć? Czy istnieje sposób oparcia Visual Studio w websocket, czy jest jakieś inne narzędzie oparte na NodeJS, które spełnia wszystkie moje wymagania?

Och, jeszcze jedno, chciałbym, aby narzędzie koegzystowało pokojowo z "połączeniem", ponieważ używam tego do mojej regularnej obsługi dokumentów.

TIA, Toby

Answer 1

miałem dokładnie ten sam problem, że jesteś stoi w tej chwili, kiedy próbował użyć Socket.IO na innej platformie bez bezpośredniego portu klienta (i bez motywacja do samodzielnego portowania).

skończyło się na przeniesienie mojego kodu używać ws który jest wdrożenie w oparciu o standardy websocket węzła bez dodanego cukru z socket.io.

To działa bardzo dobrze w moim przypadku na kilku różnych platformach, ale trzeba by przerobić większość kodu połączenia/ponownego połączenia itp

WWW: link

GitHub: link

NPM: npm install ws

Answer 2

Socket.io używa WS pod okładkami, więc możesz trafić na ten sam problem z instalacją w systemie Windows. Może się okazać, że narzeka, że ​​musisz zainstalować Visual Studio 2010 dla składnika ws do pracy.

Można jednak skonfigurować wersję Visual Studio używaną przez node-gyp, która uruchamia kompilator C++ za pomocą zmiennej środowiskowej.

Przykłady:

• ustawić GYP_MSVS_VERSION=2012 dla Visual Studio 2012
• ustawiony GYP_MSVS_VERSION=2013e ('E' oznacza 'Express Edition')

Pełny wykaz zobaczyć - https://github.com/joyent/node/blob/v0.10.29/tools/gyp/pylib/gyp/MSVSVersion.py#L209-294

Jest to bolesne dla użytkowników systemu Windows NodeJS, ponieważ zakłada, że ​​masz kopię instancji Visual Studio które nigdy nie będą mieć wielu użytkowników końcowych. Dlatego lobbuję Joyenta, aby zachęcił ich do włączenia gniazd sieci jako części węzła CORE, a także do wysłania kompilatora GNU gcc w ramach instalacji NodeJS, abyśmy mogli na stałe naprawić ten problem i nie zmuszać użytkowników węzłów systemu Windows do modyfikowania ich środowiska lub pobrać cokolwiek innego.

Zapraszam do dodawania swój głos na:

• https://github.com/joyent/node/issues/8005#issuecomment-50545326

UWAGA: Zespół Joyent wykazały, że socket.io spadnie z powrotem do korzystania z wolniejszego wdrażania podczas kompilacji ws zawiedzie. Innymi słowy, Twój kod nadal działa - po prostu nie tak szybko. Nie jest to jasne dla użytkowników końcowych wykonujących instalację dowolnej aplikacji zależnej od socket.io lub ws, ponieważ wyświetla ona czerwony tekst błędu podczas procesu instalacji, prowadząc użytkowników do założenia, że ​​instalacja się nie powiodła, podczas gdy w rzeczywistości zadziała, chociaż powoli.