Сообщений 18    Оценка 1180 [+1/-0]         Оценить

Технологии построения распределенных приложений в .NET

Часть 1. Пространство имен System.Net

Автор: Мика Сухов
Источник: RSDN Magazine #2-2004

Опубликовано: 06.11.2004
Исправлено: 10.12.2016
Версия текста: 1.0

Вступление Сокеты Протокол TCP Протокол UDP Протокол HTTP Протокол SMTP Сетевая статистика Безопасность на основе доступа к коду Не реализованные технологии Заключение

Исходные тексты (Whidbey beta1)
Исходные тексты (VS 2003)

Вступление

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

Сокеты

Сокеты появились тогда, когда начали создавать первые системы распределенных вычислений. И, скорее всего, о них еще не скоро забудут. Их любят многие за гибкость и простоту в использовании. На их основе можно очень быстро и просто сделать первый прототип любого распределенного приложения. Присутствуют они и в .NET (System.Net.Sockets). В листинге 1 представлен простейший пример взаимодействия “клиент-сервер”.

Листинг 1. Пример простого “клиент-сервер” взаимодействия, которое пересылает данные по сокету из одного участка программы в другой ;o).

      private
      static
      void OnBeginAccept(IAsyncResult ar)
{
  Socket listener = (Socket)ar.AsyncState

  using (Socket client = listener.EndAccept(ar))
  {
    byte[] buffer = newbyte[_bufferSize];

    // Получаем данные от клиента.
    client.Receive(buffer);
    buffer = Encoding.UTF8.GetBytes(string.Format("Hello, {0}", 
      Encoding.UTF8.GetString(buffer)));

    // Отправляем клиенту ответ.
    client.Send(buffer);
  }
}

staticvoid Main(string[] args)
{
  EndPoint endPoint = new IPEndPoint(IPAddress.Loopback, 8320);

  using (Socket listener = new Socket(endPoint.AddressFamily,
    SocketType.Stream, ProtocolType.Tcp))
  using (Socket client = new Socket(endPoint.AddressFamily,
    SocketType.Stream, ProtocolType.Tcp))
  {
    // Сокет будет слушать порт 8320 на локальном адресе
    listener.Bind(endPoint);

    // Максимальный размер очереди подключений. // Нам для теста достаточно одного.
    listener.Listen(1);

    // Запускаем поток, который ждет подключения клиента.
    listener.BeginAccept(new AsyncCallback(OnBeginAccept), listener);

    // Подсоединяемся клиентом.
    client.Connect(endPoint);

    Console.Write("Введите сообщение: ");

    string request = Console.ReadLine();

    // Отсылаем данные на сервер.int count = client.Send(Encoding.UTF8.GetBytes(request));

    byte[] buffer = newbyte[_bufferSize];

    // Получаем данные с сервера.
    client.Receive(buffer);

    string response = Encoding.UTF8.GetString(buffer);
    int index = response.IndexOf('\0');
    Console.WriteLine(string.Format("Ответ сервера: {0}", 
      response.Remove(index)));
  }
}

Протокол TCP

В .NET есть и более высокоуровневые надстройки над сокетами. Классы TcpClient и TcpListener предоставляют функциональность, осуществляющую коммуникации не на уровне сокетов, а на уровне потока ввода/вывода. Для этого используется класс NetworkStream. Данный класс является наследником System.IO.Stream, но переопределенные им методы чтения и записи не записывают данные ни в какие внутренние хранилища (файлы, массивы байт), а передают прямо в сокет на сервер.

Для демонстрации работы TCP-классов я решил написать самопальный OORPC (Object-Oriented Remote Procedure Call). В двух словах скажу, что это такое, и зачем нужно. Если еще раз посмотреть на предыдущий пример и оценить, какая функциональность при коммуникации должна быть заложена в распределенном приложении, можно отчетливо увидеть, что сокеты годятся лишь для малых проектов. Писать сложные коммуникативные блоки на них очень сложно и неудобно. Именно для этого я и написал механизм под названием “Дальнозов”®.

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

В листинге 2 представлен код тестового серверного приложения. Класс Launcher помечается атрибутом ServiceAttribute, сигнализирующим о том, что его объект может быть доступен из другого домена. В конструктор ServiceAttribute передается URI класса.

Листинг 2. Код сервера, использующий технологию “Дальнозов”.

[Service("RemObj")]
publicclass Launcher: IRemoteObject
{
  publicstaticvoid Main()
  {
    RemotingServices.RegisterChannel(
      new System.Net.IPEndPoint(System.Net.IPAddress.Loopback, 8320));
    RemotingServices.Register(typeof(Launcher));
    
    Console.WriteLine("Сервис запущен");
    Console.ReadLine();
  }

  publicstring SomeMethod(string message)
  {
    returnstring.Format("Hello, {0}", message);
  }
}

А вот код клиента.

Листинг 3. Код клиента, использующий технологию “Дальнозов”.

ClientChannel channel = new ClientChannel(new Uri("tcp://localhost:8320/RemObj"));
IRemoteObject obj = RemotingServices.GetRemoteObject<IRemoteObject>(channel);

Console.Write("Введите сообщение: ");
string message = Console.ReadLine();

string response = obj.SomeMethod(message);

Console.WriteLine("Ответ сервера: {0}", response);

Как видите, все прозрачно и легко. Все самое интересное, конечно же, скрыто внутри классов, в частности, в классе RemotingServices, представленном в листинге 4.

Листинг 4. Вспомогательный класс, используемый серверной и клиентской сторонами для инициализации инфраструктуры технологии “Дальнозов”.

        public
        class RemotingServices
{
  internalstatic Hashtable Proxies = 
    Hashtable.Synchronized(new Hashtable());

  internalstatic ArrayList ListenChannels =
    ArrayList.Synchronized(new ArrayList());

  /// <summary>/// Регистрируем серверный слушающий канал./// </summary>publicstaticvoid RegisterChannel(IPEndPoint endPoint)
  {
    ListenChannels.Add(new ListenChannel(endPoint));
  }

  /// <summary>/// Зарегистрировать серверный тип./// </summary>publicstaticvoid Register(Type serviceType)
  {
    // Данное приведение безопасно, т.к. в случае, если тип не помечен // конкретным атрибутом, будет возвращен пустой массив, а не null.
    ServiceAttribute[] serviceAttrs = 
      (ServiceAttribute[])serviceType.GetCustomAttributes(
      typeof(ServiceAttribute), false)

    if (serviceAttrs.Length == 1)
      Proxies.Add(serviceAttrs[0].Uri, 
        new RealProxy(Activator.CreateInstance(serviceType)));
    elsethrownew ArgumentException("Тип не помечен ServiceMethodAttribute.");
  }

