Распределенные вычисления Javascript

Ответ 1

Сначала мне приходит в голову вопрос безопасности. Почти все распределенные протоколы, которые я знаю, имеют шифрование, поэтому они предотвращают риски безопасности. Хотя этот предмет не является настолько инновационным.

http://www.igvita.com/2009/03/03/collaborative-map-reduce-in-the-browser/

Также Wuala - это распределенная система, которая реализуется с помощью java-апплета.

Ответ 2

Я думаю, что Web Workers скоро будет использоваться для создания распределенных вычислительных фреймворков, есть некоторые ранние попытки в этой концепции. Выполнение незаблокированного кода могло быть выполнено до использования setTimeout, но это имело мало смысла, поскольку большинство поставщиков браузеров сосредоточились на оптимизации своих JS-движков совсем недавно. Теперь у нас есть более быстрое выполнение кода и новые функции, поэтому бессознательно запускать некоторые задачи в фоновом режиме при просмотре веб-страниц, возможно, всего лишь несколько месяцев;)

Ответ 3

Здесь есть что сказать для "прав пользователя". Похоже, вы описываете ситуацию, когда веб-мастер для Foo.com включает в себя script для, скажем, Folding @Home на своем сайте. В результате, все посетители Foo.com имеют часть своего процессора, "пожертвованного" Folding @Home, пока они не уйдут от Foo.com. Без какого-либо отказа от ответственности или отказа, я бы подумал, что это одна из форм вредоносного ПО и избегать просмотра любого сайта, который сделал это.

Чтобы не сказать, что вы не могли создать систему, которая попросила подтвердить или разрешить, но существует определенный потенциал для злоупотреблений.

Ответ 4

Я сам обдумал это в контексте рекомендации пункта.

Во-первых, существует проблема нет со скоростью! JIT скомпилированный javascript может быть таким же быстрым, как неоптимизированный C, особенно для числового кода.

Большая проблема заключается в том, что запуск javascript в фоновом режиме замедлит работу браузера, и поэтому пользователям может не понравиться ваш сайт, потому что он работает медленно.

Очевидно, что проблема безопасности, как вы можете проверить результаты?

И конфиденциальность, можете ли вы обеспечить, чтобы конфиденциальные данные не подвергались риску?

Кроме того, это довольно сложно сделать. Может ли количество посещений, которые вы получаете, оправдывает усилия, которые вам придется вложить в него? Было бы лучше, если бы вы могли прозрачно запускать код на сервере или на стороне клиента. Компиляция других языков на javascript может помочь здесь.

Вкратце, причина, по которой он не распространен, заключается в том, что время разработчиков более ценно, чем время сервера. Риск потери пользовательских данных и неудобства для пользователей перевешивают потенциальные выгоды.

Ответ 5

Я знаю, что multipaprocessing.com делает аналогичную вещь, не уверен, что именно javascript, но они запускают Java через браузер и полностью работают в памяти со строгой безопасностью.

У них есть 50 000 компьютеров, в которых они успешно запускают приложения, даже как веб-сканирование (80legs).

Ответ 6

Я думаю, что мы можем проверить результаты по какой-то проблеме.

Скажем, у нас есть n количество элементов и нужно их сортировать. Мы дадим его работнику-1, рабочий-1 даст нам результат. Мы можем проверить это время O (n). Учтите, что для получения результата требуется не менее O (n * log (n)). Кроме того, мы должны рассмотреть, насколько велико n элементов? (беспокойство о скорости сети)

Другой пример: f (x) = 12345 и функция. Цель состоит в том, чтобы найти значение x. Мы можем проверить его, заменив x на некоторый рабочий результат. Я думаю, что некоторые проблемы, которые не поддаются проверке, трудно кому-то дать.

Ответ 7

Вся идея Javascript Distributed Computing имеет ряд недостатков:

• единственная точка отказа - нет способа прямой для связи между узлами
• естественный отказ узлов - каждый node работает до тех пор, пока браузер
• не гарантирует, что отправленное сообщение будет когда-либо получено - в соответствии с естественным сбоем узлов
• не гарантирует, что полученное сообщение было отправлено, потому что некоторые хакеры могут вставлять
• раздражающая загрузка на стороне клиента
• этические проблемы

хотя есть только одно (но очень заманчивое) преимущество:

• легкий и свободный доступ к milions узлов - почти у каждого устройства теперь поддерживается браузер JS

Однако самой большой проблемой является корреляция между масштабируемостью и раздражением. Скажем, вы предлагаете привлекательный веб-сервис и выполняете вычисления на стороне клиента. Больше людей, которых вы используете для вычисления, больше людей раздражает. Больше людей раздражает, меньше людей пользуются вашим сервисом. Ну, вы можете ограничить раздражение (вычисление), масштабируемость или попробовать что-то между ними.

Рассмотрим Google, например. Если google будет запускать вычисления на стороне клиента, некоторые люди начнут использовать bing. Сколько? Зависит от уровня досады.

Единственная надежда на Javascript Distributed Computing может быть мультимедиальным сервисом. Пока они потребляют много CPU, никто не заметит никакой дополнительной нагрузки.

Ответ 8

Я нашел вопрос, похожий на это некоторое время назад, поэтому я создал вещь, которая делает это. Он использует веб-рабочие и загружает сценарии динамически (но не Eval!). Веб-рабочие изолируют скрипты, чтобы они не могли получить доступ к окну или DOM. Вы можете увидеть код здесь, а основной веб-сайт здесь

У библиотеки есть всплывающее окно согласия при первой загрузке, поэтому пользователь знает, что происходит в фоновом режиме.

Ответ 9

Я думаю, что проблема №1 - неэффективность javascript при вычислении. Это не стоило бы того, потому что приложение в чистом c/С++ было бы в 100 раз быстрее.