Re[4]: Microsoft .NET Remoting - .NET

Статья:
Microsoft .NET Remoting

Авторы:
Мика Сухов

Аннотация:
В этой книге обсуждаются особенности функционирования и архитектуры .NET Remoting — новейшей технологии для построения распределенных приложений. Вы узнаете, как использовать беспрецедентные возможности этой технологии для построения отказоустойчивых, масштабируемых, защищенных, быстрых и простых в сопровождении и администрировании распределенных Интернет-приложений.

Здравствуйте, _FRED_, Вы писали:

_FR>Ещё необходимо упомянуть, что под фреймворк 1.1 примеры, использующие евенты, без небольшой доработки совсем не будут работать.
_FR>Но при использовании поиска на РСДН это легко обойти

Я вместил все это в одно предложение

Так же авторами не описаны специфичные проблемы и ошибки .NET Remoting, которые проявляются при более глубоком использовании технологии.

Здравствуйте, Мика Сухов, Вы писали:

МС>Статья:
МС>Microsoft .NET Remoting

Ещё необходимо упомянуть, что под фреймворк 1.1 примеры, использующие евенты, без небольшой доработки совсем не будут работать.
Но при использовании поиска на РСДН это легко обойти

Здравствуйте, Аноним, Вы писали:

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

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

А>Заранее благодарен, Я.

Re: отлов исключений для всех методов Remoting объекта

Здравствуйте, Аноним, Вы писали:

Ноду customErrors нужно вынести повыше:

А><configuration>
А>    <system.runtime.remoting>
А>        <customErrors mode="off"/>
А>        <application name = "Server">
А>            <channels>
А>                <channel ref = "tcp" port = "8888" />
А>            </channels>
А>        </application>
А>    </system.runtime.remoting>
А></configuration>

что по книге, то она достаточна мрачноватая. нет лёгкости восприятия

Как "гораздо более лучшую" рекомендую Advanced .NET Remoting, правда стоит 3000р... Я прочитал аглицкую — ощущения великолепные!

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Аноним, Вы писали:

А>что по книге, то она достаточна мрачноватая. нет лёгкости восприятия

Есть такое. На мой взгляд, такие книжки нужно всякими историями разбавлять или шутками. А то и впрямь читается туговато.

А>Как "гораздо более лучшую" рекомендую Advanced .NET Remoting, правда стоит 3000р... Я прочитал аглицкую — ощущения великолепные!

Она вышла на русском?

Здравствуйте, Аноним, Вы писали:

>> Нужно реализовать интерфейс ILogicalThreadAffinative

А>"Реализовать интерфейс" — слишком громко сказано. Просто создать класс-наследник от него.

Вообще то, интерфейсы именно реализуются.

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

Ключевое слово Call. Тоесть один раз на вызов — для двух разных вызовов (от двух клиентов, или от одного) будет разные CallContext, ибо разнве контескы, так как будут разные потоки. Нужно ли удалять на сервере использованные данные? Не помню, вроде они обратно клиенту отправляются (именно для этого и нужен интерфейс ILogicalThreadAffinative), и каждый раз на сервере CallContext заполняется заново.

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

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

Заранее благодарен, Я.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Я не Мика Сухов, но раз уж Вы обратились ко мне, то я купил эту книжку в московском Библио-глобусе. Правда это было в прошлом году. Честно скажу, что другой книги по этой же тематике я не встречал (да и не особо искал — в этой есть почти все, что надо!)

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Кстати, глубокоуважаемые глубокознавцы ремоутинга!
Не подскажете ли, как проще всего передать серверному объекту информацию, идентифицирующую активировавшего его клиента?
(Если это вообще возможно для WellKnow — SingleCall объекта).

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

в серверном приёмнике

ServerChannelSink

Я сделал в методе 2 дополнительных параметра IP и ID соединения, на клиенте в них пуляю "ничто", а в серверном примёнике подменяю аргументы на данные клиента. РАботает как часы...

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Спасибо!
К сожалению, remoting пока не является глвной моей проблемой

Я сделал вместо WellKnow объекта ClientActivated пока что меня это удовлетворило. (Посмотрим, на какие еще камни наткнусь)

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Мика Сухов, Вы писали:

МС>Статья:

МС>Авторы:
МС> Мика Сухов

МС>Аннотация:
МС>В этой книге обсуждаются особенности функционирования и архитектуры .NET Remoting — новейшей технологии для построения распределенных приложений. Вы узнаете, как использовать беспрецедентные возможности этой технологии для построения отказоустойчивых, масштабируемых, защищенных, быстрых и простых в сопровождении и администрировании распределенных Интернет-приложений.

Купил я эту книгу.
Написано все очень кратко и кое где не понятно.
Основное внимание уделено почемуто SOAP+HTTP и совсем забыто что есть еще и TCP+BINARY