  /// <summary>/// Подключиться к удаленному объекту./// </summary>publicstatic T GetRemoteObject<T>(ClientChannel channel)
  {
    // Создаем тип-заглушку и инициализируем его объект, // передавая в него uri сервера.return  (T)
      Activator.CreateInstance(TransparentProxyGenerator.Generate(typeof(T)),
        BindingFlags.NonPublic | BindingFlags.Instance, 
        null, newobject[] { channel }, null);
  }
}

Для удобности понимания процесса передачи данных с клиента на сервер приведу UML-диаграмму последовательности вызовов моих классов, представленную на рисунке 1.

Рисунок 1. Процесс доставки клиентского вызова на сервер.

На самом деле все просто. Класс TransparentProxy, дублирующий функциональность зарегистрированного серверного типа (на рисунке помечен как ServerObject), в теле своих методов создает объект Message, передавая в него uri объекта, название вызываемого метода и значения входящих параметров. После этого TransparentProxy сериализует полученный объект Message с помощью BinaryFormatter и отправляет данные на сервер. На сервере экземпляры TcpListener (которые создаются при вызове метода RemotingServices.RegisterChannel) принимают запрос и десериализуют запрос. Полученный объект Message передается в метод соответствующего экземпляра RealProxy, где происходит вызов метода серверного объекта через Reflection. После исполнения серверного кода, возвращаемые значения (return, out, ref) упаковываются в Message, сериализуются обратно в массив байтов и отправляются клиенту. Последний десериализует ответ и возвращает измененные значения параметров клиентскому коду.

Но есть одна проблема. Дело в том, что на клиенте должен всегда присутствовать тип, которые декларирует в точности все методы серверного объекта. В теле этих методов будет происходить сериализация параметров вызываемого метода с помощью binary-форматтера и передача информации через сокет. Но тогда получается, что как только серверный тип изменится (или мы захотим работать с другим серверным объектом), придется заново писать тип-заглушку. Выход есть. Можно создавать этот тип “на лету” c помощью кодогенерации из пространства имен System.Reflection.Emit. При этом никакого кода каждый раз писать не нужно. Дешево и эффективно. Именно так я и сделал. С помощью Reflection я вытаскиваю все методы типа, для которого мне нужно будет создать заглушку. Затем создаю тип заглушки, наследуя его от реального. В заглушке реализую все те методы, которые есть у базового типа. В каждом методе происходит процесс сериализации, отсылки по сокету, принятия ответа и десериализации.

Безопасность

Безопасность - один из наиболее важных моментов в построении распределенного приложения. Рассказать об использовании технологий коммуникации в .NET, но не упомянуть о стандартном решении безопасности в этих технологиях было бы неправильно. Именно поэтому я решил написать о стандартной реализации безопасности, предоставляемой .NET для технологий удаленного взаимодействия.

Что ж, вступление пройдено, поэтому перейдем к теории и реализации.

Для реализации безопасного соединения через протокол TCP (да и вообще через любой транспортный протокол) в .NET существует класс AuthenticatedStream. Это абстрактный базовый класс для всех потоков данных (Stream), для которых может быть применено то или иное решение безопасности. Так, например, в .Net стандартно существует два его наследника, NegotiateStream и SslStream.

Класс NegotiateStream позволяет аутентифицировать клиента через такие протоколы как NTLM и Kerberos. Тип аутентификации выбирается автоматически. Если текущая версия ОС клиента Win9х – используется NTLM, иначе – в зависимости от типа протокола аутентификации, который поддерживает сервер. Чаще всего используется Kerberos (в Windows 2003 этот протокол является основным). Если же сеть не объединена в домен, всегда используется NTLM. NTLM также используется, если на сервере используется NT4 или более ранняя версия.

В начале немножко теории о том, как работают протоколы NTLM и Kerberos.

Рисунок 2. Процесс аутентификации по протоколу NTLM.

На рисунке 2 показано, как работает процесс аутентификации по протоколу NTLM (Microsoft Windows NT LAN Manager). В начале клиент посылает свой логин и имя домена на сервер. Тот перенаправляет его контроллеру домена. Получив запрос, контроллер формирует случайным образом пакет, challenge, и шифрует его клиентским паролем. Challenge посылается клиенту. Клиент дешифрует challenge, создает ответ и шифрует его с помощью challenge. Зашифрованный ответ отсылается на сервер, который перенаправляет его на контроллер домена. Контроллер дешифрует ответ и проверяет его. Если все нормально, контроллер уведомляет сервер, что клиент аутентифицирован.

Рисунок 3. Процесс аутентификации по протоколу Kerberos.

Существует и более надежный протокол аутентификации, Kerberos. На рисунке 3 представлен его алгоритм. Клиент посылает запрос о том, что хочет получить ticket-granting ticket (TGT), билет, использующий во время сеанса работы с Центром Распределения Ключей (ЦРК). ЦРК создает TGT, а также сессионный ключ (СК), зашифрованный клиентским паролем. СК будут шифроваться все последующие пакеты, отправляющиеся на ЦРК. Клиент дешифрует СК, создает authenticator (имя клиента + отметка текущего времени) и шифрует его с помощью СК. После этого клиент отправляет на ЦРК запрос, содержащий TGT, authenticator и имя сервера, с которым будет работать клиент. ЦРК дешифрует TGT и authenticator, и сравнивает отметки времени (это нужно для того, чтобы ключ не подменили в процессе аутентификации). Максимальная разница в отметке времени не должна превышать пяти минут. После этого ЦРК создает билет, зашифрованным секретным паролем сервера, с которым будет работать клиент, и создается серверный сессионный ключ (ССК), с помощью которого будут шифроваться все пакеты, отправляемые на сервер. ССК шифруется с помощью СК. После этого клиент дешифрует ССК, создает authenticator, шифрует его с помощью ССК и отправляет его вместе с билетом на сервер. Сервер дешифрует билет, получает ССК, дешифрует authenticator и получает Identity клиента. Если требуется взаимная аутентификация (mutual authentication, аутентификация, при которой клиент удостоверяется, что его аутентифицирован конкретный сервер), сервер отсылает authenticator клиенту.

Преимущества Kerberos перед NTLM состоят в следующем:

