I recently deployed an Azure app to the staging environment which is supposed to accept TCP packets in port 2993. When run in the Azure emulator, it does this very well, and performs exactly as it should.
However, now that it is on Azure's staging servers, whenever I try to connect to the TCP port, i get the following SocketException:
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
My web app has two instances, one is a worker role (it has 2993 configured in its endpoints) and a web role (only for port 80). Port 80, by the way, functions perfectly. The web app was created with Visual Studio in C#. Why is this happening and how can I fix it?
All help is greatly appreciated.
I would like to explain what was the issue and why adding above code solve this problem for others benefit.
In your worker role, you configure any TCP endpoint along with any port number. When this VM starts the VM is provisioned to use this port and firewall is included an exception to provide access to this port. By the time your is ready to start your Azure VM already have TCP/IP address and configured port is enabled.
Now when your role starts and if you have any service or application required access this port you really need to l
For example If I have Tomcat/Java configured in my worker role, I must have to create a TCP listener on my configured port. This can be done when my worker role starts as below:
Get the IP address and Port number of the current role instance
Create a TCP Listener and start on this IP address and Port
Add the code to perform step 1) and 2) in my worker role OnStart() function.
The code will look like as below:
TcpListener TomcatPortListener = new TcpListener(RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["TomcatWeb80"].IPEndpoint);
TomcatPortListener.Start();
In your case you you did exactly the same you got the IP address and Port number from and then created an endpoint from a socket address using IP/Port:
RoleInstanceEndpoint externalEndPoint = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["TCPin"];
IPEndPoint localEndPoint = new IPEndPoint(externalEndPoint.IPEndpoint.Address, externalEndPoint.IPEndpoint.Port);
localEndPoint.Create();
It is a must setting for any web or worker role which create TCP endpoint.
It seems the problem had something to do with the program's detection of the server's IP address. By using the following server code instead, I managed to fix the problem:
RoleInstanceEndpoint externalEndPoint = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["TCPin"];
IPEndPoint localEndPoint = new IPEndPoint(externalEndPoint.IPEndpoint.Address, externalEndPoint.IPEndpoint.Port);
The IPEndpoint can then be used with the tcpListener socket.
Related
Using the example Chat Server/Client project available as part of the Akka.NET source code I have attempted to modify it such that it would successfully work over two computers on my network.
I have two systems that are connected via a router like this
192.168.0.29 (Server) <---------------| Router |---------------> 192.168.0.52 (Client)
I then have two actor systems that are configured like this:
Server:
akka {
actor {
provider = remote #Specify remote provider
}
remote {
dot-netty.tcp {
port = 666 #Akka server port number
hostname = 0.0.0.0 #Bind to all local network interfaces
public-hostname = 192.168.0.29 #Expose public IP to enable correct routing of public messages.
}
}
}
Client:
akka {
actor {
provider = remote
}
remote {
dot-netty.tcp {
port = 0 #Tell Akka that this is a client connection/use random port.
hostname = 192.168.0.29 #Tell Akka.NET which remote instance to connect to
}
}
}
Unfortunately, while I am able to successfully connect to the chat server locally, no matter how I configure my Hocon I cannot seem to get the remote instance to bind to my server actor located on the machine 192.168.0.29.
The specific error message that I receive
[ERROR][27/11/2019 4:58:36 PM][Thread 0004][Akka.Remote.Transport.DotNetty.TcpTransport] Failed to bind to 192.168.0.29:0; shutting down DotNetty transport.
Cause: System.Net.Sockets.SocketException (10049): The requested address is not valid in its context
at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, String callerName)
This error message suggests to me that there is no available socket that Akka.NET can access.
Ironically enough, some time ago I asked a very similar question which at the time helped me resolve my connectivity issues but I never used Akka.NET till recently again.
I note that both machines have their firewalls turned off and can successfully ping each other, I have also played around with all various combinations of settings.
The original source code to the Akka.NET server/client application is located here, my current version of it is here.
Could anyone provide any insight into what I might be doing wrong and how I can improve my debugging of Akka.NET remote connections? For example is there a way that I can verify that the Actor system on server 192.168.0.29 is accessible from 192.168.0.52 externally?
Haha, and literally 5 minutes after posting my question I was finally able to determine the solution (although its not ideal).
The solution was the realisation that when you instantiate the ActorSystem on the client application you are NOT actually connecting the local actor system to the remote system BUT rather creating a local instance of an actor system which itself is listening on a random port.
The remote connection itself occurs when you create an ActorSelection() reference.
So all I needed to do was change my client hocon from
hostname = 192.168.0.29
TO
hostname = 192.168.0.52
However this creates one final (albeit rather small) problem. I now need a different hocon file for an instance running locally vs an instance running remotely. Admittedly this could probably be addressed through code....
I'd be happy to mark as the solution someone who might be able to propose something that addresses this issue.
I currently have 2 .Net applications which run on the same PC simultaneously.
These 2 applications communicate using UDP like this:
Client:
udpUnityToConsole = new UdpClient();
udpUnityToConsole.Client.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);
try
{
udpUnityToConsole.Connect("localhost", 11004);
}
Server:
unityUdpReceive = new UdpClient();
unityUdpReceive.Client.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);
unityUdpReceive.Client.Bind(new IPEndPoint(IPAddress.Any, 11004));
The communication stream is fast and reliable, there is just one issue with it and that is that if the PC is not connected to a network then it will crash with a
System.Net.Sockets.SocketException: No such host is known.
If the connection has been established already and then the PC is disconnected from the network, the connection will remain. Only if there is no network connection to start with will it fail.
Any suggestions are greatly appreciated.
All I had to do was change localhost to 127.0.0.1 which is the address of the local machine and never changes, therefore it is safe to use. Using localhost meant that the UDP library had to look up the IP being used with the localhost alias, but that wasn't necessary as I knew it already. I could probably also find out the IP some other way and run that query on both applications.
I want to listen for HTTP requests and TCP connections on the same port but on different IP addresses.
string prefix = "http://192.168.1.2:40000/";
HttpListener http = new HttpListener();
http.Prefixes.Add(prefix);
IPEndPoint ep = new IPEndPoint(IPAddress.Parse("192.168.1.3"), 40000);
TcpListener tcp = new TcpListener(ep);
If I start the HttpListener first, I get an error when starting the TcpListener.
An attempt was made to access a socket in a way forbidden by its access permissions
If I start the TcpListener first, I get an error when starting the HttpListener.
The process cannot access the file because it is being used by another process
When the HttpListener is running, netstat reveals that it's only listening on the IP address specified, but it's running in the System process (PID 4).
Proto Local Address Foreign Address State PID
TCP 192.168.1.2:40000 0.0.0.0:0 LISTENING 4
When the TcpListener is running, it's also only listening on the IP address specified, but it's running in my application's process.
Proto Local Address Foreign Address State PID
TCP 192.168.1.3:40000 0.0.0.0:0 LISTENING 18316
Even though they listen on different IP addresses, there's still a conflict that won't let me do both at the same time.
I am able to run two HttpListeners and two TcpListeners on different IP addresses with the same port, however.
Update
The question was asked:
How do you have assigned two local IP addresses on the same LAN segment?
Originally I had two IP addresses on the same network adapter in the same subnet (255.255.0.0). (See how this is possible at https://superuser.com/questions/571575/connect-to-two-lan-networks-with-a-single-card).
To rule out this as an issue, I setup a virtual machine with two network adapters on different subnets. The results were the same.
Apparently you must tell HTTP.sys which IP addresses to listen on because it hijacks them all by default.
In my case, running the following command allowed me to run HttpListener and TcpListener on the same port on different IP addresses.
netsh http add iplisten 192.168.1.2
Sources
Disabling HTTPS Socket Pooling
add iplisten
I am trying to connect to a sensor using network, the sensor's ip is 192.168.2.44 on port 3000;
My Code:
byte[] byteReadStream = null; // holds the data in byte buffer
IPEndPoint ipe = new IPEndPoint(IPAddress.Parse("192.168.2.44"), 3000);//listen on all local addresses and 8888 port
TcpListener tcpl = new TcpListener(ipe);
while (true)
{
//infinite loop
tcpl.Start(); // block application until data and connection
TcpClient tcpc = tcpl.AcceptTcpClient();
byteReadStream = new byte[tcpc.Available]; //allocate space
tcpc.GetStream().Read(byteReadStream, 0, tcpc.Available);
Console.WriteLine(Encoding.Default.GetString(byteReadStream) + "\n");
}
But when I run this code, I get this error:
The requested address is not valid in its context
Use IPAddress.Any to listen. This seems to be your goal:
//listen on all local addresses
The listening address you have specified is invalid for some reason. There is no need to specify a numeric address.
The TcpListener listens for connections from TCP network client, on a given port on your local machine. That is, for incoming connections. Your code will be acting as a "server" of sorts.
The requested address is not valid in its context
Simply, it means that the IP address given is not used by any network interface on your machine.
Use IPAddress.Any to listen on any IP address (i.e. network interface).
However, it might be the case that you need to connect to the sensor (on port 3000), not the other way around.
EDIT: The new exception just tells you that you have two applications trying to listen to the same interface/port combination. Do you have two instances running at the same time?
One of the reason for this issue could be the presence of defaultProxy section in the configuration file which would be routing every outgoing call via proxy address mentioned in this setting. Ensure that either there is a proxy server/service listening at the proxy address, or comment this section to stop the routing. In case the application configuration file does not have it, and this error is still there, check for the defaultProxy section in the machine.config file. machine.config should be available in folder C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config. In our case it was the defaultProxy in machine.config.
I have 2 instances of the same application, on different machines, that should talk with each other, where no one is a typical server or client.
Both instances of the application has a TcpListener, local port = 8000.
One application instance (call it "A") creates a TcpClient. Now, this client can't have local port = 8000, or the constructor throws the socket exception "Only one usage of each socket address (protocol/network address/port) is normally permitted".
So, I create this first client with a random local port, and run Connect() to connect with the other application instance "B".
"B" accepts the connection using TcpListener.AcceptTcpClient(), which returns a TcpClient that can be used to communicate with "A". Though, this TcpClient has the same IP and Port as the TcpListener!? How is this possible, when I could not use the same port when I created the TcpClient manually on "A"? I actually really would like them to use the same port as the listener, on both machines...
So, how can I create the TcpClient on "A" with same port as the TcpListener?
I think you might not fully understand the address port client server architecture.
TcpListener is listening to any connection on address and port. After connection established you can use the "Socket" to receive and send messages from the client and server both.
example:
0.0.0.1 is machine A.
0.0.0.2 is machine B.
you can put a TcpListener that is listening on port 8000 on machine A. When the TcpClient on machine B will make try to connect machine A on port 8000 the TcpClient on machine B will get a generated (by the OS) port.
and then you will have a connection
0.0.0.1:8000 -> 0.0.0.2:3587(Generated port) - so you dont need to worry for the client listening port.
A TCP Connection has always a server and a client side. The server is listening (waiting) for a connection and the client connects to the server.
When the server gets the connection request, AcceptTcpClient gives you the socket of the server side to communicate with the client. A TCP Connection is always defined with the IP Addresses and Ports of the two sides: serverip:serverport and clientip:clientport.
If you want a really symmetrically System, both instances would have a server and a client that connects to the other server. All data that would then always be sent from client to server over the connection that was established by the client.
For Example:
ClientA connects to ServerB -> ConnectionAB
ClientB connects to ServerA -> ConnectionBA
ApplicationA sends data to ApplicationB over ConnectionAB
ApplicationB sends data to ApplicationA over ConnectionBA
If your goal is to use 2 TCP endpoints to talk to each other, without one of them being an
explicit server always, you probably should run a listener (on port 8000, in your case)
on both machines. Next, let each machine try randomly for the connection -- let each
machine pick a random time (between 0 and T) and then wake up. Whichever machine
wakes up first, will call connect() and establish the connection.
As #nivpenso pointed, the end point doing the connect need not explicitly bind to
a port. The connect() step explicitly assigns a temporary random port to that
end point.
So, if hostA initiates the connection, here are all the endpoints you would see
(you can use netstat to see these connections)
HostA:
-- listener: 8000
-- connection to hostB:port8000, localport:xyz
HostB:
-- listener: 8000
-- connection to hostA:port:xyz, localport:8000
On the other hand, if hostB initiates the connection, here are all the endpoints you
would see:
HostA:
-- listener: 8000
-- connection to hostB:port:xyz', localport:8000
HostB:
-- listener: 8000
-- connection to hostA:port8000, localport:xyz'
In the Internet, BGP uses a similar method to connection 2 TCP peers.