We Keep Coding

SignalR app starts, runs on http but not on https: Unexpectedly closed connection

I have a self-hosted SignalR application in a Windows Service built with VS2015 FW 4.6, SignalR 2.3.0. This has been working fine for more than 2 years using ports 6286 (https) and 6287 (http) and "*" for the IP. I wanted to switch these ports to 80 and 443 respectively and apply a wild-card certificate to 443. Since there are web sites using the certificate on IP 192.168.100.7 I added another IP address (192.168.100.3) to my server applied the certificate with:
netsh http add sslcert ipport=192.168.100.3:443 appid={12345678-db90-4b66-8b01-88f7af2e36bf} certhash=xxxxxxxxxxxxxxxxxxxxxxxxx
I can verify the success with:
netsh http show sslcert ipport=192.168.100.3:443
So I start the WebApps with the following:
SignalR = WebApp.Start("http://192.168.100.3:80/");
SignalRSSL = WebApp.Start("https://192.168.100.3:443/");
They seem to start fine, no errors and if I use http://192.168.100.3/signalr/hubs it works fine. However, https://192.168.100.3:443/signalr/hubs gives the "Unexpectedly closed connection" error.
What have I done wrong, is there something else to set for https?

My error... I was using the internal IP's and corresponding external IP's to test this. What I realized is that the wild-card certificate is not tied to an IP, it's tied to a domain! So, I created an A record for the IP with the wild-card's domain and it worked.
However, I now have a different problem in that it's trying to negotiate with the web server's domain and not the signalR domain to send a message!
https://webserverdomain/signalr/negotiate?clientProtocol=1.5....
I don't know where it's picking the web server's name up but it's different enough that it's probably a topic for another post.

Connecting to local nCache

I'm trying to setup my local nCache development. In my ASP.net code, I'm calling the following:
Cache cache = NCache.InitializeCache("local-test");
However, it is throwing an OperationFailedException:
No server is available to process the request for local-test
Any idea why? The documentation says that this error typically relates to firewall issues, but I'm running this thing locally.
Configuration
In %NCHOME%\config\client.ncconf, the cache is identified:
<cache id="local-test" client-cache-id="" client-cache-syncmode="optimistic" default-readthru-provider="" default-writethru-provider="" load-balance="True">
<server name="My IP address"/>
</cache>
...and config.ncconf has the following definition:
<cache-config name="local-test" inproc="False" config-id="0" last-modified="" type="local-cache" auto-start="False">
<log enabled="True" trace-errors="True" trace-notices="False" trace-warnings="False" trace-debug="False"/>
<perf-counters enabled="True"/>
<compression enabled="False" threshold="100kb"/>
<notifications item-remove="False" item-add="False" item-update="False" cache-clear="False"/>
<cleanup interval="15sec"/>
<storage type="heap" cache-size="250mb"/>
<eviction-policy enabled="True" default-priority="normal" policy="lru" eviction-ratio="5%"/>
</cache-config>

I am listing down some the reasons for this exception to be raised.
• This error is sometimes thrown when the Cache you are trying to connect is stopped on the machine
You can verify this by running the 'Get-Caches' cmdlet from PowerShell. If it is not currently running on this machine, you can start the Cache by using the 'Start-Cache' cmdlet from PowerShell.
PowerShell Guide: http://www.alachisoft.com/resources/docs/ncache/powershell-ref/
• When an application tries to connect to the Cache, the IPs where the Cache is hosted are checked through the Client.ncconf file ("C:\Program Files\NCache\config\client.ncconf"). If the IPs that are mentioned are wrong, your call may go to a completely different server where either cache is not running or service is not accessible at all.
You can review that the IP configured against the Cache in the Client.ncconf is the same as what you have currently running on the box. So for example if your IP is '192.16.1.1' then your Cache's client.ncconf tag should look something like this.
<cache id="mycache" client-cache-id="" client-cache-syncmode="optimistic" default-readthru-provider="" default-writethru-provider="" load-balance="False" enable-client-logs="False" log-level="error">
<server name="192.16.1.1"/></cache>
This IP should be the same as the one that is configured in the NCache Service configuration file.
• If the machine has dual IPs and the NCache Service is running on a different IP (than the one where the Cache is hosted or configured to host) then your application may also get this error.
Please make sure that your NCache Service is currently running on the correct IP as well. Please check the value against the following tags in the NCache Service Configuration file (C:\Program Files\NCache\bin\service\Alachisoft.NCache.Service.exe.config)
<add key="NCacheServer.BindToClusterIP" value=" xx.xx.xx.xx "/>
<add key="NCacheServer.BindToClientServerIP" value="xx.xx.xx.xx"/>
Please make sure that this is the same IP as the one configured in the Client.ncconf file.
• This error could also be thrown in such a scenario where there is a firewall enabled on the machine, it could be denying the access to the ports on which the Cache host process is running. .
Please make sure that the Cache Ports are opened in the Firewall, if the firewall is enabled. You can verify the Cache's Port from this file "C:\Program Files\NCache\bin\service\CacheHostPorts.xml". If this still doesn't work, please disable the firewall completely and check.

