Идея интересна, концепт хорош.
-зачем ZeroMQ, что не так с RemoteProcedureCall из stdlib?
-появилось много нативных Go хранилищ (github.com/boltdb/bolt, github.com/google/cayley, github.com/HouzuoGuo/tiedot, etc), которые можно использовать in-process простыми вызовами нативных Go функций избегая этим работу с сокетами и TCP протоколом. Теоретически это должно быть быстрее Mongo, не пробовали под нагрузкой? Если пробовали, может поделитесь опытом.
-Выглядит привлекательным, рациональным использование NaCl (native client) в google Chrome для нагрузки пользовательской машины. NaCl SDK вроде уже вполне зарелизены.
К сожалению, пока что нельзя запустить golang в Chrome.
«They cannot be run directly in Google Chrome. As such, the NaCl support in Go 1.3 is useful only for running sandboxed environments like the Go Playground»
Сам когда-то изучал этот вопрос, очень жаль, что они еще не добавили такую возможность.
Спасибо.
1. Не RPC, потому что мне нужен message passing. Например, отправляемые сообщения у меня не подразумевают синхронного ответа, стороны обмениваются несвязанными потоками сообщений. Конкретно zmq потому что у меня с ним хороший опыт, потому что он позволяет выбрав «тип» соединения и задав пару настроек, не заботиться о таких вещах, как создание соединений, пере-соединение при обрывах, буферизация отправляемых сообщений, логика при отсутствии пира и т.п.
2. Спасибо за список хранилищ, я их не пробовал. У меня хранилище и так in-process, по сути — массив с парой map-ов в качестве индексов. Однако, когда все это вырастет и усложнится, не исключено что захочется использовать что-то более функциональное.
3. Пока я не пробовал nacl, поскольку не было нужды, все что нужно удобно делается и js-ом. Хотя, с точки зрения «спрятать исходник модуля, чтобы спамерам было труднее искать слабые места» — может и возьму на заметку.
Еще раз спасибо!
А выложите на гитхаб проект на Go? Очень интересно было бы посмотреть, может даже законтрибутить.
Кстати, посмотрите в сторону WebRTC, возможно что-то пригодится для плагина — кажется, на его основе можно сделать так, что на бекенде у вас останется лишь signaling-составляющая, а все остальное можно сделать полностью распределенным.
Пока выкладывать серверную часть не планирую. У меня на этот счет смешанные чувства и аргументы, так что пока пусть будет закрытым.
WebRTC я не изучал, судя по википедии это протокол для реал-тайм обмена данными между браузерами. Мне сложно судить, чем он может помочь убрать из сервера прикладную составляющую (ведение и поиск по БД), кажется что «это не совсем то». Или может я не понял вашу мысль?
Пока у меня план перейти на long-polling, это позволит снизить задержки при выдаче заданий и получении статусов объявлений.
Я решил, что пусть лучше вкладка откроется один раз и висит, периодически загружая в себя нужные страницы, чем на каждую страницу я буду вкладку закрывать и открывать — такое мельтешение точно никого не порадует. Или может у вас другая проблема, напишите, пожалуйста, в личку. Спасибо!
Средствами youtube api можно получить несколько кадров из видео для анализа, если таких хитрых агентов будет достаточно много, довольно легко проверять и видео.
Хорошая идея, спасибо!
Думаю можно еще и вести черный список youtube-аккаунтов, я сильно сомневаюсь что они будут под каждую объяву создавать акк в гугле, затратное это дело.
скажите, почему нельзя считать посредниками всех, кто указывает телефон только на картинке? другими словами, если нет явно написанного телефона в тексте, то ситать автора посредником
Считать всех кто пишет телефон на картинке посредниками — нужно. Собник так и делает. Просто обнаружить телефон на фото — не просто, агенты всячески его маскируют.
ну я бы такую погрешность допускал, ради того, чтобы не распознавать телефоны на фотографиях. Как только этот телефон появится хотя бы в двух нормально опубликованных объявлениях с разными объектами, так его сразу пометим как спам.
Номер посредника знать очень хочется. Но в случае с телефонами на фото технической возможности распознать номер пока нет, и вряд ли появится.
Именно поэтому я употребляю слово «обнаружить», а не «распознать». Распознать (программно преобразовать изображение в текст) — невозможно, обнаружить (определить наличие надписи на изображении) с хорошей вероятностью — можно, что и делается.
Собник делает именно то, что вы предлагаете, просто мы с вами в терминах разошлись.
Да, мне уже намекали что в разделе работа и автомобили тоже много всяких спамеров. Четкого плана применить там собник пока нет, но это определенно очень интересное направление. Спасибо!
Хорошая идея и реализация в целом, но считаю оформление клиентской части в виде плагина к Хрому это добровольное сокращение сегмента потенциальных пользователей.
Наверное от плагинов для браузеров полностью не удастся уйти, потому что это наиболее простой способ встраивать свой html в страницу, но написать отдельное приложение для windows которое устанавливает плагин в папку расширений браузера, а само работает в трее для вычислений, можно, хотя это более замороченный способ как для вас так и для пользователей
Не очень понятно, какую проблему это решает. Напрягает, что открывается вкладка? Меня тоже, но с «добровольным сокращением аудитории» это связано очень косвенно. Написать программу, которая будет делать собниковское дело в трее — не особая проблема, берем phantomjs, адаптируем плагин под него, компилируем под нужные платформы и вперед. Желающих это реализовать я буду счастлив принять в соавторы собника. Спасибо!
Видимо, это решает проблему «не все пользуются хромом». Для FF плагин будет? Я бы поставил себе: я либо на работе и дома ноут простаивает, либо дома и комп включен (выходные). Не знаю, большой ли трафик и насколько «рад» будет работодатель…
«Проблему» других браузеров решает разработка расширений под другие браузеры. Она в планах. В ближайших планах вынос браузеро-зависимого кода в отдельный модуль чтобы было легко портировать расширение. По сути там останется совсем немного при должных знаниях платформы, так что если кто-то захочет помочь — буду очень рад.
По объемам трафика не скажу — примерно одно объявление в минуту, фотки и всякая реклама, думаю 20-50 мегабайт в час может набежать.
Автор молодец. Это уже давно придумано и работает (с проксями, распределение не понадобилось), но к сожалению этих методов недостаточно. Впервые когда я реализовал эту систему, я рассчитывал что со временем черный список пополнится и агентов почти не будет. Но это оказалось не так. Черный список растет непрерывно, так же как и новые симки у агентов. С тех пор прошло уже два года, и система обзавелась еще кучей проверок, анализаторов, обзвонщиков людей, и я вам скажу что это все равно недостаточно эффективно.
Хотел бы внести предложение: реализуйте фильтрацию по региону. Я, в данный момент, живу в Самаре и мне хотелось бы осуществлять обработку региональных объявлений. Когда региональных объявлений нет, пусть ищет по стране.
Как было сказано в начале статьи про глобальные распределенные проекты
практической пользы для человека, поделившегося ресурсами своего компьютера — никакой
Так вот практической задачей для меня является актуальный поиск жилья в моем регионе, в частности в Самаре (вот в тему эта статья, задача для меня насущная). Во вторую очередь — все остальное.
Никакой разницы, кому раздавать задания на поиск — нет. Я могу раздавать всем подряд как сейчас, могу добавить приоритет региональности — никакой разницы ни в скорости, ни в какой-либо другой пользе лично вам — не будет. Многие упорно пытаются увидеть какую-то выгоду в этой настройке, я её не вижу, но в планах она есть — раз людям нравится.
Распределенные вычисления для поиска жилья