Посоветуйте технологию

← →
homm © (2007-09-18 12:46) [40]

> [38] DVM © (18.09.07 12:44)
> даже в MotionJPEG, не говоря о MPEG4

Вроде в MPEG4 (не divX) должно быть быстрее, чем MJPEG…

← →
DVM © (2007-09-18 12:49) [41]

> Вроде в MPEG4 (не divX) должно быть быстрее, чем MJPEG

Это вряд ли. На два порядка сложнее алгоритм. Но все может быть. Но именно мне как раз кодировать в MJPEG не требуется ибо я получаю поток уже закодированный в MJPEG, т.к. мы работаем исключительно с IP камерами.

← →
Суслик © (2007-09-18 13:17) [42]

> [15] Сергей М. © (18.09.07 11:54)
> Мож еще кому-то сгодится:
> http://slil.ru/24870267 (~16кб)
> http://slil.ru/24870284 (~ 600кб)

К сожалению никак не открывается :(

Ссылка еще в силе?

Мне NP сейчас весьма актуальны. Знаю, что есть статья Игоря Шевченко, но больше источников информации - это не меньше.

← →
DVM © (2007-09-18 13:20) [43]

> Ссылка еще в силе?

да в силе она, проблемы у slil.ru

← →
Сергей М. © (2007-09-18 13:22) [44]

> Ссылка еще в силе?

"Слил" утверждает, что месяц должно храниться ..

← →
DiamondShark © (2007-09-18 14:00) [45]

> Сокеты-то может и "быстрые", да вот протоколы портят картину.

Какие протоколы? Какую картину?
TCP и Named Pipes -- оба протоколы транспортного уровня.
Кто где чего как портит?

← →
Сергей М. © (2007-09-18 14:08) [46]

> Какие протоколы? Какую картину?

А какие такие "сокеты" ?

Бессмысленно рассуждать о сокетах без привязки к тому или конкретному протоколу)

← →
Сергей М. © (2007-09-18 14:15) [47]

> TCP и Named Pipes -- оба протоколы транспортного уровня

NP - это не только протокол. И не столько протокол, сколько единый механизм, предназначенный для осуществления интерпроцессных коммуникаций.

← →
Сергей М. © (2007-09-18 14:21) [48]

И если уж сравнивать, то сравнивать NP именно с "сокет+трансп.протокол", а не с отдельно взятым трансп.протоколом

← →
DiamondShark © (2007-09-18 14:22) [49]

> Бессмысленно рассуждать о сокетах без привязки к тому или
> конкретному протоколу

Т.е. ты признаёшь, что возражение "да вот протоколы портят картину" на утверждение "быстрее всего - сокеты" -- это бессмыслица? Что ж. Тоже ответ.

Или ты по обыкновению влючил дурочку и "не заметил", что среди альтернатив рассматривался именно TCP?

← →
DiamondShark © (2007-09-18 14:27) [50]

> NP - это не только протокол. И не столько протокол, сколько
> единый механизм, предназначенный для осуществления интерпроцессных
> коммуникаций.

А стул -- это не только мебель. И не столько мебель, сколько единый механизм, предназначенный для осуществления сидения на попе.

Какую содержательную информацию несёт это жонглирование терминами?

> И если уж сравнивать, то сравнивать NP именно с "сокет+трансп.
> протокол", а не с отдельно взятым трансп.протоколом

Ага. Таки, включил.

← →
DiamondShark © (2007-09-18 14:37) [51]

Претензии к NP по сравнению с TCP

1. Закрытость. В принципе, не такая уж и проблема, если ориентироваться только на Вин. Но всё же. Зачем сознательно закладывать подводные камни (пусть и на очень глубоком месте;)), если можно не закладывать.

2. Проблемы с межсетевыми границами.

А вот достоинств не вижу вообще никаких.

← →
Суслик © (2007-09-18 14:44) [52]

> А вот достоинств не вижу вообще никаких.

для МЕНЯ достоинство - продукт НЕ должен работать в TCP.
ну чтобы люди использовали только в локалке.

(если, кстати, скажешь как это сделать в TCP, то буду рад. пока у меня сервер и клиент на ICS асинхронные неблокирующие. все работает, но хочу, чтобы не работало через internet).

← →
DVM © (2007-09-18 15:06) [53]

> для МЕНЯ достоинство - продукт НЕ должен работать в TCP.
>
> ну чтобы люди использовали только в локалке.

Какое же это достоинство? Имхо бред.

> но хочу, чтобы не работало через internet).

Запрети адреса из списка глобальных

← →
tesseract © (2007-09-18 15:10) [54]

> я получаю поток уже закодированный в MJPEG, т.к. мы работаем
> исключительно с IP камерами.

Mjpeg он только для редактирования хорош. Слишком много места жрёт, лучше mpeg/mp4 si,pe profile/h.264. Вейвлеты конечно места вообще не жрут - но вот формат/софт у каждого производителя свой.