I had an old version of the NCache libraries installed. When I upgraded the client DLLs, everything started working.

Can't communicate with service using DNS in service fabric

I'm trying to get a stateless service to send a value to another, just to achieve communication between services by using the DNS-service in service fabric. I've tested both applications with postman, and they work fine. I'm following this tutorial where it seems pretty straight forward to do this.
The DNS-service is enabled:
The stateless service has a DNS-name:
The DNS-name is configured in the ApplicationManifest.xml
<Service Name="SocketService"
ServiceDnsName="SocketService.TimeSeriesActorApplication"
ServicePackageActivationMode="ExclusiveProcess">
<StatelessService ServiceTypeName="SocketServiceType"
InstanceCount="[SocketService_InstanceCount]">
<SingletonPartition />
</StatelessService>
</Service>
I then try to send a http get to the service, just like in the tutorial.
using (var client = new HttpClient())
{
client.BaseAddress = new Uri("http://socketservice.timeseriesactorapplication:8712/api/");
var response = await client.GetAsync("values");
}
But I get an exception:
WebException: The remote name could not be resolved: 'socketservice.timeseriesactorapplication'
This happens both when I use port 8080 like the tutorial suggests, and when I use the port I specify in ServiceManifest.xml.
<Endpoints>
<Endpoint Protocol="http" Name="ServiceEndpoint" Type="Input" Port="8712" />
</Endpoints>
What am I missing here?
Update:
Using localhost instead of dns-name also works fine.
Issue on Github: Unable to resolve service DNS name #332