• Протокол стандартизован, поэтому его можно использовать при кроссплатформенном общении (в отличие от NTLM, который работает только на ОС линейки Windows NT и Windows CE).
• Поддержка билетов дает возможность не проходить полный цикл аутентификации. Существенно снижается сетевой трафик и повышается производительность.
• Поддержка делегирования полномочий (что это такое, мы рассмотрим ниже).
• Взаимная аутентификация.

Существует еще и протокол Negotiate. Он служит для того, чтобы выбрать наиболее подходящий для общения протокол сетевой безопасности (NTLM или Kerberos).

Вернемся к классу NegotiateStream. На сервере вызывается метод NegotiateStream.ServerAuthenticate. На клиенте нужно вызвать метод NegotiateStream.ClientAuthenticate, через который можно задать уровень имперсонации. Для используется перечислитель ImpersonationLevel (System.Net). Ниже в таблице 1 представлено описание его полей.

Что ж, продолжим улучшать "Дальнозов" и добавим к нему механизм аутентификации. Вот как теперь выглядит код клиента и сервера.

Листинг 5. Код клиента, устанавливающий уровень олицетворения в Delegation.

Uri uri = new Uri("tcp://localhost:8320/RemObj");

NetworkCredential сredential = new NetworkCredential("mika", "password");
ImpersonationLevel impLevel = ImpersonationLevel.Impersonation;
string spn = "MikaSuperPrincipal";
SecurityLevel secLvl = SecurityLevel.EncryptAndSign;

ClientChannel channel = new ClientChannel(uri, impLevel, сredential, 
  spn, secLvl);

IRemoteObject obj = RemotingServices.GetRemoteObject<IRemoteObject>(channel);
Console.WriteLine("Ответ сервера:{0}", obj.SomeMethod().ToShortDateString());

Листинг 6. Код сервера, выводящий в консоль название учетной записи клиентского приложения.

          public
          static
          void Main()
{
  RemotingServices.RegisterChannel(new IPEndPoint(IPAddress.Loopback, 8320),
    ImpersonationLevel.Impersonation, SecurityLevel.EncryptAndSign);
  RemotingServices.Register(typeof(Launcher));
  
  Console.WriteLine("Сервис запущен.");
  Console.ReadLine();
}

public DateTime SomeMethod()
{
  Console.WriteLine(Thread.CurrentPrincipal.Identity.Name);
  return DateTime.Now;
}

Второй наследник класса AuthenticatedStream SslStream предназначен для работы с шифрованными данными по сети. Аналогично классу CryptoStream, работающему с криптопровайдерами из пространства имен System.Security.Cryptography, SslStream работает с классами сертификатов стандарта X.509v3 (System.Security.Cryptography.X509Certificates). SslStream поддерживает такие протоколы безопасности, как SSL версии 2, SSL версии 3, TLS, PCT. Но прежде чем начать работу с этим классом, нужно получить сертификат. Конечно же, для теста я не буду покупать сертификат в центре сертификации. Я его сгенерирую с помощью утилиты makecert, которая поставляется вместе с .NET. Вот код bat-файла, генерирующий сертификат сервера в этом тесте.

Makecert –sr localmachine –ss My –n “CN=mika” –r mika.cer -sk mika.pvk

Сертификат сервера должен содержаться в хранилище My, ассоциированном с локальной машиной, и содержать имя “CN={targetHost}”, где значение targetHost передается в конструктор класса SslStream.ClientAuthenticate.

Давайте добавим и это нововведение в нашу технологию "Дальнозов". Вот как теперь выглядит код установления безопасного соединения.

Листинг 7. Код клиента, устанавливающий безопасное соединение на основе сертификатов.

Uri uri = new Uri("tcp://localhost:8320/RemObj");
NetworkCredential сredential = new NetworkCredential("mika", "password");
ClientChannel channel = new ClientChannel(uri, 
  ImpersonationLevel.Impersonation, сredential, "MikaSuperPrincipal",
  SecurityProtocolType.Tls, new X509Certificate[]{});
IRemoteObject obj = RemotingServices.GetRemoteObject<IRemoteObject>(channel);

Console.WriteLine("Ответ сервера: {0}",
  obj.SomeMethod().ToShortDateString());

Листинг 8. Код сервера, устанавливающий безопасное соединение на основе сертификатов.

X509Store myStore = new X509Store(StoreName.My, StoreLocation.LocalMachine);
myStore.Open(OpenFlags.ReadOnly);

X509Certificate certificate = myStore.Certificates[0];

IPEndPoint ednPnt = new IPEndPoint(IPAddress.Loopback, 8320);
ImpersonationLevel impLvl = ImpersonationLevel.Impersonation;
SecurityProtocolType protocol = SecurityProtocolType.Tls;
RemotingServices.RegisterChannel(ednPnt, impLvl, certificate, false,
  protocol);
RemotingServices.Register(typeof(Launcher));

Console.WriteLine("Сервис запущен.");
Console.ReadLine();

Протокол UDP

В .NET есть надстройка над сокетом, общающимся через UDP. Это класс UdpClient. Но пусть слово “Client” не вводит вас в заблуждение. UdpListener в .NET нет. UdpClient по сути является одновременно и клиентом, и сервером. Соответственно, его методы Receive и Send нужны именно для двунаправленного общения.

Вы хоть раз хотели создать свой чат? Я – да. Тогда я даже не приступил к стадии проектирования, оставив задумку. Но теперь настало время исправить ошибки прошлого. Для демонстрации UDP я написал программу, которая может функционировать в двух режимах: в локальной сети и в Интернет. В первом случае используется широковещательная рассылка (broadcast), во втором – групповая (multicast).

Если вы не знакомы с такими понятиями как broadcast и multicast, советую прочитать нижеследующее. Broadcast- и multicast-рассылки созданы для того, чтобы за один вызов метода Send отослать данные сразу нескольким пользователям. Отличие их состоит в следующем.

Для multicast в Интернете существуют специальные UDP-сервисы (их IP-адреса: 224.0.0.0 - 239.255.255.255, причем диапазон 224.0.0.0 – 224.0.0.255 зарезервирован для использования их маршрутизаторами, так что их использовать не рекомендуется), к которым пользовательские приложения посылают уведомления о включении и исключении их из группы рассылок сообщений (Socket.JoinMulticastGroup и Socket.DropMulticastGroup). Как только будет получено такое сообщение, сервер записывает или вычеркивает IP-адрес клиентской машины в своей виртуальной таблице рассылки сообщений. Ключом в данной таблице, как несложно догадаться, является порт, на который было послано сообщение о подписке. Теперь любое UDP-сообщение, посланное на конкретный порт, будет автоматически переслано всем этим подписчикам.

