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

← →
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 камер.

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

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

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

← →
Ega23 © (2007-09-18 12:32) [30]

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

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

← →
Ega23 © (2007-09-18 12:34) [31]

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

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

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

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

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

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

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

← →
homm © (2007-09-18 12:35) [33]

> [32] DVM © (18.09.07 12:34)
> получается от 5 до 15 Гб в сутки

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

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

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

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

← →
Ega23 © (2007-09-18 12:39) [35]

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

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

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

:)

← →
Ega23 © (2007-09-18 12:40) [36]

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

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

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

> [34] DVM © (18.09.07 12:38)
> Нет конечно.

А надо, ведь
> [28] Ega23 © (18.09.07 12:29)
> И это всего 6 камер.

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

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

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

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

> А надо, ведь

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

← →
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 очень тяжко.

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

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

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

← →
Суслик © (2007-09-18 15:54) [70]

> [64] Сергей М. © (18.09.07 15:38)

качнул
буду смотреть

← →
DiamondShark © (2007-09-18 16:16) [71]

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

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

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

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

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

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

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

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

← →
tesseract © (2007-09-18 16:24) [72]

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

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

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

> 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, без учёта их взаимного влияния. Отсюда все достоинства и недостатки.

← →
DiamondShark © (2007-09-18 17:55) [75]

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

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

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

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

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

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

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

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

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

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

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

← →
Anatoly Podgoretsky © (2007-09-18 19:30) [76]

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

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

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

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

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

← →
Anatoly Podgoretsky © (2007-09-18 20:58) [78]

> Вася Правильный (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 ?
> мне чё, перечислять все разрешения?
> будь гибче

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

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

> Ну каждый сам себе злобный буратин.

особенно в законах
что-то явно указано, как можно
что-то явно указано, как нельзя
а остальное? здесь-то от чего пляшут - от АП или от меня?

> Вася Правильный (18.09.07 21:13) [81]

Твой стакан явно наполовину пуст :) Не будь пессимистом ;)
А закон всегда един. Т.е. правило и список исключений :)

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

> правило и список исключений

это то, о чем говорил я
а пустой стакан - это для АП

> Вася Правильный (18.09.07 21:22) [83]
> это то, о чем говорил я

Ты не прав :)
Правила запрещают, а не разрешают :)
Разрешают исключения :)

> Вася Правильный (18.09.2007 21:06:19) [79]

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

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

> Правила запрещают, а не разрешают :)

после "ц" всегда "и"
исключения "цыган", "цыпленок", "цыпочка"
как оно? ;)

> Вася Правильный (18.09.07 22:03) [86]
> после "ц" всегда "и"
> исключения "цыган", "цыпленок", "цыпочка"
> как оно? ;)

Оно запрещает использовать после Ц все символы кроме И, за исключением :)
Собсно где-то так :)

> Сеть неопределённой топологии.

Даже если в "боевых" условиях возникнут препятствия, проблема решается средствами VPN, при этом софт, использующий NP, переделки не потребует.

> Прикладная задача подразумевает интенсивный датаобмен.

NP этому никак не препятствует.
Ну а разумный подход к минимизации прикладного траффика важен и при использовании любой транспортной технологии/механизма.

> Отсутствует опыт использования NP.

Для получения этого опыта и были рекомендованы компоненты.
И нет в использовании NP ничего архисложного, если, конечно же, не лезть в глубоко дебри асинхронного режима. А в Висте вообще красотища - простейший в понимании и использовании блокирующий режим (ничем не сложнее сокетного аналога) + новые возможности CancelIoEx.

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

Дима, ты под "плоской топологией сети" что подразумеваешь?

← →
Вася Правильный (2007-09-19 10:26) [90]

> Ega23 © (19.09.07 09:10) [89]
>
> Дима, ты под "плоской топологией сети" что подразумеваешь?

Та, которая одним сегментом. Без шлюзов и маршрутизаторов.

> Даже если в "боевых" условиях возникнут препятствия, проблема
> решается средствами VPN, при этом софт, использующий NP,
> переделки не потребует.

А зачем закладывать, пусть и гипотетическую и маловероятную (ха-ха! так всегда кажется), необходимость костылей?
Ведь можно не закладывать, при том, что разница в реализации где-то в пределах погрешности измерения...

> NP этому никак не препятствует.

Ну... Как сказать. Я вот на примере MSSQL (он имеет возможность выбора транспорта) померил: разница на больших объёмах передачи -- за 8%.

> Ну а разумный подход к минимизации прикладного траффика
> важен и при использовании любой транспортной технологии/механизма.

Демагогия в форме ухода от темы.

> Для получения этого опыта и были рекомендованы компоненты.

Демагогия в форме подмены тезиса.

> И нет в использовании NP ничего архисложного

Так и никто не говорит, что есть. Наоборот, программные модели очень похожи. Так ведь тем меньше оснований предпочесть NP.

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

