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

← →
Rouse_ © (2007-09-18 21:08) [80]

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

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

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

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

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

← →
Rouse_ © (2007-09-18 21:18) [82]

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

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

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

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

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

← →
Rouse_ © (2007-09-18 21:46) [84]

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

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

← →
Anatoly Podgoretsky © (2007-09-18 21:47) [85]

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

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

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

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

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

← →
Rouse_ © (2007-09-18 22:24) [87]

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

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

← →
Сергей М. © (2007-09-19 08:36) [88]

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

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

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

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

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

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

← →
Ega23 © (2007-09-19 09:10) [89]

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

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

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

> Rouse_ © (18.09.07 22:24) [87]

зануда :/

← →
DiamondShark © (2007-09-19 14:01) [91]

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

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

← →
DiamondShark © (2007-09-19 14:23) [92]

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

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

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

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

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

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

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

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

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

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

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

← →
Ega23 © (2007-09-19 14:32) [93]

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

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

← →
Сергей М. © (2007-09-19 14:49) [94]

> Я вот на примере 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]

Сергей М. © (19.09.07 14:49) [94]

Из цитаты MSDN следует, что скорее всего разница больше чем 8%.

← →
Сергей М. © (2007-09-19 15:09) [96]

> 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% - это на больших объемах данных, на маленьких объемах выигрыш должен быть еще больше, ведь при бесконечном объеме данных разница между этими протоколами должна стремиться к нулю.

← →
Сергей М. © (2007-09-19 15:33) [98]

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

← →
Сергей М. © (2007-09-19 15:43) [99]

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

← →
Alkid © (2007-09-19 15:47) [100]

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

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

← →
Ega23 © (2007-09-19 15:54) [101]

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

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

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

> 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 могут грабли с безопасностью, очень уж гиморно с безопасностью, если компьютер не в домене или как-то хитро выпал из домена(что тоже бывает).

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