ligverd

c 10 часов получаю 500 ответ can't be loaded: 500 Can't connect to vigruzki.rkn.gov.ru Попробовал сменить IP , забрал, т.е. сервер нас банит. Забираю раз в час. :(

Народ у кого есть проблемы с забором дельт? Авторизация проходит, получение списка дельт проходит, а скачивание самих дельт ошибка. Началось все 2018-03-16T11:58:12+03:00 getDumpDelta(ID) возвращает имя dump_delta.zip сам файл пустой :( Старый способ через подпись работает.

Мы тоже в недоумении. В интернете тишина полная. Где информация? Или нас (как выясняется некоторых) жестоко на^%$# :( При чем данный алгоритм якобы умоляли внедрить магистральные провайдеры и они уже все готовы. :-/

А вот тут уже "Личный кабинет" + капча, есть уже отчет по забору дельт, только предупредили что пока статистика не заносится в ЛК, но контролироваться будет забор и полного реестра и дельт. Как обещали в конце концов будут штрафовать только за не закрытие ресурса а не за не забор реестра, но когда это случится забыли сказать.

:) да нет схема нормальная, я только боюсь за доступность сервера и за понижение планки на время реагирования.   +1 Вот это правильная плоскость обсуждения, а протокол дельт довольно сносный.

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

Бррр, не понял. :) При скачивании полного реестра в нем будет стоять id последней дельты, так что сохранив этот id после скачивания полного реестра и указав этот id при последующем запросе дельт вам вернется только последние дельты, все нормуль.

Нет дельты общие, время сохраняется не когда была забрана дельта , а то время которое указанно в дельте. дельта 1 deltaInfo/deltaId=1 дельта 2 deltaInfo/deltaId=2 дельта 3 deltaInfo/deltaId=3 дельта 4 deltaInfo/deltaId=4 isp1 getDumpDeltaList actualDate=2 ему вернется в списке дельта 3 и дельта 4, провайдер сохраняет у себя deltaId:4 isp2 getDumpDeltaList actualDate=1 ему вернется в списке дельта 2, дельта 3 и дельта 4, провайдер сохраняет у себя deltaId:4 isp3 getDumpDeltaList actualDate=3 ему вернется в списке дельта 4, провайдер сохраняет у себя deltaId:4 т.е. если вы пропустили формирование нескольких дельт вам вернуться все дельты начиная с следующей которая у вас есть. Повторюсь, такой же алгоритм в GIT, только отсутствует слияние так как синхронизация однонаправленная.

"Личный кабинет" написали деятели далекие от технических вопросов. На самом деле будет все тоже самое, только с бейсик (или что-то подобное, дока это умалчивает) авторизацией. Логины и пароли будут выдаваться в ручную, по запросу ISP в соответствующие органы. Также все организационные вопросы решаются там же. Для примера можно попросить тестовый ревизор, и оговорить временное окно на период проведения теста, в котором штрафовать не будут. (в чем я сильно сомневаюсь)

Не совсем так. Занесение в реестр производит команда "обученных" заносильщиков, при чем только в рабочее время. В дальнейшем они постигнут и темную сторону, т.е. будут заносить и ночью. Заносят раз в час, но есть случаи когда ресурс надо заблокировать немедленно, тогда будет внеочередная дельта. Кстати у дельт есть такой атрибут как empty, т.е. дельты штампуются без разницы есть изменения или нет.

Дельта не будет индивидуальна. Т.е. все добавленные записи "почикают" пачками с каким-то промежутком времени и сформируют дельты. У каждой дельты будет время создания, которое мы и должны хранить как последнюю актуальную версию и в дальнейшем запрашивать список дельт по этому таймштампу. в принципе те же комиты в git`е при git pull забираются все комиты от последнего известного комита, тут как раз все норм. Другое дело что сервак их будут насиловать 30К операторов раз в минуту и это может оказаться фатальным, хотя налогоплательщики оплатят очередной сервер.

1) Отсутствует метод sendRequest, ЭЦП теперь не нужна, авторизация по логину и паролю 2) формат дельт такой же как и полный список. Все записи "прошиты" id, если мы на своей стороне не имеем такую запись значит это insert, если такая запись есть значит это update 3) появилась новая запись <delete id="..."/> соответственно нужно удалить имеющуюся запись с таким же id 4) Новый метод запроса дельт в котором возвращается список дельт относительно переданного таймштампа, если глубина дельт большая и дельты были удалены, то придет код -1 который говорит о том что надо забрать полный список. В двух словах так.

Как сказал главный спикер конференции, старая система забора единого реестра будет поддерживаться до тех пор пока на новую систему не перейдут все провайдеры, а перейти они должны до конца года, но это еще не утверждено. Так или иначе в скором времени всех принудят выполнить переход, по крайней мере не раньше чем все сторонние разработки, которыми некоторые провайдеры пользуются, будут переведены на новый протокол. Даже после перехода на новый протокол время реагирования (до наступления санкций), по словам спикера, останется в приделах часа, дальше эта планка будет снижаться по мере статистики основанной на тестовых ревизорах. Время 1 минута "рекомендованное" (ага...) и это время предназначено для забора дельт а не для применения фильтрации.

Очень востребована! Возможность динамически устанавливать префиксы, и в дальнейшем по этим префиксам "рулить" на коммутаторе. Также выставлять категорию. У нас Операторов дальней связи 7 штук, и для нас это головная боль! Очень! Ждем вчера...

В настройки заходил ничего не отваливается, даже можно некие параметры поменять. vlc, ffmpeg|ffplay через некоторое время как-бы спотыкаются "замирают".

Поставил одну такую камеру на крышу, картинка и в правду хорошая, но! При непрерывном проигрывании потока с rtsp, где-то через 40 минут картинка зависает, саму камеру грузить не надо просто переконектиться. Для уточнения, проигрывал vlc 2.0 под linux Идея воспользоваться ffmpeg для записи, но ffmpeg поток с максимальным разрешение вообще забирать не хочет только 640x386 (ch01_0) ffmpeg также через некоторое время подвисает. Ни кто такого не замечал? прошивка последняя 1.1.3 PS такая связка софта нормально работает на других камерах с rtsp потоком, т.е. софт отлажен, может камера бракованная?

Для начала что у тебя за midlware?

Читай INSTALL/READMY пока константа, резерв DVBlast reads a configuration file containing one or several lines in the format : <IP>[:<port>] <always on> <SID> [<PID>,]*

Вообще, есть смысл собирать в железку типа Terayon DM6400/IVG7xxx/RGB BNP, например при наличии большого кол-ва каналов, желании зарезервировать схему, делать врезки рекламы и emergency channel, иметь единую точку мониторинга и управления и т.п. удобства и "рюшечки" которые на большом решении окупаются. IKUSI у меня сейчас на столе рядом, если народу интересно отчетец сделаю, сразу в IP отдает. Есть SNS101 не пробовал забрать ствол с большой символьной скоростью 44948 ? со скоростями ниже 30000 нормально