У одного из перегруженных методов Socket.JoinMulticastGroup есть такой параметр, как TTL (time-to-live). Этот параметр означает максимальное количество маршрутизаторов, через которое может пройти UDP-пакет. Например, если между UDP-сервисом и клиентским приложением стоят три маршрутизатора, а значение TTL равно двум, то приложение никогда не получит извещение от этого UDP-сервиса.

Стоит упомянуть, что для успешной доставки сообщения от UDP-сервиса к конкретному приложению все маршрутизаторы должны поддерживать протокол IGMP. Вам, скорее всего, не стоит об этом заботиться, так как вряд ли ваш провайдер использует маршрутизатор, не поддерживающий этого протокола. Но вот если у вас реализована собственная прокси-программа, то об этом стоит позаботиться.

Принцип broadcast-рассылки несколько отличается. Для такой рассылки не нужно никаких специальных серверов, так как источниками служат все маршрутизаторы, встречающиеся на пути сообщения, посланного от одной машины к другой. Дело в том, что при broadcast-рассылке задается не конкретный IP-адрес конечной машины, а диапазон, в который он входит. Например, вы находитесь в локальной сети, и ваш IP-адрес 192.168.100.N. Вы хотите послать сообщение на машины с IP-адресами 192.168.100.M и 192.168.100.L. Если вы будете посылать это сообщение через broadcast, то вам нужно указать адрес 192.168.100.255. Теперь ваше сообщение будет отослано всем машинам в данной подсети. При этом машинам, не участвующим в рассылке, также придется обрабатывать пакет.

Проанализировав все выше написанное, можно прийти к следующему выводу. Посылать через Интернет broadcast-сообщения бессмысленно, а вот через multicast – очень удобно. И, наоборот, в локальной сети, когда почти все машины участвуют в коммуникации, multicast был бы не очень удобен (если, конечно, вы не установите себе на какой-нибудь компьютер UDP-сервис multicast-рассылки), чего нельзя сказать про broadcast, который подошел бы в данной ситуации как нельзя лучше.

Однако вернемся к нашей чат-программе. В листинге 9 представлены классы для высокоуровневого взаимодействия по протоколу UDP. Пример их использования представлен в листинге 10.

Листинг 9. Классы для осуществления взаимодействия по протоколу UDP.

        public
        class ChatUdpListener: InteractiveServer
{
  private UdpClient _udpClient;

  public ChatUdpListener(int port) : this(null, port)
  {
  }

  public ChatUdpListener(IPAddress multicastAddress, int port)
  {
    _udpClient = new UdpClient(port);
    if (multicastAddress != null)
    {
      _multicastAddress = multicastAddress;

      // Подписываемся на рассылку.
      _udpClient.JoinMulticastGroup(_multicastAddress);
    }

    base.Start();
  }

  private IPAddress _multicastAddress;

  public IPAddress MulticastAddress
  {
    get { return _multicastAddress; }
  }

  privatevoid OnBeginReceiveFrom(IAsyncResult ar)
  {
    ReceiveState state = (ReceiveState)ar.AsyncState;
    EndPoint endPoint = new IPEndPoint(IPAddress.Any, 0);

    _udpClient.Client.EndReceiveFrom(ar, ref endPoint);

    string requestMessage = Encoding.UTF8.GetString(state.Buffer);
    requestMessage = requestMessage.Replace("\0", "");
    base.RaiseEvent(new NewMessage(endPoint, requestMessage));
    state.SetEvent();
  }

  protectedoverridevoid OnProcessRequest()
  {
    EndPoint endPoint  = new IPEndPoint(IPAddress.Any, 0);
    AutoResetEvent evt = new AutoResetEvent(false);
    ReceiveState state = new ReceiveState(evt);

    _udpClient.Client.BeginReceiveFrom(state.Buffer, 0, 
      ReceiveState.BufferSize, SocketFlags.None, ref endPoint, 
      OnBeginReceiveFrom, state);
    evt.WaitOne();
  }

  protectedoverridevoid Dispose(bool disposing)
  {
    // Если сценарий UDP-коммуникации как multicast, то отписываемся// от рассылки.if (_multicastAddress != null)
      _udpClient.DropMulticastGroup(_multicastAddress);

    _udpClient.Close();
    base.Dispose();
  }
}

publicclass ChatUdpClient: IDisposable
{
  private UdpClient _client = new UdpClient();
  private IPEndPoint _remoteEndPoint;

  /// <summary>/// Данный конструктор служит для инициализации объекта UdpClient,/// работающего через broadcasting./// </summary>public ChatUdpClient(int port)
  {
    // Процесс конвертации адреса прокси в broadcast-адрес.// Например, 192.168.100.1 --> 192.168.100.255
    Uri proxyAddress = WebProxy.GetDefaultProxy().Address;

    // Если компьютер не подключен к локальной сети, // то используем адрес "127.0.0.1"byte[] address = IPAddress.Parse((proxyAddress != null) ?
      proxyAddress.Host : "127.0.0.1").GetAddressBytes();

    // Если IPv4 форматif (address.Length == 4)
    {
      address[3] = 255;
      byte[] buffer = newbyte[8];
      address.CopyTo(buffer, 0);
      address = buffer;
    }
    elseif (address.Length == 8)
    {
      address[7] = 255;
    }

    // К сожалению, конструктор IPAddress ожидает массив байт,// олицетворяющий IPv6.
    InitRemoteEndPoint(new IPAddress(BitConverter.ToInt64(address, 0)), port);
  }

  /// <summary>/// Данный конструктор служит для инициализации объекта UdpClient,/// работающего через multicasting./// </summary>public ChatUdpClient(IPAddress address, int port)
  {
    InitRemoteEndPoint(address, port);
  }

  privatevoid InitRemoteEndPoint(IPAddress address, int port)
  {
    _remoteEndPoint = new IPEndPoint(address, port);
  }

  publicvoid SendMessage(string message)
  {
    byte[] bytes = Encoding.UTF8.GetBytes(message);
    _client.Send(bytes, bytes.Length, _remoteEndPoint);
  }

  publicvoid Dispose()
  {
    _client.Close();
  }
}

Листинг 10. Кусок кода чат-программы, отвечающий за обработку входящей и исходящей информации.

        private ChatUdpListener _listener;
private ChatUdpClient _client;

public MainForm()
{
  if (isLocalNetwork == true)
  {
    _listener = new ChatUdpListener(address, port);
    _client = new ChatUdpClient(address, port);
  }
  else
  {
    _listener = new ChatUdpListener(address);
    _client = new ChatUdpClient(port);
  }
  
  _listener.NewMessage += new EventHandler(_listener_NewMessage);
}

