2009-08-10 202 views
20

爲什麼沒有任何Javascript分佈式計算框架/項目?這個想法似乎絕對真棒我,因爲:Javascript分佈式計算

  • 客戶是瀏覽器
  • 迭代可以用AJAX做
  • 網絡管理者可以通過連接各自的Javascript
  • 千萬甚至上億用戶的幫助項目將幫助DC項目甚至沒有注意到

請分享您對此主題的看法。

編輯:另外,你認爲什麼樣的問題會適合JSDC?

GIMPS例如就不可能實現。

+0

有一個關於此主題的項目https://zlelik.blogspot.nl/2016/11/unified-field-theory-with-javascript-distributed-computing-or-gravity-electromagnetism-relation.html – Zlelik 2016-11-07 20:40:01

回答

-1

我認爲第一個問題是JavaScript在計算上效率低下。這不僅僅是值得的,因爲純c/C++中的應用程序會快100倍。

+1

只有100個?可能更多。這意味着讓1萬人安裝一個基於C++的分佈式計算客戶端將會產生至少*與獲得一百萬人蔘與基於JS的工作量相同的工作量。 – 2009-08-10 23:53:34

+0

C++對速度有好處,而JS是好的,因爲它可以在用戶瀏覽網頁時使用,而用戶不會注意到...因此,完美的解決方案是使用JavaScript來驅動C++應用程序的下載! – 2009-08-10 23:58:21

+0

但事情是每個人都可能參與一個網站或另一個網站,根據網站的JS客戶端數量可以輕鬆達到*十億*,而不是數百萬。 – 2009-08-12 06:14:18

5

在這裏有'用戶權利'要說的東西。這聽起來像是你描述的情況,Foo.com的網站管理員在他們的網站上包含Folding @ Home的腳本。因此,Foo.com的所有訪問者都會將部分CPU「捐贈」給Folding @ Home,直到他們離開Foo.com爲止。如果沒有某種免責聲明或選擇加入,我會認爲這是一種惡意軟件,並避免訪問任何網站。

這並不是說你不能建立一個系統,要求確認或批准,但有濫用明確的潛力。

+0

+1絕對同意 – allergic 2013-01-10 08:44:36

+4

+1,但它已經通過瀏覽器中的所有廣告橫幅完成:) – 2013-11-09 21:56:37

6

我認爲Web Workers即將用於創建分佈式計算框架,在這個概念上有一些early attempts。非阻塞代碼的執行可能在使用setTimeout之前就已經完成了,但是它有點意義,因爲大多數瀏覽器廠商都在最近專注於優化他們的JS引擎。現在我們有更快的代碼執行和新的功能,所以在後臺運行不知不覺一些任務,我們瀏覽網頁很可能只是幾個月的事;)

+0

JavaScript是事件驅動的,它不是默認情況下是非阻塞的嗎? – lastmjs 2015-12-12 00:55:14

4

我已經在這個項目推薦的背景下思考自己。

首先,有沒有問題與速度! JIT編譯的JavaScript可以像未優化的C一樣快,特別是對於數字代碼。

更大的問題是,在後臺運行的JavaScript會拖慢瀏覽器,因爲它運行速度慢,因此用戶可能不喜歡你的網站。

顯然存在安全問題,您如何驗證結果?

和隱私,你可以確保敏感數據不受損害?

最重要的是,這是一件相當困難的事情。您收到的訪問次數是否可以證明您必須付諸實踐?如果您可以在服務器或客戶端透明地運行代碼會更好。將其他語言編譯爲javascript可以在此幫助。

總之,它不普遍的原因是因爲開發人員的時間比服務器時間更有價值。丟失用戶數據的風險和給用戶帶來的不便遠超過潛在收益。

1

我知道pluraprocessing.com做類似的事情,不知道是否確切的JavaScript,但他們通過瀏覽器運行Java並完全運行內存嚴格的安全性。

他們有50,000個計算機網格,他們已成功運行應用程序,即使是網絡爬行(80legs)。

1

我認爲我們可以驗證某些問題的結果。

比方說,我們有n個項目,需要對其進行排序。我們會把它交給工人1,工人1會給我們結果。我們可以驗證它O(n)的時間。請考慮至少需要O(n * log(n))時間來產生結果。另外我們應該考慮n個項目有多大? (關注網速)

又如,f(x)= 12345,並給出函數。目的是找到x的價值。我們可以用一些工人的結果替換x來測試它。我認爲一些不可覈實的問題很難給予某人。

1

的JavaScript整體思路分佈式計算有缺點的數量:

  • 故障的單點 - 在節點
  • 之間comunicate
  • 節點的天然失敗沒有直接方式 - 每個節點都在工作,只要瀏覽器
  • 不保證發送的消息將被接收 - 根據到節點
  • 自然無法不保證已經收到了消息不斷髮送 - 因爲有些黑客可以設置
  • 在客戶端惱人的負載
  • 倫理問題

雖然只有一個(但非常誘人)的優勢:

  • 輕鬆自由訪問節點的milions - 幾乎每一個設備具有當今JS支持的瀏覽器

但是最大的問題是可擴展性和煩惱之間相關性研究。假設您提供一些有吸引力的Web服務並在客戶端運行計算。更多的人用於計算,更多的人感到煩惱。更多的人感到惱火,更少的人使用你的服務。那麼,你可以限制煩惱(計算),可擴展性或嘗試之間的事情。

以谷歌爲例。如果谷歌將在客戶端運行計算,一些人將開始使用bing。多少 ?取決於煩惱程度。

Javascript分佈式計算的唯一希望可能是多媒體服務。只要他們消耗大量的CPU,沒有人會注意到任何額外的負載。

0

我發現一個類似於這個問題的回來,所以我建立了一個這樣做的事情。它使用web worker並動態獲取腳本(但不包括Eval!)。 Web工作人員對沙盒進行沙箱處理,以便他們無法訪問窗口或DOM。您可以看到代碼here和主要網站here

該庫在第一次加載時有一個同意彈出窗口,所以用戶知道後臺發生了什麼。