Каморка

Будет НТ сервис.
Помимо основной функциональности Сервис должен реагировать на команды управления. Типа показать список трэдов. Прибить трэд. Релоад сеттингс. И тп.
Команды посылаются с удаленной консоли управления. Удаленной - означает на другой машине в Виндовз сети (Домене).

Чего выбрать для управления?
Mailslots
Pipes
Sockets
Другое...

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

Ссылки на бэст практисы и примеры очень приветствуются.

Пайпы.
Есть секюрити, как тебе надо удобный интерфейс.
Майлслоты - не удобен для этих целей, если только не надо организовать систему посылки сообщений без гарантии что адресат запущен.
Сокеты - секюрити придется организовывать самому.

Бест практисез- уже третье приложение проктирую с пайпами, предыдущие два прекрасно работают.
Спрашивай если что.

aldep писал(а):Пайпы.
Есть секюрити, как тебе надо удобный интерфейс.
Майлслоты - не удобен для этих целей, если только не надо организовать систему посылки сообщений без гарантии что адресат запущен.
Сокеты - секюрити придется организовывать самому.

Бест практисез- уже третье приложение проктирую с пайпами, предыдущие два прекрасно работают.
Спрашивай если что.

Спасибо.

Как быть если несколько управляющих консолей будут коннектится? Например если первая консоль зависла и надо запустить вторую, но трубка уже залочена. Надо делать трэды как с сокетами или как?

Еще. Как насчет RPC? Нет ли опыта? Намного ли это сложнее? Возможно ли обойтись без Директори Сервиса если местоположение сервера с РП известно?

aldep писал(а):Пайпы.
Есть секюрити
[snip]

блажен кто верует. nt пайпы между машинами prone to DoS + priviledge escalation attacks.

MarkM писал(а):

aldep писал(а):Пайпы.
Есть секюрити, как тебе надо удобный интерфейс.
Майлслоты - не удобен для этих целей, если только не надо организовать систему посылки сообщений без гарантии что адресат запущен.
Сокеты - секюрити придется организовывать самому.

Бест практисез- уже третье приложение проктирую с пайпами, предыдущие два прекрасно работают.
Спрашивай если что.

Спасибо.

Как быть если несколько управляющих консолей будут коннектится? Например если первая консоль зависла и надо запустить вторую, но трубка уже залочена. Надо делать трэды как с сокетами или как?

Еще. Как насчет RPC? Нет ли опыта? Намного ли это сложнее? Возможно ли обойтись без Директори Сервиса если местоположение сервера с РП известно?

Несколько управляющих консолей без проблем, можно делать потоки, это самое простое, либо пытаться обрабатывать все в одном потоке, тут гемора гораздо больше.
Для каждого коннекта создается свой pipe instance, поэтому если одна зависнет на ругие это не влияет.

Насчет RPC опыта нет, это low level protocol, очень редко пользуются напрямую.
Если хочется что-то более красивое чем пайпы, я бы делал DCOM. Единственный минус, с которым столкнулся - трудности конфигурирования. Если с ними справится, то дальше работает замечательно.

drain bamage писал(а):

aldep писал(а):Пайпы.
Есть секюрити
[snip]

блажен кто верует. nt пайпы между машинами prone to DoS + priviledge escalation attacks.

Человеку надо было аутентификацию иметь.
Все приложение находится внутри виндового домена. Какой там DoS? Внимательное надо быть, гражданин.

5-копеек.

По поводу DCOM. Если это допустимо, то это возможно лучший вариант. По поводу трудностей конфинурации DCOM - замечено не было. Но я сам администрировал тот W2k-домен и сетки, поэтому знал, что и как делать. Поэтому, может это очень и очень субъективно. Допускаю, что если Mark работает в конторе, где есть не совсем качественное администрирование - могут быть и грабли.
Недостаток очевиден - только платформа NT + домен.

По поводу DoS, в том числе в локальной сети. Для DCOM, прикладных протоколов служб, работающих поверх RPC - это всегда было, и наверное, будет. Вспомните, хотя бы лавсан. Понятно, что можно и нужно пачить и т.д. Я только о том, что факт работы в лан ещё не повод к тому, что опасность DoS низка. 80% всего деструктивного - из лан. Это известный факт.

По поводу RPC. Опыт очень небольшой. Можно сказать, и нет опыта. Болванка для клиента и сервера делается достаточно быстро. Примеров, много, в том числе в SDK есть. Лично мне не нравится многодельностью и непонятность. Поддерживать такой проект будут только С-шники. Для проекта с продолжительным сроком - может быть не очень хорошо.

aldep писал(а):

drain bamage писал(а):

aldep писал(а):Пайпы.
Есть секюрити
[snip]

блажен кто верует. nt пайпы между машинами prone to DoS + priviledge escalation attacks.

Человеку надо было аутентификацию иметь.
Все приложение находится внутри виндового домена. Какой там DoS? Внимательное надо быть, гражданин.

RTFM, товарищ. DoS - denial of (arbitrary) service, далеко не всегда DoS is network-mounted, он может быть и local.

В случае с pipes, pipe-based сервис, написанный по модели обычной appilcation (или по примеру из msdn) может быть использован как локальными, так и удаленными underpiviledged процессами для поднятия своего priviledge level до админского. Я надеюсь понятно, почему это не ахти как хорошо.

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

drain bamage,
Может предложишь, что конструктивное?
Я допускаю, что у тебя здесь самый богатый опыт, по сравнению если не с остальными, то со мной. Так скажи, как сделать? Лично мне было б интересно твоё мнение о практических вещах послушать.

drain bamage писал(а): RTFM, товарищ. DoS - denial of (arbitrary) service, далеко не всегда DoS is network-mounted, он может быть и local.

И?

В случае с pipes, pipe-based сервис, написанный по модели обычной appilcation (или по примеру из msdn) может быть использован как локальными, так и удаленными underpiviledged процессами для поднятия своего priviledge level до админского. Я надеюсь понятно, почему это не ахти как хорошо.

Любое приложение работающее под может быть использованно потенциально для поднятия привилегий. Если ты мне объяснишь как это зависит от communication layer, то я буду благодарен.

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

Позволяю. Да уверен, поскольку предыдущее приложение работала и работает в Primus'e, National Bank и еще 5-6 организациях подобного размера. А нынешнее, уже почти год работает на 5-ти 8 процессорных application server, на которых параллельно работают еще 10 других тоже resource hungry приложений.

aldep писал(а):Насчет RPC опыта нет, это low level protocol, очень редко пользуются напрямую.
Если хочется что-то более красивое чем пайпы, я бы делал DCOM. Единственный минус, с которым столкнулся - трудности конфигурирования. Если с ними справится, то дальше работает замечательно.

[trn] Tak vrode naoborot pishut. RPC vyshe paipov, mozhet rabotat' cherez paipy tozhe.
DCOM ne hochu pochemu-to. Ne znaju. Pajpy mne blizhe, na sokety pohozhi. RPC on tozhe na RPC pohozh. A vot DCOM... Est' li primery serverov na DCOM? Da i naskol'ko eto racional'no, radi desjatka komand servisu, gorodit' DCOM?
[/trn][/trn]

MarkM писал(а):

aldep писал(а):Насчет RPC опыта нет, это low level protocol, очень редко пользуются напрямую.
Если хочется что-то более красивое чем пайпы, я бы делал DCOM. Единственный минус, с которым столкнулся - трудности конфигурирования. Если с ними справится, то дальше работает замечательно.

[trn] Tak vrode naoborot pishut. RPC vyshe paipov, mozhet rabotat' cherez paipy tozhe.
DCOM ne hochu pochemu-to. Ne znaju. Pajpy mne blizhe, na sokety pohozhi. RPC on tozhe na RPC pohozh. A vot DCOM... Est' li primery serverov na DCOM? Da i naskol'ko eto racional'no, radi desjatka komand servisu, gorodit' DCOM?
[/trn][/trn]

В плане remote invocation RPC более низкого уровня, чем DCOM.

Мне тоже не нравится DCOM, и уж тем более ради 10-ка комманд я бы не городил RPC.

MarkM,

Да и насколько ето рационально, ради десятка команд сервису, городить ДЦОМ?

Издевашься? Там всё уже "за тебя" давно сделано.
Знаешь хоть что-то проще, где в одном флаконе всё?

В плане remote invocation RPC более низкого уровня, чем DCOM.

Мне тоже не нравится DCOM, и уж тем более ради 10-ка комманд я бы не городил RPC.

Да, верно. Только пара акцентов и один вопрос.
DCOM использует RCP для маршалинга. А если быть точнее, то MS RPC.

Мне на самом деле интересно, а чем может не нравиться DCOM в вылезанной W2k сетке. И даже сетках, если нормальный админ.

Про RCP - а как с секуритей быть? С группами юзверей домена.

Ещё, MarkM... Сделай multithread приложение, затем наверни RPC чтоб с клиентами общаться, затем разберись с секурити, затем сделай COM-подобные обёртки, затем напиши ..... Короче, сделаешь свой DCOM вместо мелкософтовского. Оттестируешь и начнёшь юзать для прикладного своего проекта. Вернее для программирования.