[nicolnx]

Добрый день

 

Коллеги, подскажите пожалуйста, что выбрать для multicast -> unicast? OS роли не играет - могу поднять как на фре так и на линухе. Количество активных сессий будет измеряться сотнями.

Судя по отзывам relaying лучше держит нагрузку, но несколько смущает закрытый код + он же не обновлялся довольно давно. С другой стороны натыкаюсь на инфу что в последних версиях udpxy стал весьма стабилен. Есть у кого реальный опыт борьбы с тем и другим?

[Ivan_83]

Через пару недель смогу дать потестить свой аналог udpxy.

- общий буфер на каждую мультикаст группу;

- задаваемый размер прекеша на группу;

- возможность цепляться к мультикасту на любом интерфейсе (через урл задаётся интерфейс);

- ловля SAP анонсов и выдача их плейлистом (может ловить на нескольких интерфейсах и выдавать за раз);

- никаких форков, только один рабочий процесс.

хз что ещё придумаю по ходу :)

[nicolnx]

Через пару недель смогу дать потестить свой аналог udpxy.

 

Исходный код открывать планируете?

[maxlapshin]

https://github.com/erlyvideo/udpts эта штука вроде у клиентов работает пристойно

[nicolnx]

https://github.com/erlyvideo/udpts эта штука вроде у клиентов работает пристойно

 

а на каких нагрузках?

[iconnect]

Используем для задачи multicast->http собственное решение. По сути - промышленный http стример.

OS - Linux.

 

Вход

200 multicast

Выход (максимальная нагрузка на сервер)

1хX3430 - 4Gb/s

2хE5649 - 14Gb/s

 

От кол-ва сессий зависит слабо - можно просто поделить выходной поток на планируемую среднюю полосу на сессию. В нашем случае - это тысячи активных сессий.

Цифры реальные - взяты с "боевых" серверов.

 

 

Коллеги, подскажите пожалуйста, что выбрать для multicast -> unicast? OS роли не играет - могу поднять как на фре так и на линухе. Количество активных сессий будет измеряться сотнями.

Судя по отзывам relaying лучше держит нагрузку, но несколько смущает закрытый код + он же не обновлялся довольно давно. С другой стороны натыкаюсь на инфу что в последних версиях udpxy стал весьма стабилен. Есть у кого реальный опыт борьбы с тем и другим?

[maxlapshin]

https://github.com/erlyvideo/udpts эта штука вроде у клиентов работает пристойно

 

а на каких нагрузках?

 

2-3 гигабита на раздачу.

[Ivan_83]

Исходный код открывать планируете?

Да.

Нативно под фрю (kqueue), под линухом тоже не сильно хуже (epoll).

[nicolnx]

Исходный код открывать планируете?

Да.

Нативно под фрю (kqueue), под линухом тоже не сильно хуже (epoll).

 

Может сразу на github да совместными усилиями допилим?

[Ivan_83]

Скелет я сам добью, а вот с генерацией всяких html для статистики и прочего буду только рад.

[Andrey_open]

Ivan_83, как успехи? хочется попробовать :)

[Ivan_83]

Хорошее: tsreader не показывает ошибок, поток отдаётся, работает под фрёй и линуксом, можно в урл задавать имя или индекс интерфейса, размер прекеша, размера блока для отправки. Прописал статикой заголовки Content-type: video/mpeg и всякие для длна, вмп начал с него показывать.

Теперь думаю что нужно в урл запроса ещё параметр сделать для Content-type в ответе, чтобы видео и аудио плееры различали и чтобы в программе это не хранить и не сильно заморачиватся детектом.

 

Из плохого: пока не научил цеплять клиентов к одному мультикаст приёмнику и вообще ничего не выдаёт по хттп, кроме потока от мультикаста и ошибок при неверном урл. Ещё под линуксом почему то отпадает подписка на мультикаст, но это скорее к линуксу - от него не видно игмп запросов/ответов квериру. (в udpxy есть таймер пере подписки, видимо на случай кривых ядер)

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

