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

vladd

Активный участник
 Просмотреть профиль  Активность

  • Публикации

    250

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

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем vladd

  2. Опубликовано · Жалоба на ответ

    А тут особые досеры не нужны, достаточно немного глючных или любопытных клиентов.

    Подробно в код не смотрел, но если там таймаута получения запроса нет (и кипалива чтобы сам отваливал дохляков) то оно рано или поздно будет проявляться на больших аптаймах.

    Таймаут кстати есть, и на подключение запроса (5 секунд), и на дохляков.

  3. Опубликовано · Жалоба на ответ

    Вам скорее всего нужно вот это http://www.lofis.ru/documents/conv8RR.pdf

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

  4. Опубликовано · Жалоба на ответ

    shop.nag.ru/catalog/01897.Mediakonvertery/02403.1Gb/03166.SNR-CVT-2SFP

     

    смотря чем хотите управлять :)

     

    Это совсем не то, нужна возможность по snmp или телнетом зайти на конвертер и опросить статус ddm. А также пропинговать конвертер. Понятно, что это l2 свитч двух портовый получается, только проблема в том, что нужен форм-фактор именно конвертера, с внешним питанием. А свитчи все большие.

  5. Опубликовано · Жалоба на ответ

    Бывают ли в природе управляемые конвертеры SFP-SFP? Желательно в стандартном форм-факторе. Необходимо иметь возможность через управляющий влан посмотреть состояние DDM, пропинговать, и выполнить прочие нехитрые действия.

     

    Спасибо!

  6. Опубликовано · Жалоба на ответ

    Можно ли установить timeout если overruns превысит какого то значения?

    Странно, видимо какие-то подвисшие сессии. Сделаю в следующей версии, с тредами.

     

    А что говорит tcpdump на x.109.235.134 ? Трафик бежит или нету?

  7. Опубликовано · Жалоба на ответ

    1. Подключаемся и не шлём запрос, просто висим, итого: потоки +1

    Если такая проблема есть, доработать не сложно - либо в iptables, либо ограничением количества подключений с одного IP в самой софтине. Это явно не тянет на фатальный баг. У нас внутри сети ддосеров не наблюдалось, а в открытый интернет сервер не светим.

     

    Я свою лучше ещё доработаю, начинать с начала как то не интересно :)

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

  8. Опубликовано · Жалоба на ответ

    Вспомнился Courier Mail Server 1.56 и ранее, он тоже создавал по потоку на клиента.

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

     

    Если у вас во внутренней сети есть проблема c ddos-ерами, то это можно решить парой строчек в iptables. Или доработать софтину, и выложить изменения тут :)

  9. Опубликовано · Жалоба на ответ

    Еще раз - треда на клиента нет, есть тред только на время обработки запроса GET. Потом тред убивается и работа идет только с клиентским fd. На 500 клиентах количество занимаемой памяти не изменилось ни на мегабайт.

     

    и что, при 8k запросов в секунду будете создавать/убивать 8k тредов в секунду? может, лучше пул тредов?

     

    При таких нагрузках уже будут ресурсы допилить либо эту программу, либо купить что-то готовое. Пока же у нас 300-400 клиентов, и не в секунду, а в час пик одновременно смотрящих, под такие запросы и сделал софтину. Бесплатные решения не устраивали, а коммерческие - были неоправданно дорогие.

     

    Неа, не увеличивается total packets, картинка в влц появилась и зависла.

    Значит 100% не идет мультикаст-поток, или прекращает идти после запуска. Точно не включен fast leave, ограничение количества потоков или еще что-нибудь в этом роде? Программа запрашивает все потоки сразу, и должна получать их даже если никто не смотрит.

  10. Опубликовано · Жалоба на ответ

    > pthread_create(&http_thread_t, NULL, http_thread, harg);

     

    Вы серьезно? На каждого клиента тред?

     

    Тред на http-сессию, для обработки запроса. После этого fd клиента передается в общий пул и тред убивается.

     

    skipping 1 packets

     

    и в влц не показывает

     

    Судя по выделенному, не идет udp-поток. Посмотри несколько раз /stat - увеличивается ли атрибут total packets?

  11. Опубликовано · Жалоба на ответ

    Пользуюсь мегафоном lte, такие скорости бывают иногда, но когда что-то срочно надо сделать или посмотреть, обычно грузится все еле еле. Да и что говорить - даже онлайн радио на скорости 64 кбит/с редко когда удается послушать без затыков во время какой-то получасовой поездки на машине в пределах мск.

     

    Не в том направлении работают :)

  12. Опубликовано · Жалоба на ответ

    Вынужден у родственников смотреть госканалы, складывается впечатление - на Украине война, а у нас всё хорошо!

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

  13. Опубликовано · Жалоба на ответ

    После мучений с udpxy и борьбы с распуханием xproxy в астре, что сильно обострилось в канун олимпиады, решил по быстрому сделать свое решение. Представляю на суд общественности то, что получилось в итоге и прошу желающих протестировать.

     

    Принцип работы - слушание по умолчанию всех udp-каналов, полученных из командной строки, запись их в небольшой буфер, и отдача клиентам по http с небольшим прекешем (2 секунды). Это позволяет клиенту очень быстро выполнить буферизацию и сразу начать просмотр. Особенно шустрое включение происходит на smart tv. Используется epoll, что позволяет улучшить качество работы, однако из-за этого программа собирается только в linux.

     

    Запускается так:

     

    ./inputtcp -p <порт> -u 239.71.91.1:1234 -u 239.71.91.2:1234 …

     

    Программа начинает слушать на заданном http-порту и обслуживает группы 239.71.91.1:1234, 239.71.91.2:1234 и остальные, заданные при запуске. Любые другие группы вызовут ошибку 404. Формат запроса - стандартный - /udp/239.71.91.1-1234, статистику можно получить по запросу /stat - по всем клиентам. Особенно понравилась возможность смотреть количество переполнений буфера у клиентов - поле overruns в таблице.

     

    Из ограничений - пока все работает в одном треде, но ничего не мешает запустить несколько экземпляров софтины, исходя из количества ядер, для обслуживания разных групп на разных портах, и сформировать плейлист исходя из этого. Также в файле inputtcp.с можно подправить максимальное количество подключений (стоит сейчас 512).

     

    По опыту - работает у нас уже 2 недели, пики в 300 пользователей в момент трансляции закрытия олимпиады и прочих событий пережили нормально. Качество не сравнить с udpxy, в котором уже при 50 клиентах начинались затыки и рассыпания, а HD вообще было невозможно смотреть. Здесь же с этим все идеально. Больше у нас по tcp не смотрят. Будет интересно, если кто-нибудь попробует на большем количестве абонентов.

    itcp.tar.gz

  14. Опубликовано · Жалоба на ответ

    Отличие от TCP в том, что сервер не будет затормаживаться на получение ACK от клиента, а клиент не шлет эти ACK.

    Т.е. получается эдакий полунадежный TCP.

     

    Используем подобную технологию для передачи магистральных потоков через далекие расстояния по публичным сетям. По практике - 20% потерь компенсирует вообще без каких-либо проблем. То есть таких потерь, при которых tcp вообще перестает ворочаться, особенно с rtt более 100 мс. HD каналы с битрейтом 15-20 мбит/с идут идеально.

  15. Опубликовано · Жалоба на ответ

    Какие только роботы и технологии не придумывают люди. Интересно, а нечто подобное имеется:

     

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

    - В отверстия вставляем оптические кабели, не зачищая, прямо в броне и оплетке, нажимаем кнопку.

    - Аппарат гудит минут 5, и на экране появляются наши кабели - с разложением на модули и волокнами в них, с указанием цветов.

    - Соединяем волокна друг с другом, водя пальцем по сенсорному экрану, и нажимаем кнопку "пуск".

    - Аппрат гудит-жужжит еще минут 15-20, и выплевывает наши кабели, запаянные в муфту, в которой все волокна сварены исходя из наших указаний.

     

    Понятно, что стоить будет как полсамолета, но для многих крупных компаний было бы очень выгодно иметь такое. Да и ничего принципиально невозможного нет для изготовления таких аппаратов.

     

    Просто интересно, вдруг уже такое вовсю используется? :)

  16. Опубликовано · Изменено пользователем vladd · Жалоба на ответ

    У нас при задержках 40-50 мс спидтесты показывают 70-90 мбит на московских серверах.

     

    Боритесь с потерями. Нещадно. Даже 0.5% потерь при таких задержках снижают скорость до 1-5 мбит/c в один поток. Вылизывайте сеть. Трясите магистралов, если проблема у них.

     

    3175165401.png

  17. Опубликовано · Жалоба на ответ

    Применительно к приставкам, интерфейс, написанный на C/C++/Qt, лучше интерфейса на яве/html, примерно также как сапсан лучше ручной дрезины с приделанным двигателем от мерседеса.

     

    Так вот, встроенный интерфейс, в частности на Dune, как раз относится к первому варианту. К тому же все отлично управляется, куча документации со стороны производителя, возможна самостоятельная сборка своих прошивок, скриптов и т.п. По скорости - летает, для абонента все продуманно и удобно. Не понимаю, кому может прийти в голову вместо этого вешать на ту же дюну еще что-то свое на js/html? И что это им дает?

  19. Опубликовано · Жалоба на ответ

    Самая большая беда в киви, что терминалы берут свою комиссию поверх оговоренной. И никак это не изменить. Может быть сегодня 0, а завтра в этом же терминале 10% - а пользователи ругаются на оператора. Поэтому не стали с ними работать.

  20. Опубликовано · Жалоба на ответ

    1005A нормально работает, но есть проблема - если в него включен еще и комп, то в спящем режиме на нем сетевуха переводится в 10-мегабитный режим. А именно наличие 10-мбитного устройства в неуправляемом сегменте является причиной плохой работы iptv. Как только отключаем wake-on-lan - все нормализуется.

  21. Опубликовано · Жалоба на ответ

    Спасибо за организацию! Все по-прежднему очень понравилось. Пожелания:

     

    1. Рассылать в твиттер со специальным тегом за 5 минут тему следующего доклада или начинающегося круглого стола. Очень нужно, реально.

    2. Оставить вайфай на том же уровне, что и был в этот раз. Реально на порядки улучшился, молодцы. Кстати, как такое стало возможным, если не секрет?

    3. Обязать вендоров привозить с собой по большому мешку подарков для всех участников, причем разных. Флешки, футболки, толстовки, игрушки и т.п.

  23. Опубликовано · Изменено пользователем vladd · Жалоба на ответ

    Это бесполезно.

    Ибо его траффик от вас уйдет по best маршрутам.

    Так вот именно это и нужно - отдавать клиенту не полный fullview, а только те префиксы первого аплинка, которые попали в best-маршруты моего роутера. Возможно ли это в принципе? Тогда исходящий трафик от клиента будет уходить только на первого оператора.

    А входящий и так идет как надо.

    Просто выковыривайте его пакеты со второго аплинка, перенаправляя на первый.

    Имеется в виду source-based роутинг? Дело в том, что первый аплинк - это пиринговый route server, от которого приходит куча шлюзов, и просто слить на один хоп весь трафик клиента не получается.

  24. Опубликовано · Жалоба на ответ

    Имеется два аплинка (1 и 2), и один клиент. Со всеми установлена bgp-сессия. Возможно ли как-то сделать так, чтобы клиенту анонсировались только те префиксы, которые получены от аплинка 1, и которые одновременно в данный момент выбраны как best на нашем роутере?

     

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

     

    PS. Используется quagga. Заранее спасибо за советы :)

  25. Опубликовано · Жалоба на ответ

    Вернули принудительное перенаправление, а то как-то они починили, что трафик опять полился с Европы.

    Не поделитесь скриптом для отлова сетей гугла для внесения их в DNAT? Или может быть лучше объединиться и готовый список сетей выкладывать куда-нибудь на ftp раз в час скриптом?