/// <summary>/// Обработчик события Button.Click для кнопки "Send"./// </summary>privatevoid send_Click(object sender, System.EventArgs e)
{
  // Получаем сообщение из поля sendingData.string requestMessage = sendingData.Text;
  // Посылаем сообщение.
  _client.SendMessage(string.Format("От {0} : {1}", 
    CallContext.GetData("userName"), requestMessage));
sendingData.Text = null;
}

privatevoid OnAddNewMessage(string message)
{
  receivedData.Text = DateTime.Now.ToShortTimeString() 
    + " " + message + "\n" + receivedData.Text;
  sendingData.Focus();
}

/// <summary>/// Обработчик события UdpListener.NewMessage./// </summary>privatevoid _listener_NewMessage(object sender, EventArgs e)
{
  receivedData.Invoke(new AddNewMessage(OnAddNewMessage), 
    newobject[] { ((NewMessage)e).Message });
}

Безопасность

В .NET нет стандартных решений для построения безопасного соединения на основе протокола UDP. Да это и не удивительно, так как этот низкоуровневый протокол был разработан для быстрой доставки данных без подтверждения.

Протокол HTTP

Связка классов HttpWebRequest и HttpWebResponce, наследников классов WebRequest и WebResponce, умеет посылать запросы Web-серверам по протоколу HTTP и получать ответы. Их серверный собрат, который должен появиться в .NET версии 2.0, HttpListener, полностью реализует функциональность Web-сервера (кстати, когда я начал писать данную статью, то этот класса назывался HttpWebListener ;o) ).

Начать работу с HttpListener довольно просто. Вначале нужно создать объект этого класса. После этого необходимо зарегистрировать http-префикс (HttpListener.Prefixes), с которого будут начинаться все запросы, адресованные нашему приложению. Затем нужно вызвать метод HttpListener.Start, чтобы активизировать работу сервера. И, для того, чтобы получить запрос необходимо вызвать метод HttpListener.GetContext. Как только придет запрос, этот метод вернет экземпляр класса HttpListenerContext, в котором будет содержаться вся нужная информация о запросе.

Для примера я реализовал простенький Web-сервер, который хостит ASP.NET (System.Web.Hosting) и обрабатывает GET-запросы к ASPX-ресурсам.

Листинг 11. Классы, отвечающие за реализацию функциональности Web-сервера.

        public
        class AspNetHost : BaseHost
{
  publicoverridevoid ProcessRequest(string verb, Uri requestUri, 
    TextWriter responseStream)
  {
    // Создаем класс для обработки ASP.NET-запроса.
    HttpWorkerRequest workerRequest;

    // На данные момент поддерживается только запрос типа POST.if (verb == "GET")
      workerRequest = 
      new SimpleWorkerRequest(requestUri.AbsolutePath.Replace("/", ""),
      requestUri.Query, responseStream);
    elsethrownew NotSupportedException();

    // Запускаем обработку запроса.
    HttpRuntime.ProcessRequest(workerRequest);
  }
}

publicsealedclass WebServer : RSDN.Articles.Framework.Net.BaseServer
{
  private Hashtable _hosts = new Hashtable();
  private HttpListener _listener = new HttpListener();
  privatebool _disposed = false;
  public WebServer()
  {
    conststring aspxExt = ".aspx";
    _hosts[aspxExt] = BaseHost.Create(aspxExt);

    _listener.Start();
    _listener.Prefixes.Add("http://localhost:8320/");
    _listener.AuthenticationScheme = AuthenticationSchemes.Basic;

    base.Start();
  }

  protectedoverridevoid OnProcessRequest()
  {
    HttpListenerContext listenerCtxt = _listener.GetContext();

    try
    {
      string extension = 
        Path.GetExtension(listenerCtxt.Request.Url.AbsoluteUri);

      BaseHost host = _hosts[extension] as BaseHost;
      if (host != null)
      {
        using (MemoryStream output = new MemoryStream())
        {
          StreamWriter writer = new StreamWriter(output, Encoding.UTF8);
          writer.AutoFlush = true;

          host.ProcessRequest(listenerCtxt.Request.HttpMethod, 
            listenerCtxt.Request.Url, writer);

          listenerCtxt.Response.ContentLength = output.Length;
          output.Position = 0;
          using (Stream responseStream = listenerCtxt.Response.OutputStream)
          {
            responseStream.Write(output.ToArray(), 0, 
            (int)listenerCtxt.Response.ContentLength);
          }
        }
      }
      else
        listenerCtxt.Response.StatusCode = (int)HttpStatusCode.NotImplemented;
    }
    catch (Exception ex)
    {
      listenerCtxt.Response.StatusCode = 
        (int)HttpStatusCode.InternalServerError;
    }
    finally
    {
      listenerCtxt.Response.Close();
      listenerCtxt.Request.Close();
    }
  }

  protectedoverridevoid Dispose(bool disposing)
  {
    if (_disposed != false)
    {
      _disposed = true;
      _listener.Stop();
    }

    base.Dispose(disposing);
  }
}

Листинг 12. Инициализация хостинга для Web-сервера.

        using (BaseServer server = new WebServer())
{
  Console.WriteLine("Веб сервер запущен.");
  Console.ReadLine();
}

Как показано на рисунке 4, сервер, получая запрос от клиента (объект класса ListenerWebRequest), по расширению вытаскивает нужный ему хост-обработчик (в тестовой программе поддерживается лишь расширение запроса “.aspx”). После этого в хост-обработчик передаются данные запроса и выходной поток, в который будет записываться ответ. После обработки запроса заполняются соответствующие выходные HTTP-заголовки, и ответ отсылается клиенту через ListenerWebResponse.

Рисунок 4. Процесс обработки запроса Web-сервером.

А вот код клиента. Клиент посылает запросы через HttpWebRequest и получает ответ в виде HTML-текста, который выводит ActiveX-control DHTML Editor.

Листинг 13. Код клиентского приложения, который получает ответ от Web-сервера и отображает его.

        // Формируем запрос, отправляем его на сервер и получаем ответ.
        using (WebResponse response = 
  WebRequest.Create(new Uri(url.Text)).GetResponse())
{
  // HTML код "засовываем" в Browser control для отображения ответа.
  axDHTMLEdit1.DocumentHTML = new StreamReader(
    response.GetResponseStream()).ReadToEnd();
}

