ActiveMQ's default port 61616 collides with the IANA recommended range for ephemeral ports (49152-65535).
This can keep ActiveMQ from binding to 61616 if it is used by an existing TCP connection.
Collisions shouldn't be a problem if the ActiveMQ broker is started on system boot, since the OS would likely start at the low end of the port range and wouldn't collide with 61616 until tens of thousands of TCP connections had been established.
However, collisions are possible if the ActiveMQ broker is restarted any time after boot.
Should ActiveMQ users not be using 61616 for real installs, or should port 61616 be excluded from the server's ephemeral port range during deployment?
In practice this does not tend to be an issue, as ActiveMQ brokers tend to run on dedicated servers without a lot of outbound connections, and therefore ephemeral port usage. They also run either as a Windows service or Unix daemon, so are able to get that port without any real hassle. In most production settings 61616 is used.
Related
I am working in a legacy VB6 project that involves TCP Communication using sockets.
Application requires long lived socket connections but i doubt to how much extent it is possible.
Application runs in windows OS.
If after a socket connection in established and some data is exchanged at regular intervals say 30 sec,
will the connection lives forever or is there any constraints from OS or TCP stack or network provider?
There is no technical limitation against having a TCP socket connected for months on end.
Skype will have a 24/7 TCP session established to a server as long as it's running.
The idea of TCP is that you:
syn→
← synack
ack→
And now your connection is established. Barring some technical issue (rebooted machines), that TCP connection will stay up forever. Yes there may be various edge firewalls that have to maintain stateful information about that TCP/IPv6 (or TCP/IPv4) connection - but that is the firewall's problem.
Their job is to route traffic. If they can't handle n open connections: then they need to be redesigned.
I want to connect to a Cisco Anyconnect VPN (which I believe does NOT act as a proxy -- my IP address doesn't change when connecting to this VPN).
However I wish to hide my true IP to the Cisco Anyconnect server I'm connecting to.
Can I connect to another VPN service like TunnelBear first, then connect to the Cisco Anyconnect server, and be sure the Cisco Anyconnect server is seeing my TunnelBear proxy IP and not my real IP?
The scenario you are describing should be possible, using the technology you described. I would assume the sequence of events would follow:
Initiate OpenVPN connection
Initiate Cisco VPN connection
However, keep in mind that you may need to install a client to access the Cisco VPN. These clients tend to interact with and potentially manipulate your operating system's network configuration, this makes sense when you consider that these applications are built to re-route your network traffic. These clients would most likely have the ability to see your VPN configuration.
A possible workaround to the issues outlined above, regarding the local client being able to recognize your network configuration: one might configure their host's entire gateway (router or perhaps virtual machine host) to route traffic through the primary VPN.
You should keep in mind the resource usage and computation power required in order to maintain each VPN's security and (possibly) compression layers.
Even if the second VPN connection is established, I wouldn't expect quality performance, and multiple compression layers could be suboptimal.
I know that port numbers are used for identifying different processes running on a server, so that multiple processes can use the same networking resources. But how does it work internally?
For example, if a request to a website http://www.my-awesome-website.com:80 reaches a server, how does the server know that there is a web server running on port 80? I mean, what does the request pipeline look like between getting the request to finding out that a web server is running on port 80 and forwarding the request to the web server?
Port numbers are merely addresses for some transport-layer protocols, such as TCP and UDP, in the same way that IP addresses are for layer-3 protocols, and MAC addresses are for layer-2 protocols. Not all transport-layer protocols use ports, and each transport-layer protocol independently maintains its ports so that TCP port 80 is not the same as UDP port 80, and each can be used simultaneously by different applications.
Layer-2 addresses are only relevant to the LAN links, layer-3 addresses are only relevant host-to-host over the layer-3 network, and layer-4 addresses are relevant application-to-application.
IANA registers ports and maintains the official registry list at Service Name and Transport Protocol Port Number Registry.
From RFC 793, TRANSMISSION CONTROL PROTOCOL:
Multiplexing:
To allow for many processes within a single Host to use TCP
communication facilities simultaneously, the TCP provides a set of
addresses or ports within each host. Concatenated with the network
and host addresses from the internet communication layer, this forms
a socket. A pair of sockets uniquely identifies each connection.
That is, a socket may be simultaneously used in multiple
connections.
The binding of ports to processes is handled independently by each
Host. However, it proves useful to attach frequently used processes
(e.g., a "logger" or timesharing service) to fixed sockets which are
made known to the public. These services can then be accessed
through the known addresses. Establishing and learning the port
addresses of other processes may involve more dynamic mechanisms.
Connections:
The reliability and flow control mechanisms described above require
that TCPs initialize and maintain certain status information for
each data stream. The combination of this information, including
sockets, sequence numbers, and window sizes, is called a connection.
Each connection is uniquely specified by a pair of sockets
identifying its two sides.
When two processes wish to communicate, their TCP's must first
establish a connection (initialize the status information on each
side). When their communication is complete, the connection is
terminated or closed to free the resources for other uses.
Since connections must be established between unreliable hosts and
over the unreliable internet communication system, a handshake
mechanism with clock-based sequence numbers is used to avoid
erroneous initialization of connections.
After opening a socket(which is like an open file but used for network communications), the user of the socket may use it directly with an ephemeral port(selected by the OS), which is typical if the application is a client application.
What server processes do is to call the bind() socket API call to set a port for the socket, and then call listen() in case of a TCP socket to start listening for incoming connection requests.
Because of the bind() call the OS will know that this particular socket is the one receiving the data sent to the particular port number.
The packets sent over the network contain the source and destination IP addresses as well as the source and destination ports:
http://www.techrepublic.com/article/exploring-the-anatomy-of-a-data-packet/
So the OS has a data structure with open sockets listed by their port numbers and it will pass the received data to the correct socket's input buffer. Sent data will be marked by the port number of the sending socket.
I'm receiving lots of information per client, and i don't know how to handle it. If i make lots of connections to one port will it work? Now, I'm using 1000 ports open with only one client. Do I change?
Typically, one application or one major part of application should have its own port. For each client that connects to the port, you spawn a process/create a thread to service it. After the service is complete and the reply sent back, if connection is not persistent, you close it.
After all, you can only have 65535 ports open on your pc (theoretically), and not all of those are available for private (non system) applications either.
So the way to go is to have one port for application/major application functionality. E.g.
Database Management Systems (e.g. DB2) can have a (theoretical) max limit of 64000 connections per port.
http://pic.dhe.ibm.com/infocenter/pim/v6r0m0/index.jsp?topic=%2Fcom.ibm.wpc.adm.doc%2Fdata_admin%2Fwpc_con_managedb2connections.html
Multiple clients can connect to the same listening port, so you only need to open 1 port in most cases (some protocols, like ftp, use multiple ports). It is the combination of client IP/port and server IP/port that uniquely identifies a connection, so it works just fine. There are multiple programming models available to allow a server to service multiple clients at one time.
As far as I know, a (single generic) webserver uses ports (like any other tcp/upd application) to identify users/process. Since, a port is a 16-bit unsigned integer, thus ranging from 0 to 65535. How does server act when it reaches its limit?
High level sample
The server1 answering by 8080! The client1 conect to server1 (now they are connected by random ports: (but unique) server1:5123 <--> client1:6123)
Another client2 connect to the server1 ( server1:5124 <--> client2:7123 )
So, the thing is: Is the server limited by 65535 (in pratical less than that) for a given instance?
In the simplest case a webserver consumes only one TCP port (conventionally port 80) on the server system. All of the connections to the webserver are handled through that single port. The other 65534 ports remain available for other uses.
This works because a TCP connection is identified not just by the port number on the server, but by the combination of (server IP, server TCP port, client IP, client TCP port). So the server can have a huge number of concurrent TCP connections all on its port 80, using the other three items to identify which connection the traffic belongs to. If the server only has a single IP address, and therefore the (server IP, server port) portions are identical on all connections to the webserver, the individual connections are still distinguishable by the (client IP, client port) portions of the combination.
If you run the netstat -a command on a busy Unix webserver you'll see this in action. That command will show a bunch of connections on the server's port 80, but all with different client IPs and/or ports. It'll also show that the system is still listening for new connections on port 80, at the same time as it is handling all of the existing connections on that port.
The total number of connections to the webserver might be limited by some other constraint (perhaps memory usage, perhaps some arbitrary limit in the webserver itself or in the OS kernel) or by some external constraint (perhaps connection table size in external firewalls or gateways) but it's not limited by the 16-bit TCP port range.
Also note that TCP ports are completely separate from UDP ports, so using TCP port 80 for a webserver does not prevent UDP port 80 from being used for some other purpose. And vice versa.