I'm working on a angularjs/electron project, and we're utilizing pouchdb noSQL. I'm currently trying to sync the pouchdb to my couchbase server, but when I do i'm receiving this error
FATAL: Failed to start HTTP server on 127.0.0.1:4985: listen tcp 127.0.0.1:4985: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted. -- rest.(*ServerConfig).Serve() at config.go:705
I've already checked my ports, and there's only one instance of my sync port active. So, you can understand why I'm a bit puzzled. If you can offer any suggestions, I'd be very appreciative.
Figured it out. When installing couchbase sync gateway, it comes in as a service. Make sure the service isn't active, when you run it from console.
Related
I have a device (esp32s2) which is IoT enabled and communicating with AWS server.
The device is connecting to the internet via router. I want to check from the device, if the router is connected to the internet or not. If not connected, I need to disconnect mqtt broker instantly.
I know there is aws_iot_yield happening, but it is taking too much of time to change the client state (~5-10 mins) after disconnection. So, is there is any other way in which I can come to know if the device is connected to the mqtt broker or not using AWS sdk?
I want to avoid using pinging to some address/server as it will increase the usage of resources.
Thanks in advance!
Since the connectivity to the AWS server trough internet depends on the network elements, the only reliable way to know if you are connected to internet is to send a package to a know address and receive the response. Simplest way to do this is to use ICMP (ping) protocol. Usually the most reliable destination to ping is the Google DNS server 8.8.8.8 or 8.8.4.4 which is a cluster service and it's always replying on the ping.
You can control the pause between two pings and how many pings you will send in one session in order to preserve the resources.
Alternative approach is to use a router that can send messages to a monitoring device that the link state was changed (by example SNMP trap). But this is not fully reliable method since the router can not detect all scenarios where the connectivity to your AWS server is lost.
I am developing a .Net Core (3.1) web application hosted with IIS 10. When I am trying to use SignalR on localhost, I am able to connect totally fine and receive messages from the backend, but after I publish it to IIS, I get the error: "Server returned handshake error: Handshake was canceled." In the client logs on Chrome's console, I get the message: "Information: SSE connected to http://myserver.com/MyApplication/output" before I get the error described above (which you would think means that I connected successfully)...
I have seen other posts where people have suggested that I have to enable webSockets on IIS, and I have already checked the my site has this enabled.
I have also seen people suggest to try using the longPolling argument in the withUrl function when creating the connection, and this has not helped either.
I have also added SignalR Event Log Trace Listeners to my web.config file, and the only warning I get that might be related to this issue is that I get a warning from the .NET runtime that reads "Failed to determine the https port for redirect." I am not sure what this means or if it would be related to SignalR, but as this also appears to deal with Middleware, it might be significant.
One thing that I thought might be related is that my site is just one of multiple hosted on this server, so that when I am running locally, I can use the following to connect to SignalR:
hubConnection = new signalR.HubConnectionBuilder().withUrl("/output").build();
But because of the way this site is deployed on my server, I have to use this:
hubConnection = new signalR.HubConnectionBuilder().withUrl("/MyApplication/output").build();
when I deploy the site or else I get a 404 error...
Would there be any issue there? I noticed when inspecting the network requests that on localhost, the URL to connect with the socket is "wss://localhost:44315/output?id=..." and I get the "Status Code: 101 Switching Protocols", but after I deploy, the url that is used is "http://myserver.com/MyApplication/output?id=..." and I get a "200 OK" just before receiving the error described at the top. Why does wss get used on localhost but http is requested from my client when I deploy?
FINALLY discovered the issue after days of debugging... The reason I was getting a "101" response on localhost and not when published is because 101 is basically the server (IIS in my case) saying "I support web sockets". I realized that because I wasn't getting this when published, web sockets were probably not enabled in IIS. It was weird, however, because I went into IIS manager and it said that web sockets were enabled, but after much more research, I found that you also have to go into "Server Manager" and enable it as well (see here https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-websocket-protocol-support and follow step by step instructions). I did not realize both were required.
trying a quick experiment with ACI to see if I can use it to host iperf3 for some on demand network performance testing. The docker image is https://hub.docker.com/r/netgio/iperf3server/
I can get the container up and running but when I try to connect to it the iperf client gives me the error "iperf3: error - control socket has closed unexpectedly"
I was hoping this would be a simple, single port, single instance use case. are there any specifics related to socket connectivity into ACI instances that would affect this?
EDIT:
iPerf3 defaults to TCP port 5201 so to ensure ACI port mappings are working as expected I created an nginx docker image configured to listen on port 5201 and deployed to ACI. This worked as expected (I could access the default home page at http://:5201). So the issue seems to be specific to whatever iPerf3 is doing with its sockets.
Note the error happens almost immediately at launch of the client iperf3 process.
Azure is experiencing an outage right now. You're probably being impacted.
http://downdetector.com/status/windows-azure
We have a makeshift SOAP client written in C# connecting to a CXF service on a desktop from a windows mobile device. When this device is connected via ActiveSync, it creates a virtual adapter for the RNDIS connection. This virtual adapter assigns a gateway IP to the host, 169.254.2.2.
When we attempt to go through the connection with the hostname or the host's IP set as the address in the C# client, everything works perfectly. When we however set the IP to be the RNDIS gateway (169.254.2.2), the connection is periodically lost on the server side. The CXF service keeps trying to connect, and eventually succeeds, but this results in a massive slowdown of the connection. There are no errors reported in our logs on the mobile C# side, only on the CXF server.
Does anyone have any clues as to why this is happening? We need to assert that 169.254.2.2 cannot possibly be used as a valid endpoint before we rule it out.
Oh, and in case it helps, the C# client is granted the IP 169.254.2.1 through DHCP after the ActiveSync connection.
The first issue that comes to my head, especially once I saw that you are using DCHP, is that the lease time on the IP from the DHCP server is expiring and the CXF server is having to wait for the DCHP server to issue a new lease.
Try lengthening the DCHP lease if you know that the IP won't be changing and use a static IP if you are able. That will at least remove that point of failure.
I found out the cause of this, but I feel bad for answering because I doubt there was any way someone else could have guessed that this was the problem:
On our CXF server, we have a call to InetAddress.getHostName() which basically does a reverse DNS lookup on the request sent from the C# client.
When using the ActiveSync IP address, there was no entry in the DNS for 169.254.2.1 (of course), so the java class would hang until the method timed out (which took about 20 seconds before it would write a response to the C# client). At 20 seconds per request, this resulted in the massive slowdown and lost connection errors.
We fixed this by moving the call to an executor thread that force-finished after half a second. Because it was in another thread, the slowdown became nonexistent. Glad to have that over with!
I need one server to receive ip requests from clients(there are not in the same intranet), and I can
route all the response packets to a special gateway server, and then I send the response packages to
clients after some processing. it is like VPN, but I want to do some development based one
opensource project, so i can control it myself.
any suggestion? thanks!
There is OpenVPN which is as the name already suggests open source.
You could set up the server on the local one as a kind of proxy (or reverse-proxy depending on your viewpoint) and have the clients connect to it.
It depends what protocol you're using, maybe it has explicit proxy capability or you can get an existing proxy program, or just proxy it using a simple socket forwarder program.