I see you are running service fabric 5.6.210. The recent 5.6.220 release (https://blogs.msdn.microsoft.com/azureservicefabric/2017/06/20/release-of-sdk-2-6-220-and-runtime-5-6-220-refresh-for-windows/) contains some fixes for the DNS service. Note that even though I am running 5.6.220, I have noticed that the DNS name resolution does not always seem to start working straight away after deployment on my local machine (I have to redeploy or wait a few minutes). If you are running locally you can test the name resolution in a terminal window - just ping your service's DNS name.

I fixed it by using ipconfig /flushdns to refresh DNS.
I also found that local IP is the first DNS server in my DNS chain.

'No connection could be made because the target machine actively refused it'

I am working on a 'Smart Device Project' using .Net Framework 3.5. I am trying to connect to some Java SOAP services on a remote server.
In order to do that, I added 'Web References' to my project.
When I try to call my web service I get a WebException 'Unable to connect to the remote server' with the inner exception being 'No connection could be made because the target machine actively refused it'.
I searched quite a lot on the Web and StackOverflow and found a lot of ASP configuration and 'Unavaliable port' answers, but as I have another application using the exact same Service successfully, I can't get why the new one isn't getting through (It did sometimes through my tests so I suppose my client implementation isn't that bad)
I tried to look if there was some connection issue on the port by using some TcpClient:
System.Net.Sockets.TcpClient client = new System.Net.Sockets.TcpClient();
try
{
client.Connect("myServerName", 8087);
MessageBox.Show("Success");
} catch (Exception ex)
{
MessageBox.Show("Failure");
}
finally
{
client.Close();
}
This connection succeed.
Here is a sample on how I call my WebService:
WSServiceExtended srv = new WSServiceExtended();
srv.Proxy = new System.Net.WebProxy();
ServeurWSI wsi = new ServeurWSI();
srv.Url = "http://myServerName:8087/myServerApp/services/myService";
wsr = srv.login(wsi);
The service is called 'Extended' because I overrided the auto-generated one in order to add Cookie managment since I am using the Compact Framework. Following the sample in this thread:
https://social.msdn.microsoft.com/Forums/en-US/34d88228-0b68-4fda-a8cd-58efe6b47958/no-cookies-sessionstate-in-compact-framework?forum=vssmartdevicesvbcs
EDIT:
I made some new tests with the Web references and got it to work.
When I add the Web Reference, I have to put some Url to the Web Service. When I set it with the actual hostname instead of the 'localhost' everything is fine.
But then, since I set it manually to the real address just before the call, it shouldn't matter
srv.Url = "http://myServerName:8087/myServerApp/services/myService";
EDIT2:
I might have forgotten some specifics about my environnement.
The Web Services are exposed on my computer on some Tomcat Server.
The application I am working on is also developped on this computer (That's why I can add Web References by putting 'localhost' in the address)
The application is then deployed on a distant device (Windows CE) that will make calls the Web Services through WIFI (There, localhost wouldn't work then)
I tried calling the Web services from other computers successfully.
I'm beginning to think that there might be some differential between the called Url and the one that is set, otherwise, how would I have a difference in behaviour such as the one described in the first edit?
EDIT3:
Well..Seems like it's not a network issue but a .Net compact framework (usage?) issue...
The Url property of the Web Service implementation is simply ignored and the one in the Reference.cs is used in place.
If someone had some idea on how I could troubleshot this, I would really appreciate it.

That error means that you reached a server and the server said "no way". So you're either hitting the wrong server or the wrong port.
I find the telnet client is useful for testing stuff like this. From the command line, you can do:
telnet [servername] [port]
So something like:
telnet myServerName 8087
If it goes to a blank screen, then it connected successfully. If it does not connect, it'll tell you.
The telnet client is no longer installed by default in Windows 7+, so you'll have to install it. See here for instructions: https://technet.microsoft.com/en-ca/library/cc771275
If the connection does open, you could paste in an actual HTTP request to see what happens. A simple GET would look something like this:
GET /myServerApp/services/myService HTTP/1.1
Host: myServerName:8087

One reason for this error can be that the service binds to only a certain IP address. It could well be that the service only listens on the IP that is assigned to the host name, but not on the localhost IP (127.0.0.1).
For example:
If the host myServerName has the public IP 192.168.0.1, your service can choose to listen on all IPs assigned to the host (sometimes specifying 0.0.0.0), or it can specifically listen on 192.168.0.1 only. In that case you will not be able to connect through 127.0.0.1, because the service simply doesn't listen on that IP.
You can "use" this inverse of this feature to make a service accessible only to local clients, not on the public IP-Address, by listening on 127.0.0.1 only, but not on the public IP. This is sometimes used on Linux for example to make MySQL only accessible on the host itself.

I was starting to forget this post but I finally found the problem that was messing things up and it has nothing to do with programmation.
I was doing the calls while the device was connected to the computer via the 'Windows Mobile Device Center' allowing to access the device from Windows.
While connected, the host provided is ignored and all calls on the specified port are handled by the connected computer.
Disconnecting the device allows to communicate properly...

SignalR client won't connect using OWIN Self Host in Azure Worker Role

I have an Azure Cloud Service with a worker role that starts an OWIN web app on startup, which uses SignalR.
Separately, I have a console project that uses the SignalR client library to connect to this worker role and listen for events.
Everything is working when I run the client and the service locally using the Azure emulators.
When I publish the cloud service and point the console application to it and try to connect, I get the following in the SignalR trace logs:
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
It then proceeds to try again using server sent events and long polling with the same error each time.
I'm using the following endpoint in my Cloud service config:
<Endpoints>
<InputEndpoint name="SignalREndpoint" protocol="http" port="80" localPort="80" />
</Endpoints>
And here is how I create my OWIN web app:
var endpoint = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["SignalREndpoint"];
string webAppUrl = $"{endpoint.Protocol}://{endpoint.IPEndpoint}";
_webApp = WebApp.Start<Startup>(webAppUrl);
Finally, here's how I configure 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,
});
}
}
In the client project I am simply using a HubConnection to connect using the following URL for local testing, http://localhost:80, and the following URL for connecting to the cloud instance, http://myapp.cloudapp.net
I'm not sure what's different between the actual Azure instance and my local emulator that's causing it to not work in the cloud.
Interestingly, if I use the browser to connect to the URL http://myapp.cloudapp.net/signalr/hubs, it works and returns the JS proxy file.

Have you tried using TCP instead of HTTP as a protocol?
I am not a SignalR expert in any way, but I know about it. When we host our server (XSockets.NET) on Azure worker roles we configure the protocol to be TCP (not HTTP).
Have no idea why it would work on localhost though.
Another thing to consider is if the worker role supports websockets? SignalR requires IIS8+ for websocket support and I have no idea if you have access to that in a worker role. There are no options in Azure to turn websockets on/off on a worker role (from what I can see). So my guess is that there is no Microsoft WebSockets in the worker role. By I might be wrong here!
EDIT: Looked at one of my instances and saw that I can change OS and that the default one is 2012 Server. So Microsoft websockets should be available!