I have Nifi server connected to an OPC server to retrieve Data and send it to Kafka , the problem I have is that every time OPC server restart the port between Nifi and The OPC change and I loose connection , so I have to determine the new port and ask security team to open the New Port , is there any way to fix this Problem in Nifi ? or it should be fixed in the OPC server ?
What you explain seems normal.
When a client connects to a server normally the client's operating system assigns a random port number to the client's connection, that is normal, the one that is fixed is the port on which the server listens.
If the server reboots you will always lose the connection and the client will have to reconnect ... with a different port number
The solution is that the client tries to reconnect automatically if the connection is lost
Related
VB.NET Server Does Not Receive Connection Requests from Remote Clients
A VB.NET server application does not see connection requests from another client on the network (i.e. with a different IP address). However, it does see connection requests from the client application running on the same computer as the server.
The listening socket is created with the following parameters
System.Net.Sockets.AddressFamily.InterNetwork
System.Net.Sockets.SocketType.Stream
System.Net.Sockets.ProtocolType.IP
We have experimented with the preceding without success.
The endpoint to which the listening socket is bound specifies the local IP address and a specific port number.
The wait-for-connection code is textbook asynchronous:
thelistener.Listen(10)
thelistener.BeginAccept(New System.AsyncCallback(AddressOf targetofaccept), thelistener)
If the client that attempts connection is on the same computer as the listener, then targetofaccept is run successfully. If the client that attempts connection is on some other computer on the network, then targetofaccept is not run.
The behavior occurs for any other client on the network (i.e., not just one).
Thinking that there was some firewall issue, we created VB6 servers and clients using the same addresses and ports. The VB6 server will receive connection requests regardless of the client system.
There is no other issue with communication between clients and the server, as far as we can see. The network architecture has not been modified for a number of years.
We are debugging the code as a VB.NET console application.
Any tips on how to diagnose appreciated.
Before calling Listen() you need to bind your listener socket to the address 0.0.0.0 (in .NET IPAddress.Any) so that it listens to connections from any IP address.
This can be done using the Socket.Bind() method:
Dim listenerEndpoint As New IPEndPoint(IPAddress.Any, <your port>)
thelistener.Bind(listenerEndpoint)
thelistener.Listen(10)
Thank you.
Issue WAS firewall. Fixed by finding exact location of the IDE (devenv.exe), opening "Windows Firewall" in the control panel, selecting "Allow a program or feature through firewall", selecting "Allow another program...", browsing to the exact location and selecting the executable, then ensuring "Home/Work (Private)" column is checked for that "Name".
The question says it all. But to elaborate.
I have a oracle db running at some remote host. ip: 10.0.0.121 port: 1521
It can be accessed when I connect to a windows remote desktop machine.
Now how can I connect to this remote db from my local machine?
I believe that localtunnel is similar to telebit in that you get an encrypted https connection, not a plain tcp connection (which is good).
If I understand correctly, you'll want to use localtunnel (or telebit or perhaps even ngrok) on the windows machine to expose its database connection to the outside world. You'll want to use https (and absolutely not tcp or http which would leak database passwords and all your data) to create the tunnel.
Then you'll need to run something like sclient (or stunnel) on the computer that's doing the connecting to "unwrap" the https connection back to plain tcp. It might look like this:
sclient example.localtunnel.me:443 localhost:1521
In your database client or application you would then use localhost:1521 in your database connection string (not the https address).
This gives you the security of an encrypted connection and the convenience of exposing ports out to the world, all without adding any complexity to your application or client - you just run it as normal, connecting to localhost.
Comment if you need any additional clarification.
The Server and Client (setclientmode(true)) modes need Java and take quite a while to startup (Ignition.Start). The server is the one that holds the cache. I presume that the client node is like a 'local' copy of the cache.
However, Ignite also supports a ThinClient - where we can 'open a connection' and run queries from Ignite.NET without having Java installed. The only configuration required by a ThinClient is the Host IP Address. How can we connect to a specific grid on the ignite server using the Thin Client?
Is this something that is expected to come in the upcoming releases?
Every server node is listening to some specific port for connections from thin clients. By default this is port 10800, but it can be changed. If this port is occupied, then next available is used.
So, if you want to connect to some specific node, then you should specify its IP and port, that will be used for connection.
Documentation: https://apacheignite-net.readme.io/docs/thin-client#section-configuring-server-nodes
I discovered today that if I ssh-forward the local port X to ssh server port Y, and no process is listening on port Y, I can still connect to local port X (I don't get the usual "connection refused" error).
I did my test with 2 different SSH clients on a windows host connecting to a linux server.
After a bit of reflexion, I came to the conclusion that from a pure network point of view, this is the behaviour I should expect: the SSH client is actually listening on localhost:X, so the connection is possible.
Nevertheless, this leads to a problematic situation in which I have an apparently connected socket that talks to nobody. Even sending data on the socket is a successful operation.
So my question: does the SSH protocol manage this situation in some ways, i.e. do I have strategies for detecting this situation? And if yes, may I hope support for this feature on some SSH clients and APIs (today I'm using ssh.net, that does not seem to offer this feature).
If not, how would you proceed for detecting the situation? Timeout on answer?
Thanks for your help,
Alberto.
The only logical behavior would be to close client connection if the server can't connect to the remote side, but that would not be much better than just a hanging connection.
Also there can happen situation when the SSH server is waiting for the remote connection for a minute or two before giving up, so the client's connection will be opened for this period of time anyway.
So there's actually no logical alternative rather than a hanging client connection.
First off, I already know that Windows Firewall is blocking my connection -- I just don't know what to do about it. When I turn WF all the way off, my remote connection works. I already have a Rule to allow incoming requests at port 1433, and it seems that's the right port, but I'm unsure. Now for more details.
I had SQL Server 2008 R2 on my remote dedicated server and had no problem connecting remotely via SSMS. But then I installed SQL Server 2012. It works fine, but I was forced to create a named instance for it during installation because the default instance is in use by SQL08.
My ASP.NET connection string running on that box works fine and connects to sql12 with no problem. Here is the obfuscated connection string:
Server=myserver\MSSQLSSERVER2012;Database=MyDB;User Id=Me; password=MyPaSS;
It looks like the named instance is using port 1433. I verified that SQL Browser is active and running. I have a windows firewall exception that allows sql server and port 1433, though that was there before and I'm wondering if that's only working for the now-disabled SQL08 (how do I ensure this is working for SQL12).
Say the IP to that server is 1.2.3.4
From SSMS I have tried connecting to the server thusly:
1.2.3.4
1.2.3.4\MSSQLSSERVER2012
1.2.3.4\MSSQLSSERVER2012,1433
Nothing works. Always the error is:
I have read a number of articles on this topic and they all say:
enable SQL Browser (done)
open a port in Windows firewall (seems done ??)
So how can I discover what exactly I need to do in Windows Firewall to fix this? I cannot turn the whole thing off, this is a public web server.
Here is the list of the ports that SQL Server Features use. Depending on the features/services you use you may need additional ports TCP/UDP opened. Also under server properties > connections > confirm that Allow remote connections to this server is checked. The instructions of remote connection is for 2008, since you mentioned that turning firewall off that you are able to connect remotely then I would guess this is not needed but would not hurt to double check this.
Configure the Windows Firewall to Allow SQL Server Access
Enable Remote Connections
A short answer is:
SQL Server default instance uses TCP port 1433, unless messed about with (don't do it!). If you only have a default instance, that's the only port you need, I believe - SQL Server clients don't use the browser service to find a default instance.
SQL Browser comes into play if named instances are used. This listens on UDP port 1434; it responds to requests for port numbers for named instances.
By default, named instances use dynamic TCP ports - so a different port each time they start up. The browser sorts this out for you but it's a pain through a firewall.
There is no reason why you shouldn't set a fixed port in SQL Server config manager for a named instance (say, TCP Port 1434 or whatever) so that you only need to open one extra port for the named instance.
If you use named instances, adding port 1433 is not enough.
You can reproduce this:
install a named instance
add inbound rule 1433
allow remote connections
When you try to connect you get an error that the server cannot be found. When you turn of the firewall it all works, so there must be another port needed to get it to work.
You need to open port 1434 UDP and start SQL Browser, now it works.
One or more of the following solved the problem and enabled me to connect with my remote sql server:
Allow remote connections in mssql properties
Enable MSSQL exe in winfirewall
Enable SQL Browser in winfirewall
Explicitly opened port 1433 tcp and 1434 udp
SQL Browser running as a service
This worked for me :)
If you have tried all of the above and you're still getting that error - try adding the IP and instance name to the host file of the server you are connecting FROM like this:
111.11.111.1111 INSTANCENAME #IP and Instance Name of server connecting TO
This worked for me after DAYS of going through opening ports, UDP, TCP/IP, etc. I was able to connect using a connection string with the IP, but never the instance name itself. Confirmed the login info was correct, SQL Browser was enabled and running. I hope this helps.