Eric,
On 6/25/21 22:09, Eric Robinson wrote:
-----Original Message-----
From: Olaf Kock <tom...@olafkock.de>
Sent: Friday, June 25, 2021 8:07 AM
To: users@tomcat.apache.org
Subject: Re: Re-Use TCP Source Ports if the Socket is Unique?
On 25.06.21 14:46, Eric Robinson wrote:
Olaf and Scott --
Thanks to both of you for your comments. I may have asked my question
poorly, since what you both described is the way I understand TCP to work.
There is no correlation between an incoming connection to tomcat and its
outgoing connection to a database backend, nor would I expect there to be.
Perhaps a simpler way to ask my question is: when a server has multiple
IPs, which one does tomcat use as its source IP when it initiates a three-way
handshake with a remote machine?
For example, suppose my server has IP addresses 10.0.0.1 and 10.0.0.2, and
my tomcat connector looks like this...
<Connector
port="8080"
protocol="HTTP/1.1"
address="10.0.0.2"
connectionTimeout="20000"
redirectPort="8443"
/>
Tomcat is now listening on IP 10.0.0.2.
But here's the question. If tomcat needs to initiate a TCP session to a
remote machine (acting as a TCP client), will it use 10.0.0.1 or 10.0.0.2 as the
source IP of the outbound connection? I'm assuming it will use the same IP
that the connector is configured to listen on.
Hi Eric,
again: There's no correlation. Your question boils down to a context-free
"which source IP does tomcat use for outgoing connections?". In fact, Tomcat
doesn't use any. It just asks the runtime environment (ultimately I'd expect
the OS) for a connection to a particular destination, then it uses that.
How the connection is then established will depend on
* available network adapters
* best route to the target address
* OS or network configuration
It will /not/ depend on any of Tomcat's Connector-configurations
whatsoever
Got it. Then, given a tomcat server with one NIC and two IP addresses, 10.0.0.2
and 10.0.0.3, when tomcat connects to a server on the same subnet at 10.0.0.50,
what logic does the OS use to select the source IP, all else being equal?
Obviously neither IP has a routing advantage.
You are confusing NIC and interface. A NIC is a piece of hardware, while
an interface is a software concept. Often, they are 1:1 so you have 1
NIC and 1 interface. But if you have two interfaces, they must have
something which differentiates them, or the network configuration will
be ... insane.
I'm sure it's possible to get a pair of network interfaces configured
with both of them on the same network segment, but the IP stack will
surely have rules for deciding which interface is used for the (client)
socket by default if you don't specify one.
But those rules are beyond Tomcat, beyond the JVM, and rest with the OS
itself. So the answer is "it depends" and "if you care, you should
specify which one you want."
-chris
-----Original Message-----
From: Olaf Kock <tom...@olafkock.de>
Sent: Friday, June 25, 2021 3:01 AM
To: users@tomcat.apache.org
Subject: Re: Re-Use TCP Source Ports if the Socket is Unique?
On 25.06.21 05:19, Eric Robinson wrote:
Thanks for the feedback, Daniel.
I guess the answer depends on whether the socket libraries use the
tomcat
listening port as the source IP. If you have three tomcat instances
listening on three different IPs, each instance should be able to
open a client connection using the same source port, as long as each
tomcat uses its listening IP as the source IP of the socket.
That's the part I'm still not sure about.
My expectation is that database connections do not have any
correlation with the listening port: Technically, DB connection pools
can be shared across all contained Hosts and Connectors /within a
single tomcat/, and when multiple processes are added to the game, it
doesn't really change anything.
In fact, it's not uncommon that there's a public facing network
adapter, where a http-connector listens, but a completely different
network adapter for any backend communication - e.g. to the database.
All that I expect a database driver to do is to specify where it
wants to connect to, and the OS figures out how that connection needs to
be routed.
That's utterly independent of any http connection that comes in to
the same process.
So: Don't expect any correlation, and you're safe.
(Note: There /may/ be ways to configure a db-driver to specify a
source address, but I'd expect that rather to add a potential failure
rather than anything that I'd want to control. If you interpret such a
situation differently:
Please elaborate)
Best,
Olaf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Disclaimer : This email and any files transmitted with it are confidential and
intended solely for intended recipients. If you are not the named addressee
you should not disseminate, distribute, copy or alter this email. Any views or
opinions presented in this email are solely those of the author and might not
represent those of Physician Select Management. Warning: Although
Physician Select Management has taken reasonable precautions to ensure
no viruses are present in this email, the company cannot accept responsibility
for any loss or damage arising from the use of this email or attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Disclaimer : This email and any files transmitted with it are confidential and
intended solely for intended recipients. If you are not the named addressee you
should not disseminate, distribute, copy or alter this email. Any views or
opinions presented in this email are solely those of the author and might not
represent those of Physician Select Management. Warning: Although Physician
Select Management has taken reasonable precautions to ensure no viruses are
present in this email, the company cannot accept responsibility for any loss or
damage arising from the use of this email or attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
