скорее всего кто-то все-таки куда-то позвонил с этого телефона или зашел на сайт какой-либо и зарегистрировался (причем возможно, что не сегодня, а месяц назад), может игрушку какую качали. Недавно знакомый так подписался на один сайт. Так они каждый месяц списывали по 100 рублей (присылали платную входящую смску) Причем знакомый клятвенно божился что никуда не ходил, пока я ему не сказал куда именно он ходил. он просто забыл об этом, так как месяц уже прошел, а подписка раз в месяц списывает деньги.
В МТС есть такая услуга www.mts.ru/services/fun/infocontent/, достаточно отправить смс со знаком вопроса на этот сервисный номер и вам придет полная информация о провайдере и стоимости как входящей так и исходящей смс с этого номера, а также телефон и веб адрес провайдера услуги совершенно бесплатно.
На самом деле тут очень хорошо подходит вариант с периодом (каждому зеку по 100 дней на включение лампочки) и дополнительная фича, что включать лампочку в этот период может не только зек, который к этому периоду привязан, но и зек, который уже знает, что тот зек там был (видел лампочку зажженой ранее). Т.е. получается социальная система, чем больше зеки узнают о других зеках, которые были в комнате, тем чаще они это знание распространяют, и становится неважно, что лампочка иногда гаснет.
немного подумав, уменьшил среднее время в заключении в два раза, добавив такое условие:
Если один зек уже знает, что другой зек тут был, но лампочка в период этого зека не горит, то этот зек сам включает лампочку, чтобы сказать об этом тем, кто этого еще не знает. обновленный исходник: s-c.me/Ml теперь некоторые зеки выйдут даже если они будут не бессмертны!
Думаю 100*2 оптимально для rand функции. Дает возможность каждому зеку увидеть лампочку. Для 200 получается 60 тысяч дней для 100 получается 100 тысяч дней
да, забыл сказать каждый 100й день есть день так называемого сброса информации, зек который приходит в этот день выключает лампочку полюбому. Если 100*Period дней не хватит, то все повторяется.
решил всетаки запрограммировать, то что я тут написал, и понял что слишком долго зеки будут выходить. Думаю стоит распространить информацию между как можно большим количеством зеков, т.е. договорится что есть так называемый период распостранения информации. т.е. каждый зек, может разговаривать только в свой отрезок, скажем 100 дней, остальные в этот отрезок не должны ничего делать, а просто смотреть на лампочку, зная что если в этом отрезке она горит, то это зек номер N ее включил, так как там был итого нужно около 100*Period дней чтобы хотябы один зек увидел все лампочки от всех зеков.
можно немного улучшить алгоритм, если добавить условие:
если зек тут уже был, но вчера тут не был и позавчера тут не был и лампочка горит, то лампочку он считает, но не выключает (передавая счетчик следующему зеку, который руководствуется тем же правилом.
Зеки договариваются между собой, что оставляют лампочку зажженной только если он здесь был первый раз. Следующий зек, который видит, что лампочка зажжена, гасит ее и считает сколько раз он ее погасил. Если зек пришел, а лампочка не горит и он тут уже был и у него есть счетчик погашенных лампочек (лампочек, которые он погасил), он зажигает лампочку и уменьшает свой счетчик. Тот кто первый наберет 100 на своем счетчике тот и скажет, что все ок.
Подвох в том, что маржинальность выделенного сервера выше, чем колокейшина. Вы платите за размещение, платите за сервер, платите за дополнительную память, причем постоянными ежемесячными платежами. В случае размещения своего сервера, хостер отрывается от постоянной кормушки. Так как датацентр не резиновый, то ниже определенного уровня маржинальности, хостер колокейшин продавать не хочет.
Насчет затрат, вижу пока единственный вариант, OpenSource проект YandexS3, на sourceforge, затраты почти нулевые, людям должно понравится, подключатся, может даже пожертвуют на развитие проекта :)
Каждый, кому это нужно, создаст свой маленький S3 на Яндекс.Диске гигов на 100, нагрузка из расчета на аккаунт/IP минимальная, мониторинг пропустит! Яндекс не против? :)
Полностью согласен с вашими доводами, идея со стартапом скорее всего не пройдет. Насчет отпуска, это были последние деньки и для того, чтобы разобраться с Яндекс.Диск я потратил не более двух часов, вот для того, чтобы написать все это мне потребовалось намного больше времени, это верно. Думаю, как вариант, просто больше ничего не писать :)
Насчет нескольких потоков, склеивать ничего не надо, ссылка на даунлоад менеджер передается одна и таже, просто скрипт выбирает свободную временную ссылку и дергает необходимый даунлоад менеджеру участок файла (просто немного переписать скрипт с range запросом, я это уже делал когда тестировал скрипт с FlashGet).
Но, честно говоря, я надеялся, что за моими бредовыми идеями Вы всетаки увидите, то, что вижу в них я, а именно возможность. Когда появляется возможность, есть два варианта, использовать ее или нет, когда возможности нет, вариантов тоже нет. Я думал вам понравится нестанартный подход к решению стандартной задачи, мысли, которые идут наперекор всему что уже изобретено, но, похоже, я ошибся.
В настоящий момент я привел не очень хороший пример использования такой идеи, но я уверен, что это можно использовать в других целях, просто, я пока не знаю в каких именно. Но, теперь я знаю, что такое возможно сделать, а значит, кто-нибудь, когда-нибудь обязательно это использует.
Думал будет интересно тем, кто не знает об этом API. Плюс в документации не очень хорошо описан сам процесс организцаии подписи для PHP, по крайней мере мне пришлось искать это в ее дебрях.
Если один зек уже знает, что другой зек тут был, но лампочка в период этого зека не горит, то этот зек сам включает лампочку, чтобы сказать об этом тем, кто этого еще не знает. обновленный исходник: s-c.me/Ml теперь некоторые зеки выйдут даже если они будут не бессмертны!
если зек тут уже был, но вчера тут не был и позавчера тут не был и лампочка горит, то лампочку он считает, но не выключает (передавая счетчик следующему зеку, который руководствуется тем же правилом.
Каждый, кому это нужно, создаст свой маленький S3 на Яндекс.Диске гигов на 100, нагрузка из расчета на аккаунт/IP минимальная, мониторинг пропустит! Яндекс не против? :)
Насчет нескольких потоков, склеивать ничего не надо, ссылка на даунлоад менеджер передается одна и таже, просто скрипт выбирает свободную временную ссылку и дергает необходимый даунлоад менеджеру участок файла (просто немного переписать скрипт с range запросом, я это уже делал когда тестировал скрипт с FlashGet).
Но, честно говоря, я надеялся, что за моими бредовыми идеями Вы всетаки увидите, то, что вижу в них я, а именно возможность. Когда появляется возможность, есть два варианта, использовать ее или нет, когда возможности нет, вариантов тоже нет. Я думал вам понравится нестанартный подход к решению стандартной задачи, мысли, которые идут наперекор всему что уже изобретено, но, похоже, я ошибся.
В настоящий момент я привел не очень хороший пример использования такой идеи, но я уверен, что это можно использовать в других целях, просто, я пока не знаю в каких именно. Но, теперь я знаю, что такое возможно сделать, а значит, кто-нибудь, когда-нибудь обязательно это использует.