Pull to refresh

Comments 141

Классно, только задумался о том, как гуглить что-то подобное :)

А как у него с требованиями (память, процессор)? «В режиме реального времени и с минимальной нагрузкой для сервера» хорошо звучит, но хоть немножко цифр можно?
Рабочий расход памяти — порядка 10М на 1000 одновременных соединений.
Очень неплохо, практически любой VDS потянет небольшое сообщество. Пошёл качать. Спасибо!
100М на 1000? 100 кБ на коннект? Конфиг сервера можно огласить?
очень хорошая идея и реализация.
правда «повторить N раз» все таки лучше убрать)) а то глаза мозолить начинают эти
Привет! #1
Привет! #2
UFO just landed and posted this here
реальный тест происходит судя по всему прямо сейчас)

после того как пройдет основной пик «хаброеффекта» автор выложит статистику
UFO just landed and posted this here
Реквистирую графики munin'а на странице с демкой + счетчик онлайновых подключений
Извените а на какой операционке Вы тестировали «сотни тысяч долгоживущих открытых HTTP», помнится мне статья яндекса как они точили FreeBSD чтобы она могла открыть 150т. соединений, им пришлось ядро патчить. На обычном линуксе я уверен тоже не выйдет такого количества, про Вин вообще врядле стоит даже заикатся?
Мне просто интересно Вы себе представляете что такое для операционки 100т. открытых сокетов?
не яндекса а Рамблера или mail.ru не могу нийти ссылку…
UFO just landed and posted this here
Обычный Linux c ulimit -n 1048576 и несколькими listen-сокетами. У меня открылось даже в perl-скрипте 200 тыс. сокетов, это не такое большое значение.
На фре надо патчить, а в линухе подкрутить sysctl ;)
а если попробовать передавать не короткие сообщения, а порядка 10-50КБ (целую страницу сайта), что из этого можно получить?
Там есть ограничение на максимальную длину сообщения — IN_MAXLEN.
Это я видел. А не пытались ли Вы передавать целиком ХТМЛ страницы? Будет ли выигрыш в производительности? А добавив flash прослойку можно использовать gzip :)
Картинки тоже можно тогда гонять через постоянное соединение, используя base64.
И тогда получится что-то вроде гугловского SPDY ;)
Если добавлять флеш-прослойку. Тогда лучше уж без комета — сразу все на сокеты переводить :)
Целиком HTML-страницу будет, во-первых, слишком затратно по трафику, а во-вторых, все формы ведь будут сбрасываться. Нет, лучше страницу обновлять по кусочкам.
Все. Сервис лег. На POST выдает 500 ошибку.
все-таки завалили -> 500 Internal Server Error (Канал Habrahabr)
Очень интересно! Дмитрий, а есть ли описание механизма работы?
Прочитал всю статью на dklab, но так и не понял всех тонкостей работы.
Также интересно, можно ли сделать канал, на несколько входящих сообщений — чтобы коннект не закрывался после первого сообщения.
Стоп, стоп. На демо-страницы входящие сообщения принимает не Realplexor, а PHP-скрипт обычным аяксом. И уже этот PHP-скрипт отправляет данные в Realplexor.
Ясно.
А так хотелось нормального long poll`а, сразу же на клиента.
Long Poll в смысле отправки данных не бывает. Только в смысле получения. Потому что «Poll».
Попутал немножко с терминами.
Скажем так — хотелось бы, условно не закрывающееся соединение сервер-клиент.
Возможно ли реализовать такое хотя бы для ИЕ7+, ФФ2+?
Ну кроме Long Polling, есть еще Streamin (как раз когда соединение не нужно никогда закрывать). Но только Streaming не работает в IE. Streaming в Realplexor-е в будущем обязательно добавится (правда, для других, небраузерных, целей).
можно через IFRame — мы так сделали — iframe коннект на 5 минут, отдается отдельным скриптом через nginx. перезапускается каждые 5 минут, а так все сообщения сразу гонит клиенту.
>Streaming в Realplexor-е в будущем обязательно добавится (правда, для других, небраузерных, целей).

Ориентировочный прогноз по срокам не сможете дать?
Какие клиенты планируются?

Очень интересно.

извините, но мы его убили :)
504 Gateway Time-out
Я вообще отредактировал страничку (поставил «Повторить» на 5000 раз) и начал интенсивно нажимать «Отправить». В итоге всё жутко тормозит и выдаёт ошибки аля «Error: Identifier must be alphanumeric, „Привет тому кто сказал привет“ given».

Автор что-то перепутал с описанием производительности в статье.
Сорри: перепутал, ошибку вызвал сам (ввёл текст в название канала), в остальном всё так-же.
а можно ли на PHP принимать запросы?
ну или не на PHP
на сколько я понял этот сервер позволяет подключаться клиентам (JS) к каналам и принимать посылать сообщения
может ли PHP подключаться к каналам для приёма и отправки сообщений или же только для отправки?
Он позволяет подключаться со стороны JS — на чтение, со стороны PHP — на запись (и на считывание диагностики).

Для приема PHP может подключиться, прикинувшись браузером разве что. Но зачем это? Лучше отправку из браузера на сервер делать обычным аяксом, обычным скриптом.
как это зачем?
для быстрого обмена конечно же :)
да и вообще уточнить не мешало-штука то интересная ;)
P.S.
с JS на запись это я как то не разобрался, да :)
Еще одна вкусняшка от dklab, что вы думаете о ape-project?
UFO just landed and posted this here
В libevent, если обрыв соединения проскочил в промежуток между добавлением события и началом его обработки, в первой же строчке perl-обработчика возникает SIGPIPE, который рушил скрипт и заставлял Realplexor перезапуститься. Я сейчас поставил заплатку на это (просто игнорируется сигнал, т.к. дальше по коду нужные проверки имеются).
Какие еще глюки есть, кстати? Вроде бы этот единственный, судя по логам, и его больше не должно быть.
UFO just landed and posted this here
Как поется в песне (цитирую по памяти),

Не страшЁн нам огонь при пожаре,
А страшна паникА при пожаре.
При пожаре гибнУт единицы,
При панИке же — сотни гибнУт.

В том смысле, что проблемы не страшны, страшно, когда они не исправляются. А исправляться они будут, т.к. проект активно используется (и будет использоваться еще кучей людей в OpenSource-community, я подозреваю).
Отличная работа. Насколько, ориентировочно, это приложение стабильно?
Т.е. имеет ли смысл сейчас перестраиваться под него в разрабатываемом проекте?

Сейчас, используется нечто похожее, только с использованием memcacheq, но решение с отдельным демоном мне нравится больше, тем более, что у вас уже все реализовано и на стороне php и на стороне клиента.
Ну, мы его в Рутвите используем. Насколько стабильно — это только время может показать. Главное, что у него всегда будет активная поддержка, а изменения в код вносить очень легко, благодаря тому, что код на Perl и покрыт автотестами.
А связка с другими языками? Например с python?
Обязательно будет, в первую очередь.
FireFox 3.5.6 отправляя на канал сообщение оно не появляется в «верхнем браузере» Win7 Ultimate.
Кто-то заспамил канал who_is_online в демо-скрипте. :-) Так что на JS он долго и мучительно отрисовывается.
Оклимался, но задержка видно что есть… спамят жестко.
Есть один вопрос — а как включить режим работы с теми самыми долгоживущими соединениями?
Мой httpfox плагин показывает просто пачку обычных HTTP запросов (в ответ получая JSON).

А только что вообще словил кучу 502 Bad Gateway от nginx'а.
Где тут долгоживущие соединения? :(
Он включен, а соединения долгоживущие. Просто не все плагины для Firefox это умеют отображать. :-)
А 502 поймали, наверное, в момент, когда я его перезапускал. Провожу периодически разные эксперименты тут.
Эх, хотел попробовать — а не ставиться, Event::Lib при установке валится. Может стоить добавить в дистр сразу все необходимое?
Event::Lib — это бинарная библиотека. Инструкции по установки есть в документации.
Да, я как бы понял и видел :) но при сборке валится.

Result: FAIL
Failed 2/36 test programs. 0/283 subtests failed.
make: *** [test_dynamic] Error 255
VPARSEVAL/Event-Lib-1.03.tar.gz
/usr/bin/make test — NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports VPARSEVAL/Event-Lib-1.03.tar.gz
Running make install
make test had returned bad status, won't install without force
Failed during this command:
VPARSEVAL/Event-Lib-1.03.tar.gz: make_test NO
Ну, это уже к разработчикам Event-Lib, наверное. А может быть, решение нагуглится, наверняка кто-то еще libevent собирал для вашей версии ОС.
Спасибо за сервер.

Если не сложно ответьте на пару вопросов:

1.) Сколько потоков\файберов использует ваш сервер?
2.) Возможно ли решение проблемы лимита 2 соединений без сабдомена?
3.) Поддерживаться ли все браузеры?

Несколько замечаний.
Количество открытых хендлов лимитировано ОС, а это вроде далеко не сотни тысяч. Далее стандарт TCP en.wikipedia.org/wiki/Transmission_Control_Protocol
предполагает 16 бит на порт это (0-65535), каждое клиентское подключение заберет 1 порт.
1. Вообще-то, один. Это же событийно-ориентированный сервер.
2. Кажется, нет.
3. Ну все — вряд ли (IE 2.0 или Lynx вряд ли поддерживаются). Но основные, до которых мы смогли дотянуться, — поддерживаются, конечно.
2 — да, переход на нормальный браузер.
По поводу числа сокетов — ulimit -n 1048576 и несколько listen-сокетов вместо одного (например, на разных IP-адресах) дают до миллиона соединений. Это не проблема.
Вы не могли бы после реального тестирования опубликовать результаты, очень интересно на таких нагрузках. CPU, Память, параметры IО, результаты top.

>> Вообще-то, один. Это же событийно-ориентированный сервер.
Ммм, асинхронный IO это хорошо, но на моей практике например бродкаст рассылка по > n тысяч соединений уже занимает существенное время.

Ещё раз спасибо.
Пробую на работе — не работает. Видимо есть завязки на конкретные порты, значит для корпоративных пользователей будет не доступно. Жаль. Вечером попробую дома.
А вот и канал, в котором отображаются IP-адреса (только первые 2 цифры IP-адрес, остальные не палятся) тех, кто читает эту статью:

Правда, в силу того, что просмотров — несколько штук в секунду, это скорее демонстрация ситуации, когда Long Polling не особенно эффективен — ведь после приема данных «длинное» соединение снова переустанавливается, и это происходит несколько раз в секунду. Тут скорее Streaming нужен, но в IE с ним беда. (Ну или flash-решение.)
тогда супер — стриминг это именно то что мне надо чтобы добавить в проекты эту штуку. а то никакой полинг не подходит под задачи :(
Только тогда статус-бар в браузере скрывайте. А то пока IFRAME не загрузится, там будет написано Loading, и прогресс-бар будет активен.
а зачем скрывать? пусть пишет, это как то не особо и важно. да, есть такая проблема с лоадингом, но ее по-моему, никак принципиально не решить. Подождем веб-сокетов из html5 :)
Realplexor — не поллинг, а Long Polling. Это очень большая разница.
Long Polling использует GTalk, например.
у нас задача — получать постоянно сообщения с минимальной задержкой. их много, обычно в продакшине это 1 или больше каждую секунду.
А как часто сообщения приходят в один конкретно взятый браузер? Если всего несколько штук в минуту, Long Polling вполне подходит.
вот именно, что в каждый отдельный идут с такой частотой. К сожалению, проект по NDA, потому не могу раскрывать подробностей. Но это именно частота прихода обновлений каждому клиенту — конечно есть больше, есть меньше, но тех, которых меньше, их меньше :) Подошло бы то, что делает Lightstreamer, но дорого + не вписывается в инфраструктуру никак :(

Спасает то, что потолок клиентов параллельно висящих небольшой — до десятка тысяч.
> вот именно, что в каждый отдельный идут с такой частотой
Тогда почитайте в Википедии, что такое Comet и Long Polling. Он вам совершенно подходит.
Я прекрасно знаю, что это такое. То есть, устанавливать в среднем каждую секунду новое соединение? Пока прекрасно живет вариант с IFrame, который 5 минут получает данные, потом переоткрывается.
> Я прекрасно знаю, что это такое. То есть, устанавливать в среднем каждую секунду новое соединение?
Long Polling устанавливает соединение не каждую секунду, а раз в 5 минут (к примеру). Либо я Вас не понял, и Вы говорите о чем-то другом, либо же Вы так и не прочитали статью в Википедии.
Объясняю.

1. Установили соединение.
2. Получили пакет данных.
3. Закрыли соединение, открыли новое (п. 1)

Так? Если у меня пакеты данных поступают раз в секунду, значит соединение будет закрываться и открываться чтобы получить новый пакет каждую секунду. Вы говорите о случае, когда соединеие открылось, далее ждет (до максимум указанного вами 5 минут), и потом переоткрывается. Если данные пришли раньше, соединеие будет сброшено после них. В случае IFrame — пакеты идут на всем протяжении работы срипта, то есть он живет полюбому 5 минут и за это время коннект постоянен.
Если это event-based server, тo как он вообще в сравнении с RabbitMQ (и другими AMQP)? Или у него несколько иные задачи?
Различия ведь только в протоколе передачи данных? Все одно используется Javascript скрипт для соединения. Так какая раница, как он уже передает данные? Ведь принцип и плюсы одни и те же.
Задачи как я понял тоже совпадают, так зачем платить больше?
Да, и как на счет работы через HTTPS? все ок? И использование gzip-сжатия?
HTTPS и gzip — OK, но жать нужно nginx-ом (т.е. ставить перед Realplexor-ом nginx, в документации написано, как).
Дмитрий, спасибо за столько полезную разработку!
Скажите, пожалуйста, а с произвольного домена (не поддомена) будет работать?
Нет, работает только с поддомена — это ограничение безопасности браузеров.
dklab — это имя, которое известно многим! респект :)

Одно мне не очень понятно, чего же это так остальной народ скачет услышав слово comet?

Ведь по сути вещь тривиальная, если понять, что нужно сделать.
Достаточно эффективная, многопоточная реализация в виде Java сервлета занимает страницы полторы кода, и работает весьма шустро, так как тормозить-то там в общем нечему.

На сотни тысяч коннектов я, правда не замахивался — нужна была только пара тысяч. Решение «влоб» заработало сразу и без тормозов, так что дальше и я не разбирался.
ну может потому что ваша реализация — закрытая внутреняя, а здесь готовое решение? Я тоже думал про сервлет и т.п., но сейчас все же склоняюсь к иному решению…

P.S. Хотя особенно понравились Servlet 3.0 там асинхронность вкусная!
Готовое открытое решение я приводил — CometD, есть решения от Sun, IBM, Resin, IceSoft. Но если приложение на Java, то можно использовать Atmosphere и извлечь большую выгоду от тесной интеграции со своим приложением при простоте и надежности реализации.

P.S. Если использовать современные сервлет контейнеры, такие как Jetty, Glassfish, Tomcat6, то асинхронность будет из коробки, без необходимости интеграции с nginx и т.п.
вопрос, который меня всегда смущал — вот есть у меня веб-приложение. есть данные. Как мне отправить эти данные тому же кометд или сервлету на атмосфере, чтобы он передал их клиентам? Как совместить с другой инфраструктурой? Ни один из этих продуктов апи не предоставляет сразу
Дело не в сотнях тысячах соединений и даже не в сложности самой реализации comet-like протокола. Главная сложность — организация мультиподписки, мультиотправки, очередей, доставки с гарантией, удобного конфигурирования и запуска и т.д., а также — чтобы это все не глючило и было удобным в поддержке. Чистая алгоритмика. Самого кода работы с соединениями (общение с libevent) в Realplexor-е совсем немного — всего около сотни строчек.
Кстати, по поводу глюков. Не знаю сталкивались ли вы с такой штукой, но мне пришлось поковыряться достаточно долго, поэтому теперь рассказываю всем :)

Если мы сделали ajax запрос, который заблокировался на некоторое время на сервере,
но это время пользователь нажал F5, то старый запрос через некоторое время получит следующее сообщение от сервера и успешно доставит его в никуда.
Это, видимо, как раз на тему гарантированной доставки.
Пессимистично :)
Хотелось бы видеть уже в 2010 году — добрая технология должна быть.
На сайте не нашел как связаться с разработчиками, потому пишу здесь.

Если ваш проект не прекратит спамить пользователей Рамблера приглашениями без возможности отписки и удаления аккаунта с rutvit.ru, Рамблер вас закроет.

Считайте это официальным предупреждением.

Вторых «Профессионалов» Рунету не надо.

— Андрей Шетухин,
руководитель группы разработки
почтовой системы,
Rambler.ru
Спасибо, что Вы нашли время поднять этот вопрос на Хабре. Мы с
удовольствем хотели бы пообщаться о проблеме, которая существует с
почтой Рамблера. Постараюсь ответить на Ваши вопросы по существу.

1. «На сайте не нашел как связаться с разработчиками»
На каждой странице нашего сайта имеется всего одна служебная строка с
«Написать нам» (там же, где Помощь, О Проекте, и т.д.). Мы стараемся
отвечать не только на каждый запрос пользователя, но и делать это в
режиме реального времени.

2. «без возможности отписки»
В каждом уведомлении, уходящем c РуТвита, имеется возможность нажать
всего раз всего на одну ссылку (даже настройки менять не надо) и этим
действием либо отписаться от получения всех уведомлений с РуТвита,
либо отписаться только от уведомления данного типа. Нам неизвестно ни
об одном случае сбоя в системе, когда пользователь отписался и получил
от нас письмо.

3. «удаления аккаунта с rutvit.ru
Мы удаляем аккаунт пользователя по первой просьбе. С момента запуска
проекта мы получили менее десяти просьб об удалении аккаунтов, и все
они были удовлетворены. Нам неизвестно ни об одном случае сбоя в
системе, когда мы удалили пользователя, а он продолжал получать от нас
уведомления.

4. „спамить пользователей Рамблера приглашениями“
Наш пользователь сам инициирует приглашение. Приглашение высылается
только один раз и только по инициативе пользователя. Приглашающий
пользователь может пропустить этот шаг в процессе регистрации и не
высылать ни одного приглашения своим друзьям. РуТвит не высылает
повторных приглашений, в отличие от некоторых хорошо известных
ресурсов Рунета.

Вы, как руководитель почты, должны знать, что наши приглашения и
уведомления не попадают под определение спама потому что они не
являются „повторяющейся массовой рассылкой роботом без возможности
отписаться и удалить свой аккаунт.“
— письмо-приглашение высылается один раз по инициативе пользователя и
только по адресу его друга
— письмо-уведомление всегда содержит ссылку, нажатие на которую
позволяет отписаться от этого типа уведомления или всех уведомлений
— аккаунт удаляется раз и навсегда по просьбе пользователя

5. „Рамблер вас закроет“
Такой подход неконстуктвен. Чего вы добились тем, что Вконтакте уже
отказался от использования почты при регистрации? Я предполагаю, что
Вами движет желание в первую очередь помочь пользователям почты
Рамблера. По крайней мере так было, когда разработкой почты руководил
Капранов, и именно поэтому почта Рамблера была тогда самой удобной для
пользователей Рунета.

Я хотел бы предложить конструктивный диалог, так как какая-то проблема
с рассылкой приглашений или уведомлений, видимо, все же существует,
если на нее тратится внимание руководства Рамблера. Мне кажется, что
проблема в отсутствии стандарта в Рунете, который бы решал проблему
приглашений и уведомлений одним прозрачным, всем понятным способом.

Почему бы Вам не задать тон и разработать такой „Золотой стандарт
почты Рамблера“ для всех социальных сайтов Рунета? Мы будем первыми,
кто его внедрит. Если он действительно будет соблюдать интересы всех
заинтересованных лиц, его внедрят и остальные сайты Рунета, а Рамблер
займет лидерскую позицию по вопросу вместо позиции „не пущать“.

6. Нами, кроме желания развивать наш проект, также движет желание
помочь нашим пользователям
а) быстро находить своих друзей, которые уже пользуются РуТвитом
б) быстро приглашать своих друзей, которые еще не пользуются РуТвитом
Именно с этими целью мы предлагаем использовать книжку с адресами в
почте Рамблера.
Подчеркну, что проблема не нова, и она уже давно решена любой западной
почтой без необходимости предоставлять пароль РуТвиту.

В связи с этим у меня к Вам еще один встречный вопрос-предложение.
Если почта Рамблера действительно заботится о своих пользователях,
почему бы ей не реализовать открытый протокол OAuth. У нас это заняло
всего несколько дней. Дима Котеров писал о протоколе на Хабре. Готовы
помочь советом, если это необходимо.

Например, мы предлагаем то же самое пользователям Gmail.com, который
поддерживает OAuth. В результате пользователь Гмейла имеет возможность
разрешить заглянуть в свою записную книжку без предоставления пароля
от его почты. Доступ недвусмысленно разрешается владельцем почтового
аккаунта на Гмейле, а приглашения от пользователя Гмейла все равно
могут доставляться. Почему бы Вам не реализовать эту передовую
технологию в почте Рамблера и не предоставить ее через API?
Пользователи и социальные сайты были бы благодарны.

7. В заключение, хочу сказать, что я вполне допускаю, что у нас есть
недочеты и я готов работать над их исправлением. Но хотелось бы видеть
не огульное зачисление всех в „профессионалы“, а конкретные
предложения, что еще можно улучшить с нашей стороны. Ни одно
предложение не останется без внимания.

P.S. Нам уже пришла жалоба, что почта на Рамблере не работает. Жаль,
что Вы только предупреждаете, а кто-то ее уже перекрыл.

Заканчивайте флеймить.

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

На мнение минусующих мне плевать, я забочусь не о вебдванольдебилах, а о пользователях Почты Рамблера.
то есть, аргументированных ответов на простые вопросы вы не можете :) Когда уже Рамблер окончательно сгниет :)
Аргументированные ответы следующие:
— сервис производит незаказанные пользователем рассылки. То есть — спамит.

— в письмах нет никакой возможности отписаться от рассылок раз и навсегда. То есть, от навязанной услуги невозможно избавиться. Это — спам.

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

— сервис импортирует данные адресных книг. Это действие противоречит п 5.2 документа www.rambler.ru/doc/privacy.shtml

— сервис грубо нарушает практически все пункты раздела 3 того же документа.

Всего этого вполне достаточно чтобы закрыть этот спамстартап раз и навсегда.

импортирует адресную книгу
>импортирует адресную книгу

Импортирование адресной книги в другие сервисы без согласия лиц, контакты которых перечислены в адресной книге — это сбор и распространение ичной информации без согласия владельца. Подобное не только аморально, но еще и недопустимо с точки зрения закона.
вы уходите от ответа на вопросы/ответы вам же. Например то, что связаться с администрацией можно с сайта (а вы пишете, что не нашли).

Уведомление приходит без ссылки на отписку? Можете предоставить копию писем, что они приходят без нее?

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

Связаться — это дать контакт email. В какой там devnull что уходит с сайта, я не знаю.

>Уведомление приходит без ссылки на отписку? Можете предоставить копию писем, что они приходят без нее?

Чтобы отказаться от рассылок, надо сначала зарегистрироваться? Отличный usecase.

>О адресной книге, OAuth и прочем вам также отписали уже.

Об адресной книге я тоже отписал.
Ладно, я понимаю, что вам, Андрей Владимирович, привычнее врать и угрожать нам, вместо того, чтобы отвечать на наши вопросы.

Но зачем же вы стираете комментарии возмущённых пользователей почты Рамблера? Может быть, всё же ответите, например, вот этому:

phprus.livejournal.com/:
<<<Извините, что влажу в вашу дискуссию, но позвольте поинтересоваться,
на основании каких законов или правил вы решаете за меня кому и каким
образом предоставлять доступ к моей адресной книге находящейся в
рамблер-почте? А так-же на каком основании вы указываете мне как
распоряжаться адресной книгой находящейся на почтовых сервисах не
имеющих к рамблеру никакого отношения?

Кроме того почему некий сервис должен получать письменное разрешение
на использование данных которые вашей компании не принадлежат? (или я
что-то пропустил в вашем пользовательском соглашении и по нему все,
что я пересылаю через рамблер становится собственностью рамблера?) >>>
я — как владелец аккаунта рамблера — имею доступ к своей адресной книге. логично же? я могу её сохранять, удалять, распечатывать и вывешивать на автобусной остановке, гугл. доксах и где угодно ещё.
теперь я — как владелец аккаунта рамблера — разрешаю рутвиту доступ к своей адресной книге.

если рамблер считает, что рутвит должен спросить разрешения у всех людей из моей адресной книги, то непонятно, почему я имею туда доступ? ведь я, может быть, разрешения ни у кого не спросил?
>логично же? я могу её сохранять, удалять

Можете.

> распечатывать и вывешивать на автобусной остановке

Без согласия тех, кто перечислен в адресной книге — не можете.

> я — как владелец аккаунта рамблера — разрешаю рутвиту доступ к своей адресной книге.

Это мнение ошибочно.

>если рамблер считает, что рутвит должен спросить разрешения у всех людей из моей адресной книги, то непонятно, почему я имею туда доступ?

Потому, что эти данные используются вами в личных ценях и не передаются третьим лицам.

>ведь я, может быть, разрешения ни у кого не спросил?

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

могу ли я, в таком случае, сам, самостоятельно, через веб-интерфейс отослать письма моим друзьям и пригласить их в рутвит?
а я могу попросить свою секретаршу разослать письма через веб-интерфейс рамблера? / через почтовый клиент?
> Сами — можете.
Расшифрую это «сами». Оно означает в данном случае следующее:
1. Открыть свой любимый почтовый клиент (например, TheBat или Thunderbird).
2. Скопировать в поле To список email из моей адресной книги.
3. Вставить в текст приглашения ссылку, кликнув на которую, можно стать моим читателем.
4. Нажать кнопку «Отправить».

В настоящий момент РуТвит выступает лишь в роли такого почтового клиента (1) и не более, при этом он упрощает пользователю вставку в поле To email-ов из его адресной книги (2), а также предоставляет автоматически сгенерированную ссылку (3) для приглашения стать моим читателем. Все действия происходят на виду: пользователю явно сообщается на странице выбора получателей (2), что нажатием на кнопку (4) он произведет отправку писем. Т.е. решение о том, отправлять приглашение по почте или нет, принимает пользователь, а не система. Кроме того, для защиты популярных и известных людей от волны однотипных приглашений стоит ограничение: уходит не более 1 приглашения за X месяцев, даже если приглашения высылаются различными людьми.
Продолжайте, продолжайте. Я всегда зеваю, когда мне интересно.

Еще раз и медленно. Я все изложил в постах:
habrahabr.ru/blogs/hi/79189/#comment_2325561

habrahabr.ru/blogs/hi/79189/#comment_2325536
habrahabr.ru/blogs/hi/79189/#comment_2327112

Повторять еще раз не вижу смысла. Либо — так, либо почта не ходит.
>В настоящий момент РуТвит выступает лишь в роли такого почтового клиента (1)

Почтового клиента для массовых рассылок незаказанной корреспонденции. То есть — для спама.

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

Например, Пупкин присылает емейл на мой ящик на Рамблере.

С точки зрения вашей логики, Пупкин не давал разрешения Рамблеру, но
при этом Рамблер, как третье лицо,
1) незаконно сохраняет емейл Пупкина
2) незаконно использует емейл Пупкина в целях уже не лично моих, а
своих — коммерческих
Андрей Владимирович, чепуха, действительно, получается, если следовать
вашей интерпретации закона о персональных данных. Рад, что у нас хоть
в одной точке появилось единое мнение.

Мануалы прочёл, ясности не прибавилось. Что же мне делать, если я хочу
один раз выслать личное приглашение моим друзьям из моей записной
книжки в Рамблере? Раз уж вы затеяли публичное обсуждение, пожалуйста,
дайте рекомендацию по сути.
Если я получив письмо, ничего с ним делать не буду, я получу тот же циклический поток говна, как от «professionaly.ru» или как там их? Или письмо будет только одно?
«Кроме того, для защиты популярных и известных людей от волны однотипных приглашений стоит ограничение: уходит не более 1 приглашения за X месяцев, даже если приглашения высылаются различными людьми» — habrahabr.ru/blogs/hi/79189/#comment_2332075
Теперь понятно, почему «у Рамблера плохая карма»©.
Обалденный вы подняли срач. Мало того, что публичный, так еще и оффтопиком. Так еще и продолжаете его, хотя вам явно указали, куда отправлять ваши претензии.

Надеюсь, вы, Андрей Шетухин, не долго проработаете в Рамблере и вообще в ИТ руководителем.
Хабрахабр такой хабрахабр :)
Андрей, комментируя одно из Ваших высказываний ниже.
В России, следуя букве ФЗ-152, адрес e-mail не является данными, относящимися к персональным.

Подобные данные являются (безумие!) защищаемыми как ID в Италии, чью модель несколько слепо пытаются копировать в России. С точки зрения юридической, это Ваше заявление является откровенным ляпом.

Чтобы оценить Вашу последовательность в применении антиспам-политики, уточняющий вопрос: не блокируете ли сейчас уведомления о добавлении в «друзья» сервисов Вконтакте, МойМир@ и т.п., которые идут по спам-базам (собранным червями) от одних и тех же «персоналий»? Это тоже пахнет злым умыслом со стороны создателей. ;)

Напомню, уведомления проекта МойМир@(знаете что), который по умолчанию спамил по всему адресбуку инвайтами (этот кейс наверняка знаком создателям Рутвита и Рамблер-Почте) и известен как до сих пор входящий в топ «легальных спамеров», не фильтровались Рамблер-Почтой год назад как спам.

О себе: К рутвиту никакого отношения не имею. Профессионалi.ru считаю плохим сервисом.

PS: Есть частный интерес — как восстановить доступ к адресам почты на sovsem.net, uzhe.net и т.п., купленных Рамблером многие годы назад и де-факто убитым? Форма восстановления не работает даже через Rambler ID — в нее просто не ввести адрес вида email@uzhe.net.
>В России, следуя букве ФЗ-152, адрес e-mail не является данными, относящимися к персональным.

В адресной книге может храниться не только адрес. Как правило, там хранится и некая персональная информация.

>Чтобы оценить Вашу последовательность в применении антиспам-политики, уточняющий вопрос: не блокируете ли сейчас уведомления о добавлении в «друзья» сервисов Вконтакте, МойМир@ и т.п., которые идут по спам-базам (собранным червями) от одних и тех же «персоналий»? Это тоже пахнет злым умыслом со стороны создателей. ;)

Если будет достаточное количество жалоб, мы зарубим и эти сервисы тоже.

>Напомню, уведомления проекта МойМир@(знаете что), который по умолчанию спамил по всему адресбуку инвайтами

Он спамил по своему адресбуку инвайтами. А не воровал чужой адресбук (например, с Рамблера) и не спамил сам через него. Конечно, спамить — нехорошо. Но спамить контакты еще и не твоего адресбука — это верх свинства.

>Есть частный интерес — как восстановить доступ к адресам почты на sovsem.net, uzhe.net и т.п., купленных Рамблером многие годы назад и де-факто убитым? Форма восстановления не работает даже через Rambler ID — в нее просто не ввести адрес вида email@uzhe.net.

А что мешает написать или позвонить в службу поддержки?
Спасибо за детальные ответы. Согласен насчет кражи address-book. Сегодня одному стартапу показал Ваш коммент — придержали прыть.

По багу «чужой почты» — служба поддержки зациклена на «используйте форму восстановления», в которой вылезает баг — сервисы uzhe.net не содержали «секретного слова», а при вводе Rambler ID ссылка на восстановление более недоступна.
Напишите мне на a.shetukhin@rambler-co.ru или на slonik-v-domene@rambler.ru.
Поставил, тестирую. Заметил странность:

onreadystatechange FAILS Error: Permission denied for <domain.com> to create wrapper for object of class UnnamedClass { } readystatechange

Это на Firefox 3.5.6/Win 7, на другом, запущенном на этой же машине, 3.6.b4, все отлично.
При этом, первые 2 — 3 сообщения он получает отлично, дальше вот валится.
Новая версия с багфиксами и улучшениями производительности.
Качать, где обычно: github.com/DmitryKoterov/dklab_realplexor

* Dklab Realplexor 2009-12-26: v1.23
— [BUG] Empty identifier passed to IN line («identifier=») caused warnings.
— [SPD] Lower the number of useless debug lines and connection's name() calls.
— [BUG] Improved init script: more time to restart and better signal handling.

* Dklab Realplexor 2009-12-24: v1.22
— [BUG] SIGPIPE causes the script to restart on some unexpected client's disconnects.
New version — 1.24.

Many speed improvements. To achieve maximum speed, try to set VERBOSITY to 0 or 1 in your configuration. Also get rid of «automatic» cursors: they use Math::BigFloat (still), and Math::BigFloat is very slow. Specify cursors manually in $rpl->send() API method.

* Dklab Realplexor 2010-01-30: v1.24
— [BUG] Avoid warnings in log on unexpected disconnect.
— [NEW] Refactoring and profiler support.
— [SPD] Do not create extra shell while calling ulimit.
— [NEW] Support for per-config log facility.
— [SPD] Profiler tool with IN line ignorance. Avoid BigFloat in events: 45% speedup. Apache ab patched utility.
— [SPD] Keep channels pre-sorted after addition. It speedups 60%, because we need less cursor comparisions.
— [SPD] STDOUT buffering in non-verbose mode. More verbosity levels. Logger speedup. Custom config for profiler script.

Current profiler map attached. :)

P.S.
This new version passes all auto-tests, but if you find a bug in it, please report it here.
* Dklab Realplexor 2010-02-27: v1.30
— [SPD] Use EV library (http://search.cpan.org/~mlehmann/EV-3.9/EV.pm)
instead of libevent. It is faster and has no memory leaks.
Дмитрий, подскажите, пожалуйста, в чем может быть проблема.

На фронте постоянно сыпется в консоль:
rpl.newfs.ru:83 Bounce detected (bounceCount = 31)
rpl.newfs.ru:83 Next query in 60000 ms

А сами ответы сервера пусты.
Пример работает тут: newfs.ru/sys/test/ подписывается на новые сообщения в чате (который еще работает на старом аяксе, но так же отправляет новые сообщения в канал bp2_chat).

Установил всё как описано. Серверные автотесты проходят успешно (против двух: не верный пользователь и не верный пароль).
Sign up to leave a comment.

Articles