> Та, которая одним сегментом. Без шлюзов и маршрутизаторов.

Да, именно такая. И другой никогда не будет.

> Я вот на примере MSSQL ..померил: разница на больших объёмах передачи -- за 8%.

Абсолютно ни о чем не говорящая цифирь, поскольку не приведены условия тестирования.

Цитата из msdn, касающаяся как раз твоих "измерений"
( http://msdn2.microsoft.com/en-us/library/ms187892.aspx )

Generally, TCP/IP is preferred in a slow LAN, WAN, or dial-up network, whereas named pipes can be a better choice when network speed is not the issue, as it offers more functionality, ease of use, and configuration options.

С учетом [93] и в предположении о достаточно хорошей пропускной способности и надежности сети Автора там ты и найдешь мои "аргументы в пользу".

← →
Sandman31 (2007-09-19 14:53) [95]

> Sandman31 (19.09.07 14:53) [95]

Из цитаты это как раз и не следует.

Зато следует, что TCP/IP предпочтителен для использования в условиях "медленной" сети, что вряд ли соответствует условиям Автора, коль скоро речь идет об организации трансляции видеопотоков.

По приведенной ссылке MS кратко и внятно разъясняет преимущества и недостатки разных механизмов в тех или иных условиях.

← →
Sandman31 (2007-09-19 15:16) [97]

Сергей М. © (19.09.07 15:09) [96]

8% - слишком незначительная разница, чтобы только на ее основе отдавать предпочтение. Значит, выигрыш настолько велик, что в случае медленной сети просто нет другой альтернатицы.
8% - это на больших объемах данных, на маленьких объемах выигрыш должен быть еще больше, ведь при бесконечном объеме данных разница между этими протоколами должна стремиться к нулю.

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

Ну а если проблема выбора сопряжена не только с производительностью, но и с безопасностью, то выбор NP как "все в одном флаконе" еще более очевиден)

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

Олег, по личному опыту применения:
1. DCOM - лучше не юзать.
2. NP - если взаимодействие укладывается в схему "запрос-ответ" с блокирующими чтениями/записями - хорошо подойдёт, но имей в виду, что доступность пайпов регулируется механизмом учётных записей винды.
3. TCP/IP - вполне адекватный вариант.

> TCP/IP - вполне адекватный вариант.

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

> NP - если взаимодействие укладывается в схему "запрос-ответ"

А в случае с сокетами при прочих равных условиях оно не укладывается что ли ?)

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

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

> Ega23 © (19.09.07 15:54) [101]

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

> Абсолютно ни о чем не говорящая цифирь, поскольку не приведены
> условия тестирования.

А я и не собирался мерить с точностью до миллилитра. Наличие избыточности очевидно из теории. Интересно было посмотреть, можно ли это качественно заметить "на глаз". Можно, как оказалось.

> там ты и найдешь мои "аргументы в пользу".

Демагогия в форме инверсии презумпции.

Если у тебя есть аргументы, то надо их просто перечислить, а не отсылать искать в мутном потоке сообщений. Это ж так просто: перечислить то, что знаешь. Правда, чтоб перечислить -- надо иметь.

> Зато следует, что TCP/IP предпочтителен для использования
> в условиях "медленной" сети, что вряд ли соответствует условиям
> Автора, коль скоро речь идет об организации трансляции видеопотоков.

Демагогия в форме некорректного следования.

Если что-то предпочтительно для одного, это не значит, что оно плохо для другого.

В данном случае предпочтительность TCP/IP для медленных сетей определяется меньшей, по сравнению с NP, вносимой избыточностью.
Ежу понятно, что и в быстрых сетях это не будет недостатком.

> но и с безопасностью, то выбор NP как "все в одном флаконе"
> еще более очевиден

Расскажи, что надо сделать, чтоб разграничить доступ к пайпу по юзерам.

> DiamondShark © (19.09.07 16:42) [104]

> Демагогия в форме инверсии презумпции.

> Демагогия в форме некорректного следования.

Тебя, кажется, давно приклинило на подчеркнутом)

Не замечаешь ?)

Зря)

Зачем надрывать пуп ради надрывания пупа ?)

А ведь, imho, именно этим ты сейчас и занят)

> Сергей М. © (19.09.07 17:14) [106]

О, коронный номер -- демагогия в форме перехода на личности.

> Тебя, кажется, давно приклинило на подчеркнутом)

Есть немножко)

Зато какая у тебя появилась возможность спрыгнуть с темы!
;)

> DiamondShark © (19.09.07 17:30) [107]
>
>

Признаюсь, у меня нет желания беседовать с параноидально настроенным оппонентом)

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

> Получил удовольствие

Я рад)

Автор топика, думаю, тоже оценил)

← →
Черный Шаман (2007-09-19 20:44) [111]

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

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

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