← →
Сергей М. © (2007-09-18 15:12) [55]

> DiamondShark © (18.09.07 14:27) [50]

К чему эти твои ёрничание и ухмылки ?

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

Сокеты и NP можно "пощупать", для этого существует API (чего нет у транспортных протоколов как таковых)

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

← →
DiamondShark © (2007-09-18 15:13) [56]

> Суслик © (18.09.07 14:44) [52]

Ну, хоть это жёсткий оффтопик, отвечу.

> ну чтобы люди использовали только в локалке.

Анреально. По крайней мере, пока не определено, чем, скажем, виртуальная "локалка" поверх IP отличается от Истинной Локалки.

> но хочу, чтобы не работало через internet

Ну... Есть способ. Для истинных извращенцев. Работать через RAW-sockets и в IP-пакетах ставить TTL=1. Раненый джигит далеко не убежит.
;)
Правда, ума не приложу, что делать в случае, если сеть из двух сегментов с маршрутизатором.
Видимо, без определения "локалки", всё-таки, не обойтись.

← →
tesseract © (2007-09-18 15:15) [57]

> Видимо, без определения "локалки", всё-таки, не обойтись.

А типо уже можно с нета до любого компа в локалке достучаться ? Внутренний IP уже отменили ?

← →
Сергей М. © (2007-09-18 15:16) [58]

> 2. Проблемы с межсетевыми границами.

Палка о двух концах.

Нет этих границ - нет проблем, соответственно проще межсетевой протокол, что дает выигрыш в производительности.

← →
DVM © (2007-09-18 15:16) [59]

> Mjpeg он только для редактирования хорош.

Еще он позволяет мгновенно и покадрово перемещаться к любому кадру. Другие форматы этого не позволяют.
Также качество дает самое высокое.
Разрешение кадра любое.

А т.к. поток у меня уже закодирован, то перекодировать смысла нет ибо двойная работа. А все IP камеры вещают именно в MJPEG. Редко какие в MPEG4.

← →
Сергей М. © (2007-09-18 15:22) [60]

Named pipes are provided as a LAN Manager or Windows for Workgroups redirector component. The redirector uses the NetBIOS session layer which may be implemented over many data communications protocols such as NetBEUI or TCP/IP (NetBIOS over TCP/IP is sometimes referred to as RFC NetBIOS). Named pipe applications may be restricted in their use by operating system and network protocols.

On other network operating systems such as Novell Netware, named pipes are supported not by the redirector or NetBIOS session layer, but by a Novell IPX/SPX session layer.

Это к вопросу о тех самых "проблемах".

← →
DVM © (2007-09-18 15:23) [61]

> tesseract ©

И вот еще что: mpeg4 и подобные кодеки малоэффективны при низкой частоте смены кадров, что в больших системах само собой разумеющееся. При частоте кадров 4-5 коэффициент их сжатия резко падает по сравнению с MJPEG, при несопоставимо худшем качестве. Т.е. тут еще как посмотреть, что важнее в системе видеонаблюдения разглядеть лицо или писать месяц, но не очень детально.

← →
Сергей М. © (2007-09-18 15:24) [62]

> ума не приложу, что делать в случае, если сеть из двух сегментов
> с маршрутизатором

Вполне решаемо средствами VPN.

← →
DiamondShark © (2007-09-18 15:37) [63]

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

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

Ты всё ещё считаешь выражение "включать дурочку" ёрничаньем? А по-моему, так это непреложный факт.

> в то время как сокеты предоставляют такую возможность, соответственно
> можно оценивать производительность сокет-транспорта при
> задействовании того или иного протокола.

Ну, раз уж мы утрясли все неясности относительно того, что считать протоколом, API и механизмом, давай вернёмся к вопросу, из-за которого весь сыр-бор: какой именно "тот или иной" протокол "портит картину"?

← →
Сергей М. © (2007-09-18 15:38) [64]

> Суслик

Ну ты качнул со Слива то что я выложил ?

Вроде ожил Бачок)

Я к тому, что в малом (16кб) архиве есть readme, к нему надо отнестить с достаточной долей внимания.

← →
Сергей М. © (2007-09-18 15:41) [65]

> какой именно "тот или иной" протокол "портит картину"?

Картину портит именно TCP - тяжел он для задач Автора)

Или у тебя есть возражения ?

← →
tesseract © (2007-09-18 15:41) [66]

> Редко какие в MPEG4.

Сейчас уже 90%.

← →
Eraser © (2007-09-18 15:44) [67]

http://support.microsoft.com/kb/128985
http://msdn2.microsoft.com/en-us/library/aa178138(sql.80).aspx

← →
DVM © (2007-09-18 15:45) [68]

> Сейчас уже 90%.

Ну ты загнул. Через меня прошло около 500 моделей нескольких десятков производителей (пожалуй я о IP камерах знаю все:) и уверяю тебя MPEG4 есть только в попсовых SOHO камерах. MJPEG же присутствует во всех.
Ибо разрешение 1600*1200 или 60 кадров/сек или несколько десятков пользователей для MPEG2/4 очень тяжко.

