Can an application use two different ports simultaneously?
yes , if and only if it is not already occupied
In general, yes. Just open two sockets.
Of course there may be a firewall present and the firewall may not be configured to allow the application to use both ports. But most any firewall should support the ability to configure a range (or multiple distinct ranges) of ports as accessible to a given application.
Related
Like the title says, is it possible to run multiple Bluemix containers with the same public IP address, but with different ports exposed? (There should be no need to buy additional or waste IPv4 space.)
I'd like to run 6 differently parameterized (with environment variables) containers. The difference would be the exposed port numbers (and the inner application logic).
The only thing I need is to be able to access that port either with Docker configuration or other solutions, like NAT between these 6 images and a "router".
Thank you.
This is not possible with IBM Containers.
I have two applications (diy container type) which have to be connected via TCP. Let's take as example application clusternode1 and clusternode2.
Each one has TCP listener set up for $OPENSHIFT_DIY_IP:$OPENSHIFT_DIY_PORT.
For some reason clusternode1 fails to connect to any of the following options for clusternode2:
$OPENSHIFT_DIY_IP:$OPENSHIFT_DIY_PORT
$OPENSHIFT_APP_DNS
Can you please help in understanding what should be url for external TCP connection?
You might check the logs to see if the OPENSHIFT_DIY_IP for both apps are within the same subnet. If one, say, is...
1.2.3.4
...and the other is...
1.5.6.7
...for example, then you might not expect Amazon's firewalls to just arbitrarily allow TCP traffic from one subnet to another. If this were allowed by default then one person's app might try to hack another's.
I know that when you're dealing directly with Amazon AWS and you spin up multiple virtual servers you have to create virtual zones to allow traffic between them. This might be something that's necessary.
Proxy Ports I don't know if this is useful but it's possible that a private IP address is being bound to your application(s) and then a NAT server is translating that into a public IP address.
I have talked with some Oracle DBAs, and they told that there is a component called Oracle Listener ( http://docs.oracle.com/cd/B19306_01/server.102/b14196/network.htm ) that permits to filter the network traffic to a database, for example when the machine has many network interfaces.
Is there any tool similar in DB2? or how can I do this? because I just can configure one port per instance, and that is all. If I want to configure more, I have to do it via IPTables of firewall. However, I cannot configure which users, applications, or workload should connect which network interface.
A database server is generally not a good place to implement and manage a complicated networking scheme. From a CPU standpoint, you'd be better off delegating that responsibility to more specialized equipment (switches, routers, firewalls, etc.), and saving precious CPU cycles for database query processing instead. Running a simple, straightforward network configuration on the database server will also make it easier to secure your databases, because fewer administrators will require root access on the database server when it doesn't require regular attention from network admins.
Although the DB2 instance listens on just one TCP port (specified by the DBA), it will listen on that port on multiple network adapters and multiple IP addresses defined on those adapters. The instance will also listen on other network protocols that you've specified via the DB2COMM registry variable. Nothing at the DB2 configuration level controls which local NICs and/or IP addresses are allowed to accept inbound DB2 connection requests. However, when such granularity is needed, it's best to handle that from a dedicated firewall or router rather than a copy of iptables running locally.
I can't think of a reason that DB2's policy of one TCP port number per DB2 instance should be treated as a limitation. Even if DB2 allowed it (or could be tricked into doing so), listening on additional ports wouldn't accelerate response times for establishing a database connection, nor would it provide the instance with any more bandwidth than it already had. Increasing the number of agents/threads would change the performance characteristics, but none of those actions require the instance to listen on more than one TCP port. It would help if I understood the nature of your current (or anticipated) problem that stems from this policy.
If some of your questions are based on concerns about a NIC being a single point of failure, you may want to look into ethernet bonding, which creates the appearance of a single logical NIC from a pair of physical NICs. This is handled by networking features of the operating system, effectively hiding the complexity from database servers and other networked applications.
Network adapters in most servers now operate at gigabit speeds or faster, which all but eliminates the risk of the NIC being saturated by legitimate database traffic. If your DB2 application workload really is pushing the gigabit per second boundary all by itself, then congratulations, your organization is probably getting enough value out of the database to consider clustering it across multiple physical servers (InfoSphere Warehouse or DB2 pureScale, depending on the workload). If you're occasionally encountering network contention on the DB2 server that is caused mostly by other traffic, such as network-attached storage or network-based backups, that traffic can be isolated to specific NICs and away from the DB2 clients through network addressing techniques and some routing/switching hardware.
There is another approach to restrict connections to the database using CONNECT_PROC database configuration parameter. You just have to create a Stored procedure without parameters, and added in this configuration parameter.
The stored procedure will allow or deny the connection by retrieving info from the environnement.
For more information please check this paper: http://www.ibm.com/developerworks/data/library/techarticle/dm-1305db2access/index.html
Why does the client end of a connection
use high port number(ephemeral ports) whereas the applications
listen on typically small port numbers ?
Thx in advans,
Karthik Balaguru
Servers listen on a fixed port number so that clients will know where to connect. Clients do not need to use a fixed port number, since no one is initiating a connection to them, and in fact they cannot use a fixed port number if there may be more than one client running on the same machine (e.g. a web browser) connecting to the same server. IANA has designated ports in the range 0..49151 as fixed port numbers for specific services, and ports in the range 49152..65535 as dynamic (ephemeral) ports which are not assigned to any service and can be used when a fixed port number is not required.
The port range 0..49151 is further divided into the well known range 0..1023, which only a privileged process can bind to (at least on Unix/Linux), and the registered range 1024..49151. Ports in the range 1024..49151 can be used by server processes that may run as an unprivlieged user, and it is also possible for clients to use ports in this range if they are not being used by a server (e.g. dynamic ports on Linux and Solaris start at 32768 by default, rather than 49152).
Ports numbers under 1024 are called "registered", while those above (limit of 65,535) are called "unregistered". All these two terms mean is that ports under 1024 have standard services associated with them. IE: 53 for DNS, 80 for HTTP, 25 for SMTP, etc. Note they are associated - there is nothing to stop you from setting your application to use port 53, 25, etc but it's not recommended because other services will attempt to connect and or operate on these ports so it could cause problems.
The unregistered port region is dynamically used by client applications. IE: You are reading this answer while connecting to port 80 of the StackOverflow.com webserver(s), but your browser is using an unregistered port to initiate that request.
Because server ports are usually well known ports. On a Unix box you will see their assignment in /etc/services file. The client ports, on the other hand, are usually picked by TCP/IP stack from the specific high range. So servers know what ports to listen on, clients know what port to connect to, and nobody cares what port the connection is made from.
Lower port numbers (< 1024) are reserved to privileged processes. In addition, many of these ports are assigned to specific services by the Internet Assigned Number Authority. Clients establish connections to servers listening on these well-known ports, but use dynamically assigned port numbers in the higher ranges according to the ports that are available to them.
Lower port numbers are typically reserved for common applications. Shorter = easier to remember.
In short: How to reliably discover a server running somewhere on a (presumably multi-segmented) local area network with zero client configuration
My client application has to locate the server application without knowing the server IP address. It has to work on a local LAN that may be split into segments with hubs or other switching devices.
I already have a working solution, but it is a bit cumbersome to get it working on multi-segment networks. It works as follows:
When the client starts up, it sends UDP broadcasts on its own network segment. If the server is running on the same segment, it works without any issues - the server responds with the appropriate messages.
If the server and client are running on networks separated by a hub / switch that won't forward UDP (the most likely case), then I have a server instance running on each segment, and they forward client requests to each other via TCP - but I need to configure this for the server instances (simple, but still a pain for tech support.) This is the main problem that I need to address. There are sites where we have hundreds of clients running on 5 or 6 separate segments.
The problems I'm facing:
1. Although my application installer enables the appropriate ports on the firewall, sometimes I come across situations where this doesn't seem to happen correctly.
2. Having to run multiple server instances (and therefore configure and maintain them) on hub/switched networks that won't forward UDP
Finally I need a solution that will work without maintenance on a minimal Windows network (XP / 2000 / Vista) that probably doesn't have Active Directory or other lookup services configured.
I don't want to tag on any runtime stuff for this - should be able to do it with plain VC++ or Delphi.
What approaches do commercial apps usually take? I know that SQL Server uses a combination of broadcast and NetBEUI calls (I may be wrong about this).
Thanks in advance.
You have a few terminology issues:
Where you say "network segment" you appear to mean "IP subnet". Devices on the same network segment can see the same IP broadcasts.
Where you say "hub/switch" you appear mean "IP router".
Where you say "won't forward UDP", the problem is actually "won't forward IP broadcasts".
Once we get past that, you have a few options:
Your servers could register themselves under a well-known name in DNS, if you have a DNS server that allows dynamic DNS updates. You should probably use a SRV record as specified in RFC2782. The clients then do a DNS lookup to find the server(s).
You could statically assign your server(s) well-known names in the organisation's DNS, perhaps with a SRV record as with the previous option.
Your servers could join an IP multicast group, if your routers support IP multicast. The clients then send their initial discovery request as a UDP packet to the (pre-ordained) multicast address.
If you have domain server, I would go with small service on it. You can connect with other services to it and use it as distribution point.
Why domain server? It is relatively easy to find it's name (DsGetDcName).
Other choices would include DHCP server, DNS server or something of that kind that needs to be filled by maintenance staff anyhow.