Перейти к содержимому
Калькуляторы

mining

Пользователи
  • Публикации

    26
  • Зарегистрирован

  • Посещение

Все публикации пользователя mining


  1. Нет, какие-то дополнительные опции, вроде записи или распределения, не нужны. Исходящие тоже не требуются, решим параллельно иными способами. По поводу корпоративных/личных и т.п. не очень понял. На данном этапе разве это важно? Оформим, как угодно, это ведь организационный, а не технический вопрос.
  2. Нужно принимать входящие звонки и сообщения. Преимущественно из РФ, но, вероятно, в будущем понадобится и межгород. Пока берём номера у операторов связи, но интересна сумма затрат (разовых и регулярных) на внедрение своей нумерации. Хотя бы примерные цифры, от которых можно будет отталкиваться.
  3. Да, тема для меня новая, чуть выше упомянул об этом. А если нужно послать СМС/ММС на внутреннюю нумерацию, тоже нужны какие-то дополнительные телодвижения?
  4. А, ну вот. Это мне и непонятно, как на внутреннюю нумерацию будут совершаться звонки, приходить СМС/ММС и т.п. Получится этакий аналог NAT'а, как в IP-сетях? Внешний номер один, а за ним внутренняя нумерация?
  5. Я понимаю. :) Вопрос немного в другом - подобный подход не вызовет никаких конфликтов? Например, в случае с IP-адресами свою "нумерацию" использовать не получится, произвольный адрес вызовет конфликт на оборудовании оператора. Поэтому все вынуждены пользоваться услугами RIR'ов. А с телефонией как-то странно. Если нумерация назначается произвольно, то, действительно, зачем обращаться в Союз электросвязи? Возможно, я не всё понимаю, тема новая.
  6. А на эту нумерацию можно будет звонить из мира?
  7. Понял, спасибо. Буду рад, если ещё кто-то сможет помочь с подробностями. Кстати, а есть ещё способы получить нумерацию, не привязанную к какой-либо национальной юрисдикции? Ну, кроме 8-800.
  8. @sdy_moscow может, кто-то за деньги занимается? Не подскажете специалистов по телефонии, готовых проконсультировать?
  9. Да, что-то вроде. Только не 8-800, а свой код. Членские взносы нужно будет платить? Они большие для данной услуги?
  10. Всем привет. Заинтересовал следующий вопрос - как получить номерную емкость напрямую от Международного Союза Электросвязи? По аналогии с Voxbone (+8835100) или МТТ (+883140). Насколько подобное реально в принципе и что для этого нужно?
  11. ipv4 аренда/продажа

    Есть свободные блоки /22 - /19, пишите.
  12. Уже беседовали, отказываются. "Наш сервис предназначен, в первую очередь, для вебмастеров, желающих организовать поиск у себя на сайте и других подобных задач", в таком духе отписываются. Кроме того, доступ нужен далеко не только к Яндексу.
  13. Господа, вопрос актуален. Если кто-нибудь из читателей, работающих в провайдинге, найдёт время на формирование ТЗ для реализации и внедрения конкретного решения (беря за базу имеющееся под рукой оборудование) - с меня минимум коньяк. :) Или за контакты технарей/менеджеров, принципиально готовых обсудить вопрос. Доставка из утконосов по указанному адресу - за мой счёт. :)
  14. Эммм.... а именно? Сейчас ip уже порядка 130-140 тысяч (суммарно по нескольким лирам и включая резервные блоки для пиковых нагрузок). Проблема в том, что КПД низок (видно по трассам, пирам, ris.ripe.net и прочим робтексам, кто и куда ходит). Мне бы не хотелось эти подробности в паблике обсуждать. Яндекс, как и другие ПС, не пойдут на такое сотрудничество по политическим мотивам. Дело в том, что собираемая статистика весьма обширна и, скажем так, "функциональна", что позволяет использовать её в ущерб идеологии ранжирования документов, формировании поисковой выдачи и некоторым другим важным вещам. Кроме того, нам нужна естественность трафика, а не его заточка на стороне адресатов, которая может повлиять на отдаваемые результаты. Например, собираемая статистика по отклику и доступности ресурсов для пользователя как раз предполагает "пинг" напрямую от провайдера, а не какие-то оптимизированные между аплинками маршруты. Это мы понимаем, разумеется. С финансовой частью проблем не будет - нам достаточно ясен масштаб задачи, чтобы выходить на её решение неподготовленными материально. Дело в другом - большинство сервисов Рунета недоступны по v6. У нас-то такие сети есть, давно уже, но толк от них будет только тогда, когда где-то 60-80% провайдеров начнут пиринги по новому протоколу и, соответственно, процент пользователей с v6 достигнет величины, которую те же ПС начнут принимать в расчёт. Не думаю, что это случится в ближайшие 3-4 года. От какой суммы отталкиваться? Мы на это рынке уже больше 6 лет, если что. Причин для "разонравится" нет. С подобным успехом можно подозревать любую статистическую или аналитическую службу, типа TNS Gallup, что им разонравится их нынешняя деятельность. Подобные нюансы решаются организационными и техническими методами - оговаривается допустимость тех или иных действий в договоре, прописывается ответственность за них (включая фразу вроде "нижеподписавшийся Клиент осведомлён об уголовной ответственности за такие-то деяния"), прописываются порядок уведомления и санкции, а также оговариваются технические ограничения, вплоть до запрета определённых протоколов, портов, видов трафика, доступа к части доменного пространства, и т.д. и т.п. Здесь проблем с нашей стороны не будет. Это уже давно нереально, клиентская база только растёт.
  15. Технически - позволяет, формально - нет. Для того и нужен доступ от нескольких (десятков) крупных и не очень провайдеров, что официально какой-либо "партнёр" это сделать не может. Можно было бы - сделали бы ещё лет шесть-семь назад.
  16. sexst о чём Вы предлагаете договориться с крупными сервисами? Tosha мы работаем далеко не только с XML, да и миллионные нагрузки они не позволят даже партнёрам вроде mail.ru, проверено. Подключать для наших целей сайты - смысла не имеет.
  17. Ilya Evseev, мы уже пробовали работать на стороне конечного клиента. Это - одна сплошная головная боль, хуже всяких ботнетов. Начиная с того, что их нужно найти и индивидуально заинтересовать. Нам нужно решение именно на провайдерской стороне. s.lobanov, PPPoE - это как вариант, раз уж мы отталкивались от провайдера для домашних пользователей, с модемами и пр. А есть иные способы? Понятно, что можно нарегить 64 юрлица и коннектиться из 64 разных точек подключения. Но хотелось бы... чего-то более технологичного. Если здесь есть сотрудники провайдеров (желательно от medium и выше) из этого списка - https://www.ripe.net/membership/indices/RU.html - с радостью обсужу с ними любые конкретные вопросы. В привате, если нужно.
  18. Ну смотрите. На статике мы используем пул /20, в течение суток их меняется до 10 штук, т.е. общий объём ip должен соответствовать где-то /17. Но это лировская статика, при динамических адресах от обычного Интернет провайдера требования резко снижаются. Полагаю, в обычном режиме на один канал будет не больше (округлим) 64 подключений (64 ip), используемых одновременно. Поскольку схема работы примерно такова - 1) софт коннектится, 2) открывает нужный ресурс, где собирает нужные данные, 3) завершает сессию и разрывает, если требуется, физическое соединение (поднимает новый виртуальный сетевой интерфейс, к примеру) - то, соответственно, требование к количеству ip одно: если нельзя на каждый новый коннект предоставить новый ip, то хотя бы повторяться они должны как можно реже. Как-то так. Включатся - где скажете. Можем арендовать сервер непосредственно у провайдера, можем от себя поднимать канал (кстати, да, что-то вроде GRE было бы оптимально). Физик или юрик - тоже не важно, сделаем, как потребуют.
  19. Поисковики и прочие сервисы выдают разве-что капчу, да и то в весьма редких случаях. С этой проблемой мы успешно справляемся. Повода для иных абуз, вроде почтового спама или всяких spambot activity, тем более не будет - у нас обычный трафик, сбор статистики с новостных и крупных тематических/отраслевых ресурсов, поисковиков, сервисов вроде того же XML, adwords, alexa rank, liveinternet, различных хуизов, агрегаторов вроде be1.ru/stat, и т.д. и т.п. Единственное - объемы большие. Третья причина, по которой я обратился на nag.ru - хотелось бы сразу найти системщиков, администрирующих мощности конкретного провайдера, чтобы на базе конкретной же платформы понять спецификации, дать своим технарям мануалы, приспособить софт ко всем этим сменам MAC и поднятиям адресов, и начать наконец-таки работу (взаимовыгодные условия сотрудничества - обсуждаемы в любом случае). А то, честно говоря, уже поднадоело натыкаться на бюрократические грабли у крупных магистральщиков. Названиваешь какой-нибудь Синтерре/Ростелекому, там тебя ничего непонимающие девочки полчаса переключают между собой, потом волевым усилием ты добираешься до чуть более вменяемого менеджера, тот берёт двухдневную паузу, затем подключает Второго Заместителя Третьего Ведущего Специалиста Департамента Прямых Продаж Дирекции Услуг Корпоративного Подключения для Юридических Лиц в Десятом Сбоку Округе Резервного Филиала Центрального Офиса по Северо-Западу Московского Региона (а бывают подписи и покруче), тот подключает армию кодеров, команду сисадминов, двух сервисных инженеров из числа начальников отделов, пятерых специалистов дилера, поставляющего маршрутизаторы, одного буржуя непосредственно из Cisco, и одну секретарщу на постоянный поднос кофию, затем вооружается ТЗ на собственный управляющий софт, вооружается RFC из всех доступных взору и разуму источников, после чего начинается ЭПОПЕЯ под названием "нестандартное подключение нового клиента". Вот только толку ото всех этих галактических армий - никакого. То координатора проекта нет, то уволился кодер, отвечающий за галочку перед кнопочкой, то какой-нибудь консультант в отпуске, то у них реорганизация адресного пространства, то переезд оборудования, то фаза Луны не совпадает с орбитой Сатурна, то кофий не той марки - в общем, адъ. Поэтому хочется найти спеца, непосредственно работающего с раздающим ip-адреса оборудованием, и с ним напрямую решить все наши скромные вопросы. Надеюсь, такие люди здесь присутствуют? От меня просите, чего хотите - после борьбы с операторскими регламентами, уставами и нормативами даже какая-нибудь райповская переписка кажется сборником свежих анекдотов. А уж общий язык с живыми людьми - найдём и подавно.
  20. За несколько лет мы перепробовали массу решений, но это не выход (кроме чисто юридических нюансов, необходим полный контроль за используемыми мощностями). Сейчас мы работаем с несколькими лирами, но имеющейся статики катастрофически не хватает. Есть и вторая по значимости проблема: большинство крупных сервисов в том или ином виде используют БД, позволяющие определять географию ip-адреса, что значительно снижает КПД работы с крупными поставщиками подсетей и/или хостерами. Поэтому работа именно с провайдерами Интернета напрямую - представляется наиболее оптимальной.
  21. Львиная доля работы выполняется скриптами на нескольких nix-серверах. Кроме того, не все наши партнёры готовы к унификации программного обеспечения. К тому же, не все операторы готовы предоставить сотни коннектов в рамках одного договора (здесь вообще много организационных сложностей возникает). Поэтому нам хотелось бы найти более-менее универсальное техническое решение. Или хотя бы предварительный его набросок.
  22. Финансовая, разумеется. При наличии достаточного обоснования мы готовы как оплатить индивидуальное решение, так и соответствующую арендную плату за услуги.
  23. Я время от времени освежаю переписку с ними, подобные нагрузки допустимы (пару сотен тысяч мы уже даём, но не так неэффективно, как хотелось бы). Кроме того, нам нужна универсальная схема, работающая не только под XML (сейчас собирается много данных, по аналогии и для целей, схожих с Руметрикой - rumetrika.rambler.ru). Что Вы можете посоветовать в качестве технологического решения?