В .NET есть и другие реализации наследников классов WebRequest и WebResponce. Например, классы, отвечающие за взаимодействие по протоколу FTP (FtpWebRequest и FtpWebResponse), или классы взаимодействия с протоколом FILE (FileWebRequest и FileWebResponse). Именно такая функциональность называется “Расширяемыми Протоколами” (“Pluggable Protocols”). Она позволяет придумать свой собственный протокол и реализовать для него MyProtocolWebRequest и MyProtocolWebResponse. Главное – не забыть их зарегистрировать, и внутренняя инфраструктура из пространства имен System.Net тоже сможет их использовать. Это можно сделать через статический метод WebRequest.RegisterPrefix или через файл конфигурации (секция <webRequestModules>). Для этого нужно создать класс, реализующий интерфейс IWebRequestCreate, и зарегистрировать его с нужным префиксом (“HTTP”, “FTP”, “MyProtocol” и т.д.). Теперь можно использовать, например, класс WebClient, для работы по этому протоколу. Умеет он, конечно, немного, но сможет, например, загрузить статическую картинку с Web-сервера, или облегчить проведение операций загрузки и скачивания файлов. WebClient инкапсулирует манипуляции с WebRequest и WebResponce. Передав в объект класса WebClient адрес, содержащий название нашего протокола “MyProtocol”, он автоматически создаст для него объекты наших классов MyProtocolWebRequest и MyProtocolWebResponse. Единственное, что несколько огорчает в “ Расширяемых Протоколах” – это отсутствие аналогов HttpListener для протоколов FTP и FILE.

При работе с HTTP-протоколом вы наверняка столкнетесь с такими понятиями, как ServicePointManager и его управляемая сущность ServicePoint. Первое мы пока опустим, так как с ним связана функциональность более широкого применения, а вот второе сейчас разберем.

ServicePoint – это физическое олицетворение той точки в сети, с которой предполагается работать через классы HttpWebRequest/HttpWebResponse. Оно содержит информацию о конкретной "Web-точке", например, о том, какие клиентские сертификаты будут использоваться при передаче шифрованных сообщений, максимальном количестве подключений (например, через сокеты) или адресе конечной точки, с которым будет ассоциирован запрос. Именно по этому адресу (System.Uri) будет идентифицироваться объект ServicePoint. Вернее, не по самому адресу, а по его хосту (System.Uri.Host). То есть, для путей вида http://rsdn.ru и http://rsdn.ru/Forum/MainList.aspx объекты ServicePoint будут одинаковыми.

Создать объект ServicePoint можно двумя путями. Первый – через метод ServicePointManager.FindServicePoint. Данный метод ищет в своей внутренней таблице объект ServicePoint, и, если не находит последнего, создает новый экземпляр. Второй – получить его через свойство HttpWebRequest.ServicePoint.

Безопасность

С аутентификацией в Web-протоколах, в общем-то, все тривиально. Идентифицирующие данные записываются через свойство WebRequest.Credentials. Но прежде, чем заняться этим, давайте рассмотрим, как происходит сам процесс аутентификации в сети. В примере я использовал протокол HTTP.

Клиент посылает запрос на удаленный сервер. Если сервер требует аутентификации, то клиенту возвращается ответ с кодом ошибки 401 (Authentication Required) и HTTP-заголовок “WWW-Authenticate”, в котором записан тип аутентификации, поддерживаемый сервером (challenge). После этого, клиент должен снова послать запрос, в котором будет присутствовать HTTP-заголовок “Authorization”. В теле этого заголовка будет записана информация, по которой сможет аутентифицировать клиента прокси-сервер. Например, для Basic-аутентификации там будет записано “Basic {DomainName}\\{UserName}:{Password}”, где связка “{DomainName}\\{UserName}:{Password}” содержится в кодировке Base64. Если сервер снова вернул ошибку 401, значит аутентификационные данные недействительны.

Также в .NET существует такое понятие как предварительная аутентификация. В этом случае соответствующие аутентификационные заголовки посылаются сразу, при первом запросе, минуя вышеописанный сценарий. Для этого нужно выставить значение свойства WebRequest.PreAuthenticate в true и зарегистрировать хоть один модуль аутентификации, который умеет выполнять предаутентификационную обработку запроса. Но тут есть одна тонкость. Дело в том, что аутентификация по Web-протоколам устроена таким образом, что сервер сам выбирает ее тип (Basic, Digest и т.д.). Соответственно, клиент не может отослать аутентификационные данные, если не знает типа аутентификации. Поэтому предварительная аутентификация осуществляется только при работе с адресами, уже успешно аутентифицировавшими клиента ранее.

В .NET появилась функциональность, скрывающая детали аутентификации и отделяющая их от кода обработки запросов. Для этого создается класс, реализующий интерфейс IAuthenticationModule, который будет отвечать за аутентификацию клиентского приложения. Этот класс нужно зарегистрировать, что можно сделать двумя путями: прописать название типа в секцию <authenticationModules> или вызвать метод AuthenticationManager.Register.

В листинге 14 приведен модуль аутентификации, посылающий запрос с аутентификационными данными. Поле Password в них зашифровано по алгоритму реверсирования символов ;o).

Листинг 14. Демонстрация возможностей IAuthenticationModule.

          public
          class AuthenticationModule: IAuthenticationModule
{
  privateconststring _authenticationType = "Reverse";

  publicstring AuthenticationType
  {
    get { return _authenticationType; }
  }

  publicbool CanPreAuthenticate
  {
    get { returnfalse; }
  }

  public Authorization PreAuthenticate(WebRequest request, 
    ICredentials credentials)
  {
    returnnull;
  }

  public Authorization Authenticate(string challenge, WebRequest request, 
    ICredentials credentials)
  {
    NetworkCredential networkCredential = 
      credentials.GetCredential(request.RequestUri, 
      _authenticationType.ToLowerInvariant());

    // Реверсируем пароль.char[] passwordToken = networkCredential.Password.ToCharArray();
    Array.Reverse(passwordToken);

    // Создаем конструкцию вида {DomainName}\\{UserName}:{ReversedPassword}.string token = networkCredential.Domain + "\\"
      + networkCredential.UserName + ":" + new string(passwordToken);
    // Кодируем созданную конструкцию кодировкой Base 64 
    // и дописываем ее после типа аутентификации.
    token = _authenticationType + " " 
      + Convert.ToBase64String(Encoding.Default.GetBytes(token));

    // Создаем объект Authorization, который будет использоваться // впоследствии классом WebRequest.returnnew Authorization(token);
  }
}

Осталось немного – реализовать серверную часть, которая будет понимать, что же мы посылаем в аутентификационном токене ;o).

