2015-11-02 5 views
0

У меня есть служба Azure Cloud с рабочей ролью, которая запускает веб-приложение OWIN при запуске, которое использует SignalR.Клиент SignalR не будет подключаться с использованием собственного хоста OWIN в роли Azure Worker

Отдельно у меня есть консольный проект, который использует клиентскую библиотеку SignalR для подключения к этой рабочей роли и прослушивания событий.

Все работает, когда я запускаю клиент и службу локально с использованием эмуляторов Azure.

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

WS Connecting to: ws://myapp.cloudapp.net/signalr/connect?clientProtocol=1.4&transport=webSockets&connectionData=[{"Name":"MessageBusHub"}]&connectionToken=...

OnError(System.Net.WebSockets.WebSocketException (0x80004005): An internal WebSocket error occurred. Please see the innerException, if present, for more details. ---> System.Net.Sockets.SocketException (0x80004005): An existing connection was forcibly closed by the remote host

Затем он переходит повторять попытку с помощью серверных событий и длительный опрос с одинаковой ошибкой каждый раз.

Я использую следующую конечную точку в моей конфигурации Облачные службы:

<Endpoints> 
    <InputEndpoint name="SignalREndpoint" protocol="http" port="80" localPort="80" /> 
</Endpoints> 

А вот как я создаю мой Owin веб-приложение:

var endpoint = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["SignalREndpoint"]; 
string webAppUrl = $"{endpoint.Protocol}://{endpoint.IPEndpoint}"; 
_webApp = WebApp.Start<Startup>(webAppUrl); 

Наконец, вот как настроить SignalR:

public class Startup 
{ 
    public void Configuration(IAppBuilder app) 
    { 
     app.UseCors(CorsOptions.AllowAll); 
     app.UseServerAuthentication(); 
     GlobalHost.DependencyResolver.UseServiceBus(CloudConfigurationManager.GetSetting("ServiceBusConnectionString"), "SignalRMessageBus"); 
     app.MapSignalR(new HubConfiguration() 
     { 
      EnableDetailedErrors = true, 
     }); 
    } 
} 

В проекте клиента я просто использую HubConnection для подключения, используя followin g URL для локального тестирования, http://localhost:80 и следующий URL-адрес для подключения к облачному экземпляру, http://myapp.cloudapp.net

Я не уверен, что отличается от фактического экземпляра Azure и моего локального эмулятора, который заставляет его не работать в облаке.

Интересно, что если я использую браузер для подключения к URL-адресу http://myapp.cloudapp.net/signalr/hubs, он работает и возвращает прокси-файл JS.

ответ

0

Вы пытались использовать TCP вместо HTTP в качестве протокола?

Я не эксперт SignalR в любом случае, но я знаю об этом. Когда мы размещаем наш сервер (XSockets.NET) на рабочих роли Azure, мы настраиваем протокол как TCP (а не HTTP). Не знаю, почему это работает на localhost.

Еще одна вещь, которую следует учитывать, заключается в том, что роль рабочего поддерживает веб-порты? SignalR требует поддержки IIS8 + для поддержки websocket, и я понятия не имею, есть ли у вас доступ к роли в рабочей роли. В Azure нет параметров, чтобы включить/отключить веб-чаты на рабочей роли (из того, что я вижу). Поэтому я предполагаю, что в рабочей роли нет Microsoft WebSockets. Возможно, я ошибаюсь!

EDIT: Посмотрел на один из моих экземпляров и увидел, что я могу сменить ОС и что по умолчанию это 2012 Server. Итак, веб-узлы Microsoft должны быть доступны!

+0

SignalR пытается вернуться к серверным событиям или длительному опросу, который является просто базовым HTTP-запросом, поэтому он должен работать независимо от того, поддерживаются ли веб-сокеты. При отслеживании клиента он показывает, что он получает ту же самую ошибку при длительном опросе, что и при подключении сетевых сокетов. –