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

← →
Ega23 © (2007-09-18 10:48) [0]

Задача:
Есть некий сервер (условно - отдельная физическая машина). Выполняет функции видеоархива. На сервере крутится сервис. Есть N рабочих мест, с которых данному сервису шлётся команда забрать видеозапись с такого-то устройства и с такими-то параметрами.
На данный запрос сервис должен возвращать 2 ответа - запрос принят и запрос выполнен.
Также возможны запросы типа "живой - не живой"

Всё происходит в рамках Windows.

Собственно, вопрос: какую технологию лучше выбрать для общения между клиентом и сервисом?
Варианта пока 2: TCP\IP и DCOM.
посоветуйте, что лучше (а если есть другие варианты - то укажите их).

← →
Сергей М. © (2007-09-18 10:51) [1]

> какую технологию лучше выбрать для общения между клиентом
> и сервисом?

С учетом

> Всё происходит в рамках Windows

прямо таки напрашивается Named Pipes

← →
Ega23 © (2007-09-18 10:54) [2]

> прямо таки напрашивается Named Pipes

О. Про это не думал. Спасибо.
А в чём плюсы-минусы?

← →
Игорь Шевченко © (2007-09-18 10:54) [3]

Быстро/Дешево/Хорошо - выберите любые два

← →
Eraser © (2007-09-18 10:57) [4]

> Ega23 © (18.09.07 10:54) [2]

> А в чём плюсы-минусы?

скорость работы (теоретически), возможность разграничения прав доступа без доп. наворотов, вроде SSPI.

← →
Ega23 © (2007-09-18 11:13) [5]

> Игорь Шевченко © (18.09.07 10:54) [3]
>
> Быстро/Дешево/Хорошо - выберите любые два

Блин...
Затрудняюсь даже ответить.
Быстро - это точно. Хорошо - ну хотелось бы. Дёшево - это в каком смысле? Ресурсы?

← →
clickmaker © (2007-09-18 11:16) [6]

ну, быстрее всего - сокеты.
Медленнее и ресурсоемче - DCOM, но зато удобней в программировании
Пайпы - где-то между

← →
Сергей М. © (2007-09-18 11:17) [7]

> Ega23 © (18.09.07 11:13) [5]

Даже не задумывайся - в этих условиях юзай NP.

← →
Сергей М. © (2007-09-18 11:19) [8]

> быстрее всего - сокеты

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

← →
Игорь Шевченко © (2007-09-18 11:30) [9]

Ega23 © (18.09.07 11:13) [5]

Если быстро, то DCOM, если дешево, то TCP/IP, если хорошо, то Named pipes

← →
Ega23 © (2007-09-18 11:31) [10]

Проблема в том, что всё, что про NP знаю - это что статья Игоря есть... :)
Про остальное знаю чуть-чуть больше, но незначительно... :)
Так что самостоятельно оценить затраты/надёжность, к сожалению, пока не в состоянии. А делать надо, причём в ближайшее время.

← →
Сергей М. © (2007-09-18 11:36) [11]

> Ega23 © (18.09.07 11:31) [10]

Для самостоятельной оценки могу тебе дать пару пакетов с компонентами-оболочками NP-транспорта.

← →
Ega23 © (2007-09-18 11:41) [12]

> Для самостоятельной оценки могу тебе дать пару пакетов с
> компонентами-оболочками NP-транспорта.

Буду признателен.
egorov гав dedal.dubna.ru

← →
Rouse_ © (2007-09-18 11:42) [13]

Только если сеть доменная то в случае DCOM нужен грамотный админ...

← →
Ega23 © (2007-09-18 11:48) [14]

> Только если сеть доменная то в случае DCOM нужен грамотный
> админ...

Тут посоветовались, скорее всего действительно NP будем в качестве транспорта пользовать...

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

> Ega23 © (18.09.07 11:41) [12]

Мож еще кому-то сгодится:

http://slil.ru/24870267 (~16кб)
http://slil.ru/24870284 (~ 600кб)

← →
Ega23 © (2007-09-18 11:55) [16]

Спасибо!

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

> Ega23 © (18.09.07 11:55) [16]

Наверно, есть резон предупредить об одной засаде при использовании пайпов - отмена блокирующих вызовов, относящихся к операциям чтения/записи, для пайпов, функционирующих в Win9x/Me/NT/2000/XP, невозможна.

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

> Собственно, вопрос: какую технологию лучше выбрать для общения
> между клиентом и сервисом?
> Варианта пока 2: TCP\IP и DCOM.

Я бы TCP выбрал (собственно я и выбрал TCP, так как занимаюсь тем же). Ибо потом может захотеться все это связать и через интернет и прочее.

← →
Ega23 © (2007-09-18 12:15) [19]

> Ибо потом может захотеться все это связать и через интернет

Однозначно не захочется. Отраслевая специфика, однако... :))

← →
DVM © (2007-09-18 12:16) [20]

Еще причина, по которой был выбран TCP - это то что клиенты могут быть не только из под Win

