> -----Original Message----- > From: Christopher Schultz <ch...@christopherschultz.net> > Sent: Friday, June 25, 2021 11:33 AM > To: users@tomcat.apache.org > Subject: Re: Re-Use TCP Source Ports if the Socket is Unique? > > Eric, > > On 6/24/21 21:14, Eric Robinson wrote: > > I guess I may have answered this question for myself. At least I can > > simulate it with ncat. Note that I have two ncat sessions open to the > > same remote server using the same source port, but with different > > source IPs. > > > > [root@testserver ~]# netstat -antp|grep ncat > > tcp 0 0 192.168.11.215:3456 192.168.10.59:9000 > > ESTABLISHED > 60946/ncat > > tcp 0 0 192.168.10.58:3456 192.168.10.59:9000 > > ESTABLISHED > 60920/ncat > > > What is the command-line you used to invoke those nc processes? > Presumably, you had to specifically tell each process which source interface > to use.
Yes, as follows. I forced each ncat to use a specific source IP and source port. # ncat -s 192.168.10.58 -p 3456 remoteserver 9000 # ncat -s 192.168.11.215 -p 3456 remoteserver 9000 > > I haven't done this myself, but my guess would be that every outgoing > connection would use the default network interface appropriate for that > type of communication. > > The IP/interface Tomcat uses to bind and listen for connections has no > bearing on which interface is chosen for outbound connections. > Gotcha. So I need to find a way to force all connections from a tomcat instance to remote IP "X" to always use source IP "Y." That's my challenge. > > Is there any reason why tomcat should not be expected to work the same > > way? And when I say tomcat, I really mean libraries like the mysql > odbc > connector that tomcat uses. > > Oh, you're using Connector/J? Then you want this setting: > > localSocketAddress > > https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-connp-props- > connection-authentication.html > > -chris > Om my goodness. You, sir, are my ever-livin' hero. That WORKED. I tested it, and now my tomcat instances connect to the database server using whatever local IP I specify in the localSocketAddress property. I am a happy man. -Eric > >> -----Original Message----- > >> From: Eric Robinson <eric.robin...@psmnv.com> > >> Sent: Thursday, June 24, 2021 3:19 PM > >> To: Tomcat Users List <users@tomcat.apache.org> > >> Subject: Re-Use TCP Source Ports if the Socket is Unique? > >> > >> Two quick questions. > >> > >> Question 1: > >> > >> When tomcat creates a TCP connection to a remote server (for example, > >> a back-end database) tomcat is acting as the TCP client in that case. > >> Does it use the IP it is listening on as the source IP for its outbound > >> client > connection? > >> > >> For example, Server1 has three IPs: 10.0.0.1 (primary), and two > >> additional IPs, 10.0.0.2 and 10.0.0.3. Tomcat is listening on > >> 10.0.0.2. It receives a request that requires it to connect to a > >> database server. When it creates a TCP connection the database server, > which IP does it use as the source address? > >> > >> Question 2: > >> > >> Suppose you have two instances of tomcat on the same server. TomcatA > >> is listening on 10.0.0.2 and TomcatB on 10.0.0.3. First, TomcatA > >> establishes a connection to a remote server from its source IP 10.0.0.2, > source port 3456. > >> Can TomcatB, which is listening on a different IP, also establish a > >> connection to the remote database server using the same source port > >> 3456, given that the sockets is unique (different source IP)? > >> > >> -Eric > >> > >> > >> > >> > >> > >> > >> 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. > > 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