Стандартно .NET поддерживает такие типы аутентификации, как: Digest (System.Net.DigestClient), NTLM (System.Net.NtlmClient), Kerberos (System.Net.KerberosClient), Negotiate (System.Net.NegotiateClient) и, конечно же, Basic (System.Net.BasicClient). Изобретать тут нечего – все уже давно реализовано.

В листинге 15 представлен код тестового приложения, обязанного пройти этап аутентификации прежде, чем получить Web-страничку.

Листинг 15. Отправка HTTP-запроса с аутентификационными данными.

          // Формируем запрос, отправляем его на сервер и получаем ответ.
WebRequest request = WebRequest.Create(new Uri(url.Text));
// Тут должен быть NT-пользователь, обладающий необходимыми правами.// Иначе аутентификация не пройдет.
request.Credentials = new NetworkCredential("mika", "password");
using (WebResponse response = request.GetResponse())
{
  // HTML-код "засовываем" в Browser control для отображения ответа.
  axDHTMLEdit1.DocumentHTML = 
    new StreamReader(response.GetResponseStream()).ReadToEnd();
}

Теперь, чтобы наш Web-сервер использовал basic-аутентификацию, нужно установить значение свойства HttpListener.AuthenticationScheme в AuthenticationSchemes.Basic. Если же нужна интеллектуальная аутентификация клиента (например, изменение типа аутентификации для определенных IP-адресов), когда информация о пользователе не посылается в http-заголовке “Authorization”, нужно создать обработчик делегата AuthenticationSchemeSelector и передать его в свойство HttpListener.AuthenticationSchemeSelectorDelegate.

Так что же насчет ServicePointManager, уже упоминавшегося выше? Этот класс нужен для управления объектами ServicePoint. Через него можно задать максимальное количество данных сущностей, время существования во внутреннем хранилище, а также протокол безопасности и политику управлениями сертификатами. Именно о сертификатах в HTTP и пойдет сейчас речь.

Как и при использовании TCP, при работе по протоколу HTTP можно использовать сертификаты X.509v3. Чтобы послать зашифрованный запрос на какой-нибудь Web-сервер, нужно создать объект класса HttpWebRequest, передав в него адрес с префиксом “https”. Далее нужно добавить все сертификаты, которые будут использоваться в запросе через свойство HttpWebRequest.ClientCertificates. После этого нужно выставить тот протокол безопасности, через который будет происходить взаимодействие. Это можно сделать через ServicePointManager.SecurityProtocol, по умолчанию установленный в значение SecurityProtocolType.Ssl3. Далее, если нужна собственная аутентификация сервера клиентом и проверка его сертификата, следует реализовать интерфейс ICertificatePolicy и вызвать свойство ServicePointManager.CertificatePolicy.

Код, представленный в листинге 16, показывает инициализацию клиента для работы с нашим Web–сервером в безопасном режиме, используя сертификаты X.509v3.

Листинг 16. Использование протокола https для получения информации.

          // Формируем запрос, отправляем его на сервер и получаем ответ.
WebRequest request = WebRequest.Create(new Uri(url.Text));

// Открываем хранилище "My".
X509Store store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
store.Open(OpenFlags.ReadOnly);

// Для теста вытаскиваем первый же действительный на текущий момент// сертификат.
X509CertificateExCollection certs = 
  store.Certificates.Find(X509FindType.FindByTimeValid, DateTime.Now, true);
// Добавляем его в запрос.
((HttpWebRequest)request).ClientCertificates.Add(certs[0]);

using (WebResponse response = request.GetResponse())
{
  // HTML-код "засовываем" в Browser для отображения ответа.
  axDHTMLEdit1.DocumentHTML = new 
    StreamReader(response.GetResponseStream()).ReadToEnd();
}

Теперь осталось немного – инициализировать сервер и поместить в него серверный сертификат (тот самый, который должен получить клиент для проверки подлинности сервера). Но не все так гладко. Дело в том, что для этого нужно вызвать API-функцию HttpSetServiceConfiguration, чтобы установить сертификат. Но .NET вообще не импортирует эту функцию, а это означает, что HttpListener не работает через безопасное соединение, и об использовании HTTPS можно забыть (это можно проверить, открыв класс HttpApi из пространства имен System.Net каким-нибудь IL-дизассемблером). Надеюсь, к выходу релиз версии .NET 2.0 эта ошибка будет исправлена.

Прокси-серверы

Часто бывают случаи, когда запрос идет не напрямую к Web-серверу, а через прокси-сервер. Чтобы запрос успешно выполнился, его нужно перенаправлять этим прокси-серверам. Для того чтобы задать информацию о них, нужно присвоить свойству WebRequest.Proxy объект класса, реализующего интерфейс IWebProxy. Например, объект класса WebProxy, который предоставляет базовую функциональность по обработке запросов и переадресации их к прокси-серверам. Если у вас в настройках IE уже прописан адрес прокси-сервера, то он будет создаваться автоматически. В этом случае ничего присваивать свойству WebRequest.Proxy не нужно - это осуществляется за счет использования метода WebProxy.GetProxy. Если же информация о прокси-сервере не прописана в настройках IE, ее можно записать через конфигурационный файл. Для этого нужно вписать данные в секцию <proxy>.

Если вы хотите, чтобы по умолчанию создавался не объект класса WebProxy, а ваш собственный наследник IWebProxy, можно опять же воспользоваться конфигурационным файлом. Для этого впишите в секцию <module> свой тип, реализующий IWebProxy. Для автоматической реализации логики обработки bypass-адресов и перенаправления запросов через прокси-сервер, рекомендую наследовать свои классы от класса WebProxy. К счастью, он не объявлен как sealed, что иногда можно увидеть в декларациях очень полезных по своей функциональности классов.

Прокси-серверы также поддерживают аутентификацию. Чтобы пройти этот этап успешно, нужно выполнить точно такие же действия, как и при аутентификации на конечных серверах. Единственное отличие - вписывать идентифицирующие данные нужно в WebRequest.Proxy.Credentials.

Протокол SMTP

Видимо, разработчикам уже так надоел основанный на CDO SmtpMail своими ошибками, а Microsoft – документирование этих багов и способов их обходов, что в .NET 2.0 появился новое пространство имен System.Net.Mail (и производное для него System.Net.Mime). Новый класс SmtpClient реализован, как это модно говорить, на pure .NET (за исключением сокетной части), что позволит находить и устранять ошибки в программе значительно проще.

