Для клиента ответ может быть коротким. Как только клиент вызывает метод для удаленного объекта, мы получаем исключение типа System.Runtime.Remoting.RemotingException. Необходимо просто обработать это исключение и сделать, например, повторную попытку или записать в журнал, информировать пользователя и т.д.
А что же сервер? Когда сервер обнаруживает, что клиент отсутствует (что означает возможность очистить ресурсы, которые он удерживает для клиента)? Если ждать следующего вызова метода с клиента, он может никогда не появиться. В области COM протокол DCOM использовал механизм ping. Клиент посылал на сервер ping с информацией об используемых объектах. Так как клиент мог иметь на сервере сотни используемых клиентов, то, чтобы сделать этот механизм более эффективным, посылалась информация не обо всех объектах, а только о различии с предыдущим ping.
Этот механизм был эффективен в LAN, но не подходит для Интернета. Подумайте о тысячах или миллионах клиентов, посылающих ping-информацию на сервер. .NET Remoting использует существенно лучшее масштабируемое решение для управления временем жизни — LDGC (Leasing Distributed Garbage Collector — Сборщик мусора распределенной аренды.
Это управление временем жизни активно только для активизированных клиентом объектов. Объекты SingleCall могут разрушаться после каждого вызова метода, так как они не сохраняют состояние. Активизированные клиентам объекты имеют состояние и нам необходимо знать о ресурсах. Для активизированных клиентом объектов, на которые ссылаются из вне домена приложения, создается аренда. Аренда имеет время аренды. Когда время аренды достигает нуля, аренда заканчивается, удаленный объект отсоединяется и, наконец, мусор убирается.
Для управления временем жизни можно сконфигурировать следующие значения:
□ LeaseTime определяет время, пока не закончится аренда.
□ RenewOnCallTime является временем, которое аренда задает для вызова метода, если текущее время аренды имеет меньшее значение.
□ Если спонсор недоступен в течение SponsorshipTimeout, то удаленная инфраструктура ищет следующего спонсора. Если больше нет спонсоров, аренда заканчивается.
□ LeaseManagerPollTime определяет интервал времени, в течение которого менеджер аренды проверяет отслуживший объект.
Конфигурация аренды Значение по умолчанию (секунды) LeaseTime 300 RenewOnCallTime 120 SponsorshipTimeout 120 LeaseManagerPollTime 10
Обновление аренды
Как показано в таблице, время аренды по умолчанию для объекта составляет 300 секунд. Если клиент вызывает метод на объекте, когда аренда истекла, возникает исключение. Если имеется клиент, где удаленный объект может понадобиться на время более 300 с, то существует три способа обновления аренды:
□ Неявное обновление делается автоматически, когда клиент вызывает метод на удаленном объекте. Если текущее время аренды меньше, чем значение RenewOnCallTime, то аренда задается как RenewOnCallTime.
□ При явном обновлении клиент определяет новое время аренды. Это делается с помощью метода Renew() из интерфейса ILease. Доступ к интерфейсу ILease можно получить, вызывая метод GetLifetimeService() на прозрачном прокси.
□ Третьей возможностью обновления аренды является спонсорство. Клиент может создать спонсора, который реализует интерфейс ISponsor и регистрирует спонсора в службах аренды с помощью метода Register() из интерфейса ILease. Когда аренда заканчивается, у спонсора запрашивают ее продления. Механизм спонсорства используется, если на сервере требуются долгоживущие удаленные объекты.
Классы, используемые для управления временем жизни
ClientSponsor является спонсором, который реализует интерфейс ISponsor. Он применяется на клиентской стороне для продления аренды. С помощью интерфейса ILease можно получить всю информацию об аренде, все свойства аренды, а также время и состояние текущей аренды. Состояние определяется с помощью перечисления LeaseState. С помощью служебного класса LifetimeServices можно получить и задать свойства аренды для всех удаленных объектов в домене приложения.
Пример: получение информации об аренде
В этом небольшом примере кода доступ к информации аренды осуществляется с помощью вызова метода GetLifetimeService() на прозрачном прокси. Для интерфейса ILease необходимо открыть пространство имен System.Runtime.Remoting.Lifetime:
Помните, что эти действия годятся только для активизированных клиентом объектов. Экземпляры объектов SingleCall создаются для каждого вызова метода, поэтому механизм аренды не используется.
ILease lease = (ILease)obj.GetLifetimeService();
if (lease != null) {
Console.WriteLine("Lease Configuration:");
Console.WriteLine(
"InitialLeaseTime: " + lease.InitialLeaseTime);
Console.WriteLine(
"RenewOnCallTime: " + lease.RenewOnCallTime);
Console.WriteLine(
"SponsorshipTimeout: " + lease.SponsorshipTimeout);
Console.WriteLine(lease.CurrentLeaseTime);
}
В результате получается следующий вывод в окне клиентской консоли:
Изменение используемых по умолчанию конфигураций аренды
Сам сервер может изменить используемую по умолчанию конфигурацию аренды для всех удаленных объектов, используя служебный класс System.Runtime.Remoting.Lifetime.LifetimeServices:
LifetimeServices.LeaseTime = TimeSpan.FromMinutes(10);
LifetimeServices.RenewOnCallTime = TimeSpan.FromMinutes(2);
Если требуются другие используемые по умолчанию значения параметров времени жизни, в зависимости от типа удаленного объекта, можно изменить конфигурацию аренды удаленного объекта, переопределяя метод InitializeLifetimeService() базового класса MarshalByRefObject:
public class Hello : System.MarshalByRefObject {
public Hello() {
Console.WriteLine("Constructor called");
}
~Hello() {
Console.WriteLine("Destructor called");
}
public override Object InitializeLifetimeService() {
ILease lease = (ILease)base.InitializeLifetimeService();
lеase.InitialLeaseTime = TimeSpan.FromMinutes(10);
lease.RenewOnCallTime = TimeSpan.FromSeconds(40);
return lease;
}
}
Конфигурация служб времени жизни также задается с помощью конфигурационного файла.
Конфигурационные файлы
Вместо записи конфигурации канала и объекта в исходном коде, можно использовать конфигурационные файлы. Таким способом реконфигурируют канал, добавляют дополнительные каналы и т.д., не изменяя исходный код. Для этого, как и для всех других конфигурационных файлов на платформе .NET. используется XML на основе тех же самых приложений, о которых было написано в главе 10. В те же самые файлы в главе 25 будет добавлена конфигурация системы безопасности. В .NET Remoting имеются атрибуты и элементы XML для конфигурирования канала и удаленных объектов. Файл должен иметь то же самое имя, что и исполнимый файл, за которым следует .config. Для сервера HelloServer.exe конфигурационным файлом будет HelloServer.exe.config. В коде, загружаемом с web-сайта издательства Wrox, можно найти примеры конфигурационных файлов в корневом каталоге примеров с именами clientactivated.config, wellknown.config и wellknownhttp.config. Чтобы воспользоваться ими, переименуйте их, как показано выше, и поместите в каталог, содержащий исполнимый файл.
Вот только один пример, как мог бы выглядеть такой файл. Мы рассмотрим все различные конфигурационные параметры:
<configuration>
<system.runtime.remoting>
<application name="Hello">
<service>
<wellknown mode="SingleCall" type="Wrox.ProfessionalCSharp.Hello, RemoteHello" objectUri="Hi" />
</service>
<channels>
<channel type="System.Runtime.Remoting.Channels.Tcp.TcpChannel, System.Runtime.Remoting" port="6791" />
<channel type="System.Runtime.Remoting.Channels.Http.HttpChannel, System.Runtime.Remoting" port="6792" />
</channels>
</application>
</system.runtime.remoting>
</configuration>
<configuration> является корневым элементом XML для всех конфигурационных файлов .NET. Все удаленные конфигурации можно найти в подэлементе <system.runtime.remoting>. <application> является подэлементом <system.runtime.remoting>.
Посмотрим на основные элементы и атрибуты в <system.runtime.remoting>:
□ В элементе <application> определяется имя приложения с помощью атрибута name. На серверной стороне это имя сервера, а на клиентской стороне — имя клиентского приложения. Пример серверной конфигурации <application name="Hellо"> определяет имя удаленного приложения Hello, которое используется клиентом как часть URL для доступа к удаленному объекту.