[vitalyb]

Сделал такую штуку, может кому пригодится. Из UDP-TS мультикаста делает юникастовые RTSP + RTP (TS в RTP в UDP).

http://sourceforge.net/projects/iptv2rtsp-proxy/

[Ivan_83]

Наверное не очень хорошо копировать у себя в памяти пакет ещё раз

memcpy(&this->ringbuf[dst_start], &buf[pos], MPEG_PKT_SIZE);

можно сразу принимать в this->ringbuf[dst_start]

[vitalyb]

Ivan_83

Да, а с помощью sendmsg() можно заставить само ядро собрать полный пакет из кусков, кольцевой буфер сейчас не нужен (но может пригодиться если демультиплексировать TS на PESы), и еще кучу всякой ерудны можно придумать (к тому же там еще могут попадаться "нелогичные" куски т.к. часть уходит корнями в другой проект)... но задачу выполняет (у меня :).

[maxim1]

здравствуйте.

Подскажите а с помощью чего можно организовать из юникастов мультикаст программно

[Ivan_83]

Да, а с помощью sendmsg() можно заставить само ядро собрать полный пакет из кусков, кольцевой буфер сейчас не нужен

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

К сожалению recvmsg не умеет сразу кучу пакетов принимать в кучу iov.

У меня sendmsg() использует больше одного куска в двух случаях:

- когда у меня там rtp принятый в буфере - я не делаю доп копирований, сразу в кольцевой читаю из сокета;

- когда часть данных для отправки в конце а вторая уже в начале.

Ещё, я в линуксе так и не нашёл как узнать сколько в сокет можно данных залить на отправку, во фре kqueue сообщает сколько можно заслать, а тут приходится пихать всё что доступно сразу.

 

 

Подскажите а с помощью чего можно организовать из юникастов мультикаст программно

С помощью програмки.

[maxim1]

Какой? Желательно название.

[vitalyb]

я в линуксе так и не нашёл как узнать сколько в сокет можно данных залить на отправку, во фре kqueue сообщает сколько можно заслать, а тут приходится пихать всё что доступно сразу.

Думаю, если сокеты неблокирующиеся - можно заливать сколько влезет, по результату send() будет видно, когда место кончилось.

[Ivan_83]

Это лишняя работа, как минимум в схеме с ртп, когда много iov инитится. Другая особенность в том, что буфера отправки для клиентов будут фрагментироватся: те на фре я точно знаю сколько можно отправить, и выбираю столько iov чтобы все они влезли целиком.

Я уже привык: пофик что на линуксе не так эффективно пашет, это проблемы линуксойдов.

[andrik]

Ещё, я в линуксе так и не нашёл как узнать сколько в сокет можно данных залить на отправку, во фре kqueue сообщает сколько можно заслать, а тут приходится пихать всё что доступно сразу.

Зачем узнавать, это же лишний syscall.

[Ivan_83]

Одну причину я написал, вторая это попытка полностью эмулировать kqueue через epoll + доп вызовы.

[maxlapshin]

Зачем возиться вручную с kqueue, если есть libuv?

[andrik]

интересная штука, но насколько я понял это надстройка над libev:

 

libuv is a new platform layer for Node. Its purpose is to abstract IOCP on Windows and libev on Unix systems. We intend to eventually contain all platform differences in this library.

 

правда есть вкусные вещи типа асинхронного резолвинга.

[Ivan_83]

Зачем возиться вручную с kqueue, если есть libuv?

Нафик чужие либы, чужие ошибки и чужое видение на архитектуру приложения.

 

правда есть вкусные вещи типа асинхронного резолвинга.

И что?

У меня тоже есть простенький асинхронный резолвер с кешем, без рекурсии, эцп, использующий один сокет для отправки запросов. Отдаёт А и АААА.

Про винду не думал. И под неё можно сделать. Версия фри от линуха отличается только одним файлом где работа с kqueue/epoll, в остальных совсем немного #ifdef.

Чем больше архитектур - тем больше ограничений для приложения.