В листинге 18 представлена простейшая программа, демонстрирующая работу с новыми типами. Сперва создается объект класса SmtpClient. Ему передается имя сервера, которому будет послано сообщение. Затем создается и инициализируется объект класса MailMessage, в котором задается адрес отправителя и получателя, а также присоединяется вложение, содержащее строку. И наконец, вызывается метод SmtpClient.Send, который отправляет письмо.

Листинг 18. Программа, посылающая тестовое письмо по протоколу Smtp.

        class Program
{
  staticvoid Main(string[] args)
  {
    try
    {
      using (SmtpClient client = new SmtpClient("world.net"))
      {
        MailMessage message = new MailMessage();
        message.From = new MailAddress("unmanaged@world.net");
        message.To.Add(new MailAddress("managed@world.net"));
        message.Attachments.Add(new Attachment("Attachment"));
        message.Subject = "Test Mail";
        message.Body = "Hello frоm .NET 2.0";

        client.Send(message);
      }
    }
    catch (SmtpException ex)
    {
      Console.WriteLine(ex);
    }
  }
}

Сетевая статистика

В .NET 2.0 появится класс NetworkInformation (System.Net.NetworkInformation), предоставляющий информацию о стеке протоколов TCP/IP. Так, например, можно узнать число отосланных и принятых UDP-дейтаграмм, или число исходящих IP-пакетов. Это может оказаться полезным, например, при написании административной программы, просмотривающей статистику сервера. Ниже, в листинге 18, представлен JScript.NET-файл, с помощью которого можно получить общую информацию о компьютере и домене, в который он входит.

Листинг 18. JScript-файл, выводящий общую информацию о компьютере

import System;
import System.Net.NetworkInformation;

var netInfo = new NetworkInformation();

Console.WriteLine("Computer name: {0}", netInfo.HostName);
Console.WriteLine("Domain name:   {0}", netInfo.DomainName);
Console.WriteLine("Node type:     {0:f}", netInfo.NodeType);
Console.WriteLine("DHCP scope:    {0}", netInfo.DhcpScopeName);
Console.WriteLine("Connected?     {0}", netInfo.GetIsConnected());
Console.WriteLine("WINS proxy?    {0}", netInfo.IsWinsProxy);

Безопасность на основе доступа к коду

Code Access Security (или сокращенно CAS) – родная технология безопасности .NET. Определяет, к какому участку кода имеет доступ приложение. Но как это может применяться при построении коммуникативной части распределенного приложения, спросите вы. Дело в том, что некоторые проверки можно делать на уровне приложения (например, на клиенте можно пресечь доступ к тому или иному ресурсу, пока вызов не вышел за пределы управляемой песочницы). Чтобы понять это, рассмотрим классы SocketPermission и WebPermission. Первый используется для ограничения доступа на уровне сокета, второй – на уровне протокола HTTP. Следующий код, представленный в листинге 19, демонстрирует возможности ограничения доступа на базе CAS.

Листинг 19. Пример демонстрирует, как запретить приложению соединяться с серверами в подмаске “192.168.100.XXX” через порт 8320 по протоколу UDP, и запретить работать с HTTP-клиентами.

      try
{
  PermissionSet permissionSet = new PermissionSet(
    PermissionState.Unrestricted);
  permissionSet.AddPermission(new WebPermission(NetworkAccess.Accept,
    string.Empty));
  permissionSet.AddPermission(new SocketPermission(NetworkAccess.Connect,
    TransportType.Udp, "192.168.100.*", 8320));

  permissionSet.Deny();

  UdpClient client = new UdpClient(new 
    IPEndPoint(IPAddress.Parse("192.168.100.1"), 8320));
}
catch (Exception ex)
{
  Console.WriteLine(ex);
}

Как видно из примера, оба разрешения (permission) используют перечислитель NetworkAccess. Он нужен для определения тех действия, за которые будет отвечать данное разрешение. Так, например, Accept означает, что разрешение будет отвечать за операцию обработки клиентских сокетов, а Connect – за операцию соединения с удаленным сервером.

SocketPermission с помощью TransportType определяет, какой тип транспортного протокола будет контролироваться. В нашем примере используется член UDP, но можно было выставить и Connectionless. Правда, это могло бы пересекаться с каким-нибудь другим протоколом, не ориентированным на постоянное подключение (например, icmp, igmp, ipx или вашим собственным протоколом, реализованным на базе транспортного уровня модели OSI).

Существуют также разрешения, с помощью которых можно позволить или запретить использование DNS-сервисов. Это можно сделать через класс DnsPermission. Например, в листинге 20 представлен код, демонстрирующий данный подход.

Листинг 20. Код программы, который генерирует исключение при вызове метода GetLocalHostAddress из-за того, что у него отняли права на использование DNS-сервиса.

[DnsPermission(SecurityAction.Demand, Unrestricted = true)]
publicstatic IPAddress GetLocalHostAddress()
{
  return Dns.Resolve("mika").AddressList[0];
}

staticvoid Main(string[] args)
{
  DnsPermission permission = new DnsPermission(PermissionState.Unrestricted);
  permission.Deny();
  Console.WriteLine(GetLocalHostAddress());
}

Если мы снимем атрибут DnsPermissionAttribute метода GetLocalHostAddress, то мы все равно получим исключение SecurityException при выполении метода Dns.Resolve, так как разрешение было уже “снято” до этого в методе Main.

Не реализованные технологии

Существует еще несколько технологий удаленного взаимодействия, например, каналы (pipes). Такая технология очень удобна для межпроцессного общения разных программ. Классический пример: программа анализирует довольно-таки большое количество информации. При этом у нее нет пользовательского интерфейса (например, сервис NT). Чтобы узнать, исправно ли она работает, или изменить уже существующие настройки, к ней подключается административная консоль. Делать взаимодействие на сокетах ради локальной программы несколько расточительно. Именно для этого лучше всего использовать каналы.

Но как бы хороша или плоха не была эта технология, для них не нашлось ниши в .NET. Во Framework нет типов, через которые можно работать с каналами. Поэтому единственный способ использования их – это взаимодействие с неуправляемым кодом (System.Runtime.InteropServices), что не может не огорчать.

Заключение

Вот мы и рассмотрели технологии удаленного взаимодействия пространства имен System.Net. Но на этом мы не остановимся. В .NET есть технологии, которые предоставляют более удобный и простой интерфейс использования для построения распределенных приложений. Это Remoting и Web Services. Но об этом и многом другом речь пойдет в следующей статье, “Технологии построения распределенных приложений в .NET. Часть 2”.

Сообщений 18    Оценка 1180 [+1/-0]         Оценить