> -----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. > Olaf > > > >> -----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.
