Не удается подключиться к службе WCF, размещенной в рабочей роли - PullRequest
1 голос
/ 18 августа 2011

Я создал службу WCF и разместил ее в облаке через рабочую роль. К сожалению, когда я пытаюсь подключиться к службе рабочих ролей, я получаю исключение с сообщением: "Не существует записей DNS для хоста 3a5c0cdffcf04d069dbced5e590bca70.cloudapp.net." 3a5c0cdffcf04d069dbced5e590bca70.cloudapp.net - это адрес рабочей роли, развернутой в промежуточной среде Azure. Для предоставления службы WCF в файле workerrole.cs имеется следующий код:

    public override void Run()
    {
        using (ServiceHost host = new ServiceHost(typeof(MyService)))
        {
            string ip = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["tcppoint"].IPEndpoint.Address.ToString();
            int tcpport = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["tcppoint"].IPEndpoint.Port;
            int mexport = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["mexinput"].IPEndpoint.Port;

            // Add a metadatabehavior for client proxy generation
            // The metadata is exposed via net.tcp
            ServiceMetadataBehavior metadatabehavior = new ServiceMetadataBehavior();
            host.Description.Behaviors.Add(metadatabehavior);
            Binding mexBinding = MetadataExchangeBindings.CreateMexTcpBinding();
            string mexlistenurl = string.Format("net.tcp://{0}:{1}/MyServiceMetaDataEndpoint", ip, mexport);
            string mexendpointurl = string.Format("net.tcp://{0}:{1}/MyServiceMetaDataEndpoint", RoleEnvironment.GetConfigurationSettingValue("Domain"), 8001);
            host.AddServiceEndpoint(typeof(IMetadataExchange), mexBinding, mexendpointurl, new Uri(mexlistenurl));

            // Add the endpoint for MyService
            string listenurl = string.Format("net.tcp://{0}:{1}/MyServiceEndpoint", ip, tcpport);
            string endpointurl = string.Format("net.tcp://{0}:{1}/MyServiceEndpoint", RoleEnvironment.GetConfigurationSettingValue("Domain"), 9001);
            host.AddServiceEndpoint(typeof(IMyService), new NetTcpBinding(SecurityMode.None), endpointurl, new Uri(listenurl));
            host.Open();

            while (true)
            {
                Thread.Sleep(100000);
                Trace.WriteLine("Working", "Information");
            }
        }
    } 

Для tcppoint и mexinput настроены порты 8001 и 9001. Также для домена настроен URL-адрес развертывания рабочей роли: 3a5c0cdffcf04d069dbced5e590bca70.cloudapp.net

В клиентской части (консольное приложение) мы используем следующую конфигурацию в app.config ::

    <bindings>
        <netTcpBinding>
            <binding name="NetTcpBinding_IMyService" closeTimeout="00:01:00"
                openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                transactionFlow="false" transferMode="Buffered" transactionProtocol="OleTransactions"
                hostNameComparisonMode="StrongWildcard" listenBacklog="10"
                maxBufferPoolSize="524288" maxBufferSize="65536" maxConnections="10"
                maxReceivedMessageSize="65536">
                <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                    maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                <reliableSession ordered="true" inactivityTimeout="00:50:00"
                    enabled="false" />
                <security mode="None">
                    <transport clientCredentialType="Windows" protectionLevel="EncryptAndSign" />
                    <message clientCredentialType="Windows" />
                </security>
            </binding>
        </netTcpBinding>

    </bindings>
    <client>
      <endpoint address="httpp:\\3a5c0cdffcf04d069dbced5e590bca70.cloudapp.net:9001/MyServiceEndpoint" binding="netTcpBinding"
         bindingConfiguration="NetTcpBinding_IMyService" contract="ServiceReference1.IMyService"
         name="NetTcpBinding_IMyService" />
    </client>

  <behaviors>
    <serviceBehaviors>
      <behavior name="behave">
        <serviceMetadata httpGetEnabled="false"/>
      </behavior>
    </serviceBehaviors>
  </behaviors>   

</system.serviceModel>
<system.net>
  <defaultProxy useDefaultCredentials="true">
  <proxy autoDetect="False" usesystemdefault="False" bypassonlocal="True" />
</defaultProxy>

Следующий код построен с использованием примера кода, доступного в msdn в качестве фона. Локально работает нормально. К сожалению, когда я развертываю его в облаке, возникает исключение. Более того, когда я использую виртуальный IP-адрес вместо URL-адреса, возникает тайм-аут соединения, за исключением того, что удаленная машина не отвечает.

Ответы [ 2 ]

0 голосов
/ 10 мая 2013
    public void CallWebService(string data)
    {

        try
        {
            string uri = "url"+data;

            HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(uri);

            HttpWebResponse response = (HttpWebResponse)request.GetResponse();

            Stream str = response.GetResponseStream();

            StreamReader sr = new StreamReader(str);

            String IResponse = sr.ReadToEnd();


        }
        catch (Exception ex)
        {
            System.Console.WriteLine("Message: "+ex.Message);
        }

    }

Надеюсь, это поможет вам.

0 голосов
/ 18 августа 2011

Похоже, у вас есть настроенная служба для прослушивания net.tcp (TCP) и ваш клиент, использующий привязки http. Я не ожидал бы, что это будет работать даже на местном уровне. Я предполагаю, что вы фактически открыли порт 9000 в ServiceDefinition. Помните, что это будет конечная точка с балансировкой нагрузки. Вы пытаетесь установить связь с этим экземпляром изнутри развертывания (между ролями) или из-за пределов облака?

Я обнаружил, что намного проще настроить хост и клиента (при взаимодействии внутри роли) с помощью кода. Попробуйте это:

http://dunnry.com/blog/2010/05/28/HostingWCFInWindowsAzure.aspx

Если вы пытаетесь подключиться к сервису от клиента за пределами развертывания, это все равно применимо, но для части построения клиента. Вам нужно будет использовать внешнее DNS-имя и порт, определенные в ServiceDefinition.

Я также видел ошибки DNS, если вы пытаетесь достичь конечной точки слишком рано, прежде чем роль будет готова. Распространение DNS может занять некоторое время, и вы должны стараться не разрешать его до тех пор, пока он не будет готов, чтобы вы не кэшировали поддельную запись DNS. Если вы можете разрешить это DNS-имя по вашему VIP-адресу, это не проблема.

...