Javascript Distributed Computing [zamknięty]

Myślę, że Web Workers wkrótce zostaną wykorzystane do tworzenia rozproszonych frameworków obliczeniowych, są pewne wczesne próby tej koncepcji. Nieblokujące wykonywanie kodu mogło zostać wykonane przed użyciem setTimeout, ale miało to trochę sensu, ponieważ większość dostawców przeglądarek skupiła się niedawno na optymalizacji swoich silników JS. Teraz mamy szybsze wykonywanie kodu i nowe funkcje, więc nieświadomie uruchamianie niektórych zadań w tle podczas przeglądania Internetu to prawdopodobnie tylko kwestia miesięcy ;)

Jest tu coś do powiedzenia o "prawach użytkownika". Wygląda na to, że opisujesz sytuację, w której webmaster dla Foo.com zawiera skrypt, powiedzmy, Folding @ Home na swojej stronie. W rezultacie wszyscy odwiedzający Foo.com mieć jakiś ułamek ich procesora "oddany" do Folding@Home, dopóki nie odejdą od Foo.com.bez pewnego rodzaju zrzeczenia się lub opt-in, uznałbym to za formę złośliwego oprogramowania i unikałbym odwiedzania jakiejkolwiek strony, która to zrobiła.

That ' s not to say you nie można zbudować systemu, który poprosił o potwierdzenie lub pozwolenie, ale istnieje możliwość nadużycia.

Zastanawiałem się nad tym osobiście w kontekście rekomendacji pozycji.

Po pierwsze, nie ma żadnego problemu z prędkością! JIT skompilowany javascript może być tak szybki jak nieoptymalizowane C, szczególnie dla kodu numerycznego.

Większy problem polega na tym, że uruchamianie javascript w tle spowalnia przeglądarkę i dlatego użytkownicy mogą nie lubić Twojej strony, ponieważ działa ona powoli.

Jest oczywiście kwestia bezpieczeństwa, jak można zweryfikować wyniki?

I prywatność, czy możesz zapewnić, że poufne dane nie zostaną naruszone?

Poza tym, jest to dość trudna rzecz do zrobienia. Czy liczba odwiedzin, które otrzymujesz, może usprawiedliwiać wysiłek, który będziesz musiał włożyć w to? Byłoby lepiej, gdybyś mógł uruchomić kod w sposób przejrzysty na serwerze lub po stronie klienta. Kompilowanie innych języków do javascript może tutaj pomóc.

Podsumowując, powodem, dla którego nie jest on rozpowszechniony, jest to, że czas deweloperów jest cenniejszy niż czas serwera. Ryzyko wystąpienia utrata danych użytkownika i niedogodności dla użytkowników przeważają nad potencjalnymi zyskami.

Wiem o pluraprocessing.com robiąc podobne rzeczy, nie jestem pewien, czy dokładnie javascript, ale uruchamiają Javę przez przeglądarkę i działa całkowicie w pamięci ze ścisłym bezpieczeństwem.

Mają 50 000 komputerów, na których z powodzeniem uruchamiają aplikacje nawet takie jak web-crawling(80legs).

Myślę, że możemy zweryfikować wyniki jakiegoś problemu.

Załóżmy, że mamy n liczbę elementów i musimy je posortować. Damy to robotnikowi-1, robotnik-1 da nam wynik. Możemy to zweryfikować O (N) czasie. Proszę wziąć pod uwagę, że uzyskanie wyniku zajmuje co najmniej O(n*log(n)). Dodatkowo powinniśmy rozważyć, jak duże jest N elementów? (troska o szybkość sieci)

Inny przykład, f (x)=12345, i funkcja jest podana. Celem jest znalezienie wartości x. możemy ją przetestować przez zastąp x jakimś wynikiem pracy. Myślę, że niektóre problemy, które nie są weryfikowalne, są trudne do przekazania komuś.

Cała idea JavaScript Distributed Computing ma wiele wad:

• pojedynczy punkt awarii - nie ma bezpośredniego sposobu komunikowania się między węzłami
• naturalne awarie węzłów - każdy węzeł działa tak długo jak przeglądarka
• Brak gwarancji, że wysłana wiadomość zostanie kiedykolwiek odebrana - zgodnie z naturalnymi awariami węzłów
• nie ma gwarancji, że otrzymana wiadomość została kiedykolwiek wysłana - ponieważ niektórzy hakerzy mogą wtrącać
• irytujące obciążenie po stronie klienta
• problemy etyczne

Choć jest tylko jedna (ale bardzo kusząca) zaleta:

• łatwy i darmowy dostęp do milionów węzłów - prawie każde urządzenie ma obecnie JS obsługujące przeglądarkę

Jednak największym problemem jest corelacja między skalowalnością a irytacją . Załóżmy, że oferujesz atrakcyjną usługę internetową i uruchamiasz komputer po stronie klienta. Więcej ludzi, których używasz do komputerów, więcej ludzi jest zirytowanych. Więcej osób jest zirytowanych, mniej osób korzysta z Twoich usług. Cóż, możesz ograniczyć irytację( przetwarzanie), skalowalność lub spróbować czegoś pomiędzy.

Rozważ na przykład google. Jeśli google będzie uruchamiać obliczenia po stronie klienta, niektórzy ludzie zaczną korzystać z bing. Ilu ? Zależy od poziomu irytacji.

Jedyną nadzieją dla Javascript mogą być usługi multimedialne. Dopóki zużywają dużo procesora, nikt nie będzie zwróć uwagę na dodatkowe obciążenie.

Myślę, że problemem nr 1 jest nieefektywność javascript w informatyce. Nie byłoby to po prostu tego warte, ponieważ aplikacja w czystym c / C++ byłaby 100 razy szybsza.

Jakiś czas temu znalazłem podobne pytanie, więc zbudowałem coś, co tak robi. Używa Web workerów i pobiera Skrypty dynamicznie (ale nie Eval!). Web workers piaskuje skrypty, aby nie mogli uzyskać dostępu do okna lub DOM. Możesz zobaczyć kod tutaj , a główną stronę tutaj

Biblioteka ma wyskakujące okienko zgody przy pierwszym załadowaniu, więc użytkownik wie, co dzieje się w tle.