I am trying to write something on WebSocket with Amazon ws. The problem is that I can not open the port by running this :
conn = new WebSocket('ws://ec2-54-213-181-25.us-west-2.compute.amazonaws.com:8081');
My port config on inbound and outbound in security for TCP and ICMP are all range 0-65535 and destination 0.0.0.0/0. But I still cannot open port 8081.
Can anyone tell me the wrong thing I did?
You have to create your websocket in private ip of Your EC2. Then you can connect your websocket using your public ip or url with port number
Pointed out that I need to open the port by this way :
socket = io.connect("abc:123");
so they are the same websocket version
Related
I have an EC2 instance behind a load balancer. The security group attached to it allows for inbound connections (both ipv4 and ipv6 on port 6379). I am able to connect to my redis client:
redis-cli -h ec2-**-**-**-*.us-west-1.compute.amazonaws.com -p 6379
However, when I try to connect with nodeJS and express-session I get a ConnectionTimeoutError on EC2, but locally it works fine:
const redisClient = createClient() // uses default port localhost:6379
redisClient.connect().catch(console.error)
If there is a race condition here, like others mentioned, why does this race condition happen on EC2 and not locally? Is the default localhost incorrect since there is a load balancer in front of the instance?
Based on your comments, I'd say the problem is the load balancer. Redis communicates on a protocol based on TCP. An ALB is only for HTTP/HTTPS traffic, so it cannot handle this protocol. Use a Network Load Balancer instead, with a TCP listener. Also make sure your security group rule also allows TCP traffic for port 6379.
Redis client should be instantiated explicitly in a setup like this one (covers both ipv4 and ipv6 inbound traffic):
createClient({ socket: { host: '127.0.0.1', port: 6379 }, legacyMode: true })
As redis is self-hosted on EC2 with a load balancer in front of the instance, localhost may not be mapped to 127.0.0.1 as a loopback address. This means that the default createClient() without a host or port specified, might try to establish a connection to a different internal, loopback address.
(Make sure to all inbound traffic to tcp 6379, or the port you are using)
Requisites:
I should open multiple sockets/connections to the same server IP and
Port.
I should detect from which connection a request has come and
reroute the response to the same connection
A connection is represented as server Ip and port + client Ip and
port
Each connection has to be single-use=false, it is expected to have multiple request/replies
I'm using collaborating TcpReceivingChannelAdapter and TcpSendingMessageHandler with TcpNetClientConnectionFactory.
And IntegrationFlow for generating those connections dynamically.
How to create multiple sockets for TcpNetClientConnectionFactory that all point to the same Host and port?
I know how to set destination with new TcpNetClientConnectionFactory(host, port). But I'm unable to see or find how to affect which port is used
Should it be done with multiple TcpNetClientConnectionFactory each being bound to one inbound and outbound TCP adapter?
How can I set the local port for those connections? or at least how to obtain it?
I don't seem to find any documentantion about this option. The most similar would be This question
You need a separate connection factory/adapters for each.
See TCP Connection Events.
Use an ApplicationListener or #EventListener to receive TcpConnectionEvents.
The event has getConnectionId() which contains both the local and remote port; the event also has the connection factory bean name.
Or you can cast getSource() to TcpConnection and call getPort() (but you should not otherwise interact with the TcpConnection object.
I can't connect to my queue on azure account using java code. It seems that the problem is the network. I can to connect with my private network but not with the company network.
I have this message error:
Exception in thread "main" http://com.microsoft.azure .servicebus.primitives.ServiceBusException: Error{condition=amqp:connection:framing-error, description='connection aborted', info=null}.
Any hints?
It seems that the problem is the network. I can to connect with my private network but not with the company network.
Yes, you are right. I also find the simlar issue on the github. It seems that your company firewall restriction which blocks all traffic on ports 5671 and 5672. We could get more information from AMQP 1.0 in Azure Service Bus and Event Hubs protocol guide.
Azure Service Bus requires the use of TLS at all times. It supports connections over TCP port 5671, whereby the TCP connection is first overlaid with TLS before entering the AMQP protocol handshake, and also supports connections over TCP port 5672 whereby the server immediately offers a mandatory upgrade of connection to TLS using the AMQP-prescribed model. The AMQP WebSockets binding creates a tunnel over TCP port 443 that is then equivalent to AMQP 5671 connections.
If possible, you could ask permission to open 2 ports in your company firewall.
I have a client which is intended to connect to a server. For the client, the remote TCP port number is fixed(i.e. 102). I can NOT change it(while I can change the remote IP address). However, the TCP Port number the server is listening on is fixed as well(i.e. 1024) and I can NOT change it too. These two port numbers are different. I want to make the client connect to the server smoothly.
At the first, I had a idea that I setup a proxy listening on localhost:102 and the client connect to 127.0.0.1:102. Then this proxy redirect these TCP traffic to the real address RemoteServerIP:1024. But I found on my windows, there was already a process which is listening on 0.0.0.0:102 and I can NOT change its listening port. So this idea can NOT work.
Thank you very much.
if you cannot do it on the same windows machine running client, why not try to do it on another (linux maybe) machine?
I am trying to run a socket server on an Amazon Web Services EC2 instance. The socket is able to run just fine on it's own, and telnetting locally on the instance can connect, but trying to telnet to the socket from the outside is failing. I have gone into the security groups to ensure the ports I am using are open for both TCP and UDP (though the socket server has been configured for TCP). Is there something else I am missing?
The server might be listening on the loopback interface or ipv6 by default. You can check that by running netstat --listen -p which will show you which program listens on which address/port. How to make the program listen on the external ipv4 interface depends on the program/programming language.