В рамках проекта создаются защищенный TCP (через SSPI) и Named Pipes каналы для использования везде, где вы до этого использовали стандартный TCP или DCOM. Что-то похожее появиться в .NET 2.0, ну а пока предлагаю воспользоваться тем, что есть. Кроме того, есть действительно уникальная вещь — unmanaged клиент для .NET remoting (собственный канал + форматтер + реализация на C++).
Как мне кажется данный проект может также быть интереснен тем, кто хочет разобраться в/читает лекции по .NET Remoting. Все-таки код в rotor'е не подарок. Хотя на вкус на цвет...
Проект находится на стадии разработки (сейчас прикручиваю SSPI) — любые предложения приветствуются.
В любом случае, велкам!
09.11.04 13:05: Перенесено модератором из '.NET' — TK
Ну тут проблем несколько:
1. В примере из MSDN обертка над SSPI реализова на managed C++, чего можно избежать (это помимо того, что в версии .NET < 2.0 managed C++ прямо скажем... недоделан)
2. Аутентификация прикручена к каналу кастомными синками, что с отдной стороны хорошо (это стандартный способ расширения фугкциональности канала), а с другой плохо: в этом случае канал ничего не знает о аутентификации, а значит не может адекватно отреагировать на access denied. В нашем проекте подразумевается наличие unmanaged клиента, в коде которого нет никакого резона наворачивать функциональность синков — просто получили от сервера статус ACCESS_DENIED и отреагировали аутентификацией.
3. Нет поддержки SChannel и Basic/Digest
4. Хочется написать самому
Но на самом деле решение еще не принято окончательно, вполне возможно, что я склонюсь в сторону использования синков.
Hello, "Vadim Skipin" > > Ну тут проблем несколько: > 1. В примере из MSDN обертка над SSPI реализова на managed C++, чего можно избежать (это помимо того, что в версии .NET < 2.0 managed C++ прямо скажем... недоделан)
А чем плох managed C++? это-же не J# за которым нужно некоторый runtime тащить. Без WinAPI все равно тут вряд-ли обойтись...
> 2. Аутентификация прикручена к каналу кастомными синками, что с отдной стороны хорошо (это стандартный способ расширения фугкциональности канала), а с другой плохо: в этом случае канал ничего не знает о аутентификации, а значит не может адекватно отреагировать на access denied. В нашем проекте подразумевается наличие unmanaged клиента, в коде которого нет никакого резона наворачивать функциональность синков — просто получили от сервера статус ACCESS_DENIED и отреагировали аутентификацией.
А зачем об этом знать каналу? Это как если-бы в случае окончания бензина в машине дорога-бы реагировала увеличением угла своего наклона
Хотя, возможно, что для unmanaged клиента проще все поместить в
> 3. Нет поддержки SChannel и Basic/Digest
Можно добавить. Там-же достаточно расширяемая архитектура (в второй версии того примера)...
> 4. Хочется написать самому >
Posted via RSDN NNTP Server 1.9 alpha
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Нет, привязка к Negotiate/Kerberos/NTLM там все равно есть. Начать с того, что для SChannel/Digest нужен другой набо буферов. А лоика Sign/Encrypt помещена в контекст (что неверно). Мне больше нравится подход m$ в классе WebClient.
А про синки вопрос действительно непростой. С одной стороны так действительно правильнее (зачем транспортному уровню знать что-то о приложении?), а с другой попробуйте на клиенте отличить AccessDenied от чего-то другого. Конечно, это в случае если вы пишете клиента на C++ или не используете BinaryFormatter (т.к. он просто передаст объект исключения).
Кстати говоря, по beta .NET2.0 можно судить о применимости кастомных синков: всю аутентификацию они также затолкали в транспортный уровень.
Где-то в этом форуме уже пробегал топик с реализацией своего безопасного канала на Ремотинге. Мое мнение таково. Использовать такой канал, когда уже есть в MSDN готовая реализация, вряд ли кто будет. Нужна хорошая поддержка, а без нее никто не решится рисковать. Единственное истересное решение — это связь с unmanaged клиентами через Ремотинг. Кстати, http://www.gotdotnet.ru/News/DevNews/86527.aspx такая же идея
Re: Custom .NET Remoting channels
От:
Аноним
Дата:
08.11.04 21:17
Оценка:
Дело хорошее! Наличие подобной библиотеки может многим упростить жизнь, особенно тем, кто пока в remoting'е не бум-бум (мне, например).
А что дадут Named Pipes? Насколько это лучше/быстрее, чем tcpchannel?
А "собственный канал + форматтер + реализация на C" чем хорош? Быстрее? Насколько?
Что означает фраза "Проект находится на стадии разработки (сейчас прикручиваю SSPI)"? SSPI еще прикручен, что не доделано?
Хорощо бы еще документацию какую-нибудь. Не планируется?
P.S. Я пробовал то, что предлагает MS в MSDN — это 2 библиотеки SSPI и Security, сейчас это и использую. Как-то тестил слегка это дело. Где-то в течении 2 минут на с нескольких компов в несколько потоков создавал CAO, который еще и в БД лез. Всего за это время было 8000 созданий объекта, из них 60 с ошибкой и все разы на SSPI-ой библиотеке от MS, хотя может дело было в чем-то другом. У меня такой нагрузки в реальности нет, да и процент отшибки не особо высок, так что забил на это.
По поводу примера использования SSPI из MSDN могу сразу сказать, что реализация хромает — можно написать более эффективный код.
C++ клиент нужен там, где не предполагается использовать .NET на клиенте, однако на сервере крутиться managed объект.
NamedPipes намного быстрее TCP в случае локального взаимодействия (IPC), к тому же протокол аутентификации NTLM там уже реализован.
Что касается проекта dvremoting, то разработка сейчас идет полным ходом. В скором времени я обновлю CVS — изменилось довольно много (в основном bugfix + настройка произволительности), но синки для аутентификации пока еще отстутствуют (ничто не мешает на этом этапе использовать код из MSDN).
По поводу производительности каналов в случае IPC (массив байт пересылается на сервер и затем возвращается клиенту):
Hello, "alex2000" > > P.S. Я пробовал то, что предлагает MS в MSDN — это 2 библиотеки SSPI и Security, сейчас это и использую. Как-то тестил слегка это дело. Где-то в течении 2 минут на с нескольких компов в несколько потоков создавал CAO, который еще и в БД лез. Всего за это время было 8000 созданий объекта, из них 60 с ошибкой и все разы на SSPI-ой библиотеке от MS, хотя может дело было в чем-то другом. У меня такой нагрузки в реальности нет, да и процент отшибки не особо высок, так что забил на это. >
В реализации от MS есть пару ошибок связанных с освобождением ресурсов. Если их исправить, то все работает нормально...
Posted via RSDN NNTP Server 1.9 alpha
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[2]: Custom .NET Remoting channels
От:
Аноним
Дата:
09.11.04 18:26
Оценка:
To Vadim Skipin:
А эти тесты когда клиент и сервер на одной машине или на разных? Мне просто интересно, насколько будет выиграш Named Pipes, когда и клиент и сервер на разных машинах.
To TK: > В реализации от MS есть пару ошибок связанных с освобождением ресурсов. Если их исправить, то все работает нормально...
Ты случайно сам не правил? Если правил, то не мог бы поделиться?
Здравствуйте, Аноним, Вы писали:
А>To Vadim Skipin: А>А эти тесты когда клиент и сервер на одной машине или на разных? Мне просто интересно, насколько будет выиграш Named Pipes, когда и клиент и сервер на разных машинах.
Эти тесты запускались на одной машине.
Вообще говоря, NamedPipes не является протоколом транспортного уровня, он реализован в виде файловой системы и, следовательно, в случае удаленного взаимодействия будет использован редиректор (SMB, CIFS и т.д.), а пакеты при этом могут ходить по NetBIOS или по тому же TCP/IP. Однако, в любом случае, если Вам нужна встроенная аутентификация, то NamedPipes будет однозначно быстрее чем связка MS-TCP + MSDN-SSPI.