> Ибо разрешение 1600*1200 или 60 кадров/сек или несколько
> десятков пользователей для MPEG2/4 очень тяжко.

Возможно. Архив можно на отдельном серваке с аппаратной картой перегонять в MPEG - и на кассеты.

> Сергей М. ©
> > 2. Проблемы с межсетевыми границами.
> Палка о двух концах.
> Нет этих границ - нет проблем,

Т.е. в требования к программе надо включить пункт: "Плоская топология сети"
Не слишком ли жирно?

> соответственно проще межсетевой
> протокол, что дает выигрыш в производительности.

Бредить изволите?
Напомню: Named Pipes -- это транспортный уровень. Преодоление межсетевых границ решается (или не решается) в протоколах более низшего уровня.

> Картину портит именно TCP - тяжел он для задач Автора)
>
> Или у тебя есть возражения ?

Возражения ты сам привёл в [60]: NP реализован поверх других протоколов, в частности, поверх NetBIOS session layer, который, в свою очередь, реализован поверх TCP/IP.
Аналогичные протоколы в не-IP сетях (тот же приведённый в пример IPX/SPX) не намного "легче" TCP/IP.

Таким образом, NP никак не может (в IP сетях -- уж стопудово) быть "легче" TCP.

Кстати, поддержка IPX/SPX вполне может испариться из каких-нибудь новых версий Вин. Почему? Очень просто: проприетарный протокол. Надоест Мелкософту башлять Новелу -- и уберёт.
А открытый TCP/IP -- вечен.

> Надоест Мелкософту башлять Новелу -- и уберёт.

Он лицухи не требует. И новелл сама его уже похоронила. Почему ? Да в средних сетях уже маршрутизация лагает аж смерть.

> DiamondShark © (18.09.07 16:16) [71]
>
>

> в требования к программе надо включить пункт: "Плоская топология
> сети"

Не передергивай.
Плоскую топологию обозначил сам Автор.
Если он ошибся - это его проблемы.

> Преодоление межсетевых границ решается (или не решается)
> в протоколах более низшего уровня

На то и существует Use NetBIOS over TCP/IP.

NP-транспорт - это, если угодно, "транспорт над транспортом".

> NP никак не может (в IP сетях -- уж стопудово) быть "легче"
> TCP.
>

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

← →
Sapersky (2007-09-18 17:38) [74]

Относительно MJPEG следует, наверное, уточнить, что это просто последовательность кадров сжатых в jpeg, без учёта их взаимного влияния. Отсюда все достоинства и недостатки.

> Плоскую топологию обозначил сам Автор.

Цитату от Автора можно увидеть?

> На то и существует Use NetBIOS over TCP/IP.

Лишнее требование к операционному окружению приложения, совершенно необоснованное с точки зрения планируемого функционала. Появляющееся только из-за "а не прикрутить ли нам такой транспорт".

> NP-транспорт - это, если угодно, "транспорт над транспортом".

Об чём и речь. Как нам это интерпретировать в свете "протоколы портят картину"?

> И скажет, где правда в его условиях

"Вот он проснется и, конечно, скажет.
Пусть жизнь осудит, да? Пусть жизнь накажет."

> которые пока понятны и не вызывают у меня сомнений.

Ну вот самое время эти самые условия собрать вместе. По озвученному, а не как кому воображается.
Итак, имеем:
Сеть неопределённой топологии.
Прикладная задача подразумевает интенсивный датаобмен.
Отсутствует опыт использования NP.

Какие резоны к использованию NP?

> DVM (18.09.2007 15:06:53) [53]

Надо не запрещать, это плохой путь, а разрешать.

← →
Вася Правильный (2007-09-18 20:49) [77]

> Надо не запрещать, это плохой путь, а разрешать.

если запретить проще, чем разрешить,то лучше запрещать
если же запрещаемое сложнее, тяжелее, то лучше указать, что разрешено

> Вася Правильный (18.09.2007 20:49:17) [77]

Сначала все запрещается (по умолчанию) потом разрешается только нужное. Обычные принципы работы файрволов. Запрещать 4 миллиарда адресов тяжело, а вот разрешить только несколько нужных просто и не стоит беспокоиться об остальном.

← →
Вася Правильный (2007-09-18 21:06) [79]

> Anatoly Podgoretsky © (18.09.07 20:58) [78]

а если я хочу все разрешить, кроме udaff.com ?
мне чё, перечислять все разрешения?
будь гибче

> Вася Правильный (18.09.07 21:06) [79]
>
> > Anatoly Podgoretsky © (18.09.07 20:58) [78]
>
> а если я хочу все разрешить, кроме udaff.com ?
> мне чё, перечислять все разрешения?
> будь гибче

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

Посоветуйте технологию Найти похожие ветки