Маклинновская тяжеловатая,
несколько раз принимался читать, но дальше обчной конфигурации ну и просто прямого CreateInstance в дочернем домене я не ушел.
Книга вроде и не плохая, но почему-то напрочь отбила у меня охоту заниматься приемниками, каналами, real proxy, контекстами и прочими примочами Remoting...

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Вчера таки купил ее. Слава Богу, стоит не 3000 р. а 300 р.
Отличная книга, надо сказать! Чтобы понять мои ощущения, надо сначала сделать приложение с ремоутингом а потом нарваться на противоречия. Во всех других книгах про .NET в ремоутинге дадьше "Hello, World" не продвинулись.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, wraithik, Вы писали:

W>Купил я эту книгу.
W>Написано все очень кратко и кое где не понятно.
W>Основное внимание уделено почемуто SOAP+HTTP и совсем забыто что есть еще и TCP+BINARY

Уделенно потому что сообщения SOAP "читабельнее" . Внимание в основном уделенно возможностям которые предоставляет Remoting при написании распределенных приложений. полезная книга.

Я не совсем понял подглаву об использовании ролевой защиты в .NET Remouting... (стр. 101) Имеется она, или нет? Или работает только в среде IIS?

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

К сожалению, в примерах от этой книги многое не работает

В частности, не могу добиться работы Спонсора Аренды (который в книжке почему-то называется спонсором лицензий).
При регистрации ISponsor получаю ошибку:
"Because of security restrictions, the type System.Runtime.Remoting.ObjRef cannot be assigned."

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

потому, как, батенька, надо форматтеру канала разрешить Фул левел...

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Я извиняюсь за свою врожденную (и благоприобретенную) тупость

Но в рассматриваемой здесь книге я подобных указаний по клиентской активации и настройке спонсора аренды не нашел. Нельзя ли короткий, но ёмкий примерчик?

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Аноним, Вы писали:
А>Но в рассматриваемой здесь книге я подобных указаний по клиентской активации и настройке спонсора аренды не нашел. Нельзя ли короткий, но ёмкий примерчик?

Поэтому "при использовании поиска на РСДН это легко обойти

"

А что мешает передавать "фоновые данные" через CallContext?
Вроде все получается весьма изящно... Или я не знаю каких-то подводных камней?

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Аноним, Вы писали:

А>А что мешает передавать "фоновые данные" через CallContext?
А>Вроде все получается весьма изящно... Или я не знаю каких-то подводных камней?

Нужно реализовать интерфейс ILogicalThreadAffinative

> Нужно реализовать интерфейс ILogicalThreadAffinative

"Реализовать интерфейс" — слишком громко сказано. Просто создать класс-наследник от него.
Но вопрос в другом. Не возникнет ли коллизий при работе нескольких объектов с контекстом? Например, если хранить в контексте удаленного объекта сведения о клиенте, который активировал этот объект, то не наложатся ли одни данные на другие в один прекрасный момент?
Может надо объявлять удаленные объекты контекстно зависимыми?
(Т.е. не просто MarshalByObject, a ContextBoundObject).
И не следует ли использовать новый контекст, а не контекст по умолчанию?

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Аноним, Вы писали:

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

Ничего не понял, ну и бог с ним.

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

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

Да я вообще не могу добиться получения клиентом осмысленных исключений, возникших "по вине" удаленного объекта.
Мне приходят только: "Server encountered an internal error. For more information, turn on customErrors in the server's config file"

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Аноним, Вы писали:

А>Да я вообще не могу добиться получения клиентом осмысленных исключений, возникших "по вине" удаленного объекта.
А>Мне приходят только: "Server encountered an internal error. For more information, turn on customErrors in the server's config file"

Под IIS работаешь? Так тебе нужна секция <customErrors> ибо всем этим делом уже не Remoting заведует, а ASP.NET

> Под IIS работаешь?
Нет. Не могу найти, как программно сконфигурировать сервер под обмен исключениями.
CustomErrorsEnabled вроде только для чтения...

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Аноним, Вы писали:

>> Под IIS работаешь?
А>Нет.

А что выступает в качестве хоста?

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

Это делается только конфигурацинно (по крайней мере, стандартными средствами).

Хост — простейшая консоль под виндами.

Конфигурационный файл:

<configuration>
<system.runtime.remoting>
<application name = "Server">
<customErrors mode="off"/>
<channels>
<channel ref = "tcp" port = "8888" />
</channels>
</application>
</system.runtime.remoting>
</configuration>

Не работает

Точнее, все работает, кроме получения клиентом исключений.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Спасибо!!! Это ОНО!

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Еще вопросец о контекстах, если Вас не затруднит.

Есть необходимость объединять группы ContextBoundObjects на апп.сервере под контекстами, создаваемыми для каждого клиета. Например, хранить персональный кэш, какие-то специфические данные о клиенте и т.п.
Есть ли возможность узнавать, кем инициирован контекст (каким клиентом)?

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

А>Еще вопросец о контекстах, если Вас не затруднит.