> Ega23 © (18.09.07 10:48)

а для просмотра видеозаписи имхо лучше всего MotionJPEG по протоколу HTTP.

← →
Ega23 © (2007-09-18 12:16) [21]

> Наверно, есть резон предупредить об одной засаде при использовании
> пайпов - отмена блокирующих вызовов, относящихся к операциям
> чтения/записи, для пайпов, функционирующих в Win9x/Me/NT/2000/XP,
> невозможна.

Спасибо, будем иметь ввиду.

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

> DVM © (18.09.07 12:16) [20]

В случае с NP платформа клиента тоже не проблема.
Под линухом, скажем, есть Samba и WINE, в МакОСи тоже, если не изменяет память, есть механизмы поддержки виндовых пайпов.

← →
DVM © (2007-09-18 12:22) [23]

> Под линухом, скажем, есть Samba и WINE, в МакОСи тоже,

Линукс это еще куда ни шло, а вот когда таким клиентом окажется SymbianOS (большинство смартфонов) или Windows Mobile все будет сложнее. Хотя насчет последней я не уверен.

← →
Ega23 © (2007-09-18 12:22) [24]

> а для просмотра видеозаписи имхо лучше всего MotionJPEG
> по протоколу HTTP.

Насколько я понимаю, это зависит от того, в каком виде данное видео хранится...

← →
Ega23 © (2007-09-18 12:24) [25]

> Линукс это еще куда ни шло, а вот когда таким клиентом окажется
> SymbianOS (большинство смартфонов) или Windows Mobile все
> будет сложнее.

Поверь мне, никто не будет просмотривать на мобильнике видеотревоги с системы видеонаблюдения на "особо-важном" объекте... :)))

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

> Насколько я понимаю, это зависит от того, в каком виде данное
> видео хранится...

Формат хранения не очень важен, ты же можешь брать кадр из своего формата, зажимать на лету в JPEG и транслировать. Идеально, конечно, если хранится тоже в MotionJPEG.

А HTTP MotionJPEG очень удобно. Да и смотреть можно даже через браузер, например кажется опера понимает сама этот формат.

← →
DVM © (2007-09-18 12:28) [27]

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

У всех руководителей свои закидоны. Не знаю насчет ваших объектов, но от наших клиентов постоянно поступают различные просьбы подобного рода и смотреть они хотят чут ли не из мухосранского леса через GPRS на телефоне.

← →
Ega23 © (2007-09-18 12:29) [28]

> Формат хранения не очень важен

Важен. У нас сейчас 80 гиг за 6-9 часов (в зависимости от освещения) забивается. И это всего 6 камер.

> Важен. У нас сейчас 80 гиг за 6-9 часов (в зависимости от
> освещения) забивается. И это всего 6 камер.

Для последующей трансляции неважен. А в каком формате пишете то и в каком разрешении и с какой частотой кадров?

> но от наших клиентов постоянно поступают различные просьбы
> подобного рода и смотреть они хотят чут ли не из мухосранского
> леса через GPRS на телефоне.

Есть ещё такая штука, как "Закон о ГосТайне". Те клиенты, которые про него знают, подобными закидонами не страдают... :)

> А в каком формате пишете то и в каком разрешении и с какой
> частотой кадров?

Не знаю. Сходу не могу ответить, не я этим занимаюсь. Вроде что-то о JPEG2000 проскакивало. Разрешение - не в курсе, частота - вроде 6 кадров в секунду.

> Есть ещё такая штука, как "Закон о ГосТайне"

так бы сразу и говорил :)

> У нас сейчас 80 гиг за 6-9 часов

у меня в MotionJPEG с детектором движения 640*480*8 кадров/сек в оживленном месте (столовая например) получается от 5 до 15 Гб в сутки

> На 6 умножил? :)

Нет конечно. Так, что насчет объема можете не волноваться. У всех так.
Пережать на лету в MPEG - подобное что-то все рано не выйдет при большом числе камер без аппаратной поддержки, да и диски стоят копейки.

> у меня в MotionJPEG с детектором движения 640*480*8 кадров/сек
> в оживленном месте (столовая например) получается от 5 до
> 15 Гб в сутки

А требования к тревожному видеоархиву - вполне определённые. До 30 суток.

> На 6 умножил? :)

:)

> Так, что насчет объема можете не волноваться. У всех так.

Ты пойми, нам не надо, как "у всех". В том-то и проблема.

> Ты пойми, нам не надо, как "у всех". В том-то и проблема.

Это всем надо, чтобы лучше, чем у других. Но есть определенные рамки, задаваемые аппаратным обеспечением и ты хоть тресни, но один самый навороченный четырехядерный комп не потянет кодирование(декодирование) с 25 камер 640*480 (или 704*576) на лету даже в MotionJPEG, не говоря о MPEG4. Ограничения по шине уже начинают сказываться.

> А надо, ведь

А я разве говорю обратное? 6*15=90, т.е. те же 80 при другой частоте кадров и выходит.

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

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

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