А>Есть необходимость объединять группы ContextBoundObjects на апп.сервере под контекстами, создаваемыми для каждого клиета. Например, хранить персональный кэш, какие-то специфические данные о клиенте и т.п.
А>Есть ли возможность узнавать, кем инициирован контекст (каким клиентом)?

Задача, как ты пишешь — хранить в общедоступном для объектов клиента месте какую-то информацию. А вопрос совсем про другое. Не проще ли завести клиентам идентификаторы и сделать единое общедоступное хранилище с ключом — идентификатором клиента/сессии?

> Не проще ли завести клиентам идентификаторы и сделать единое общедоступное хранилище с ключом — идентификатором клиента/сессии?

Вот именно, что для меня нынешнего (не понимающего бОльшую часть концепции .NET Remoting) это проще.
Но ведь наверняка есть изящные решения, заложенные производителями. Например, создавать общие контексты для одноименных серверных объектов, активированных разными клиентами, я научился. А вот создавать общие контексты для всех серверных объектов, активированных одним клиентом — пока нет. Т.к. не могу извлечь информацию о клиенте не из контекста, не из IConstructionCallMessage.
(Речь идет о WellKnownObjectMode.SingleCall)

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Hello, "Курдль"

> Но ведь наверняка есть изящные решения, заложенные производителями. Например, создавать общие контексты для одноименных серверных объектов, активированных разными клиентами, я научился. А вот создавать общие контексты для всех серверных объектов, активированных одним клиентом — пока нет. Т.к. не могу извлечь информацию о клиенте не из контекста, не из IConstructionCallMessage.
> (Речь идет о WellKnownObjectMode.SingleCall)
>

Если это SingleCall, то тут нужно учитывать, что клиент явно этот объект не создает. Он лишь вызывает метод, а создается объект уже автоматически.

Что-бы объединять несколько серверных объектов от одного клиента в один контекст, то лучше использовать CAO (ClientActivatedObject) и при создании первого объекта через envoy приемник передавать на клиента id его сессии.
При последующих запросах можно будет проверять пришедший id, выбирать нужный контекст и активироваться в нем.

Posted via RSDN NNTP Server 1.9 delta

Книга содержит массу опечаток, неточностей, ощибок, в том числе и в исходниках, которые никак нельзя скачасть c microsoft.com

Здравствуйте, Мика Сухов, Вы писали:

МС>Статья:
МС>Microsoft .NET Remoting

МС>Авторы:
МС> Мика Сухов

МС>Аннотация:
МС>В этой книге обсуждаются особенности функционирования и архитектуры .NET Remoting — новейшей технологии для построения распределенных приложений. Вы узнаете, как использовать беспрецедентные возможности этой технологии для построения отказоустойчивых, масштабируемых, защищенных, быстрых и простых в сопровождении и администрировании распределенных Интернет-приложений.

Здравствуйте, SBOS, Вы писали:

SBO>Книга содержит массу опечаток, неточностей, ощибок,

Это была первая книга по .NET Remoting. Главное в ней — лидерство. На сегодняшний день эта технология достаточно широко раскрыта в различных статьях (в том числе и на это м сайте), что число причин купить книгу значительно меньше, чем года два назад.

SBO>в том числе и в исходниках, которые никак нельзя скачасть c microsoft.com

А как ты узнал, что в них есть ошибки, если еще не скачал?

[url=http://www.ozon.ru/context/detail/id/1872730/>http://www.ozon.ru/context/detail/id/1872730/
http://www.ozon.ru/context/detail/id/1870119/

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

[url=http://www.ozon.ru/context/detail/id/1852609/>http://www.ozon.ru/context/detail/id/1852609/
http://www.ozon.ru/context/detail/id/1872730/

Отличные семплы на dotnetremoting.cc

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

http://www.ozon.ru/context/detail/id/1852609/
http://www.ozon.ru/context/detail/id/1872730/

Отличные семплы на dotnetremoting.cc

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Мика Сухов, Вы писали:
Подскажите пожалуйста оффлайн магазин, где можно купить эту книгу. Или хороший онлайн(быстрый+самовызов)!

От:	Мика Сухов	Stock#
Дата:	22.11.04 23:17
Оценка:	232 (7) +1

От:	mikа	Stock#
Дата:	23.11.04 09:26
Оценка:	+1

От:	_FRED_	@ViIvanov
Дата:	23.11.04 09:24
Оценка:	23 (2)

От:	_FRED_	@ViIvanov
Дата:	21.12.04 07:59
Оценка:	11 (1)

От:	Mika Soukhov	Stock#
Дата:	21.12.04 11:29
Оценка:	6 (1)

	От:	Вячеслав
	Дата:	29.11.04 07:50
	Оценка:

От:	TK	кывт.рф
Дата:	24.12.04 22:36
Оценка:

	От:	Аноним
	Дата:	24.11.04 07:06
	Оценка:	+1

	От:	Аноним
	Дата:	13.07.05 04:50
	Оценка:

	От:	Аноним
	Дата:	24.11.04 07:01
	Оценка:

	От:	Аноним
	Дата:	24.11.04 07:18
	Оценка: