Thanks for all the feedback, André, Christopher, and John. Let me see if I can quickly answer everyone's comments.
Since there is a TCB for each connection, and the OS knows which TCBs are associated with which processes, I don't see any problem using the same local port on different sockets. When a packet arrives from a remote server, the stack looks at the full socket details, checks for a matching TCB, and routes the packet to the appropriate process. There's no confusion (except when using tools that don't show process names, like netstat without -p). Using > 64K local source ports seems like a useful capability in high-load environments where tomcat is doing a lot of back-end access (i.e., where JSPs and class files frequently call back-end services). With hashing and indexing, having giant connection tables does not seem like an unrealistic amount of processing load to me. Linux-based stateful firewalls have to keep track of a lot more connections than that, with rule processing and even layer-7 inspection at the same time, on relatively low-powered hardware. FYI, I don't have 1800 tomcat instances on one server. I have about 100 instances on each of 18 servers. That said, I agree that the real focus should probably be on the JDBC driver. I asked the question here because it seemed like a good place to start. Any ideas where I could go to chat with JDBC developers? --Eric > -----Original Message----- > From: Christopher Schultz <ch...@christopherschultz.net> > Sent: Friday, March 27, 2020 1:42 PM > To: users@tomcat.apache.org > Subject: Re: Does Tomcat/Java get around the problem of 64K maximum > client source ports? > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > André, > > On 3/27/20 11:01, André Warnier (tomcat/perl) wrote: > > On 27.03.2020 14:27, André Warnier (tomcat/perl) wrote: > >> On 26.03.2020 20:42, Eric Robinson wrote: > >>>> -----Original Message----- From: Olaf Kock <tom...@olafkock.de> > >>>> Sent: Thursday, March 26, 2020 2:06 PM > >>>> To: users@tomcat.apache.org Subject: Re: Does Tomcat/Java get > >>>> around the problem of 64K maximum client source ports? > >>>> > >>>> Hi Eric, > >>>> > >>>> On 26.03.20 18:58, Eric Robinson wrote: > >>>>> Greetings, > >>>>> > >>>>> Many people say the maximum number of client ports is 64K. > >>>>> However, > >>>> TCP connections only require unique sockets, which are defined > >>>> as... > >>>>> > >>>>> local_IP:local_port -> remote_ip:remote_port > >>>>> > >>>>> Theoretically, it is possible for a client process to keep using > >>>>> the same local > >>>> source port, as long as the connections are to a unique > >>>> destinations. For example on a local machine, the following > >>>> connections should be possible... > >>>>> > >>>>> 192.168.5.100:1400 -> 192.168.5.200:3306 192.168.5.100:1400 > >>>>> -> 192.168.5.201:3306 192.168.5.100:1400 -> > >>>>> 192.168.5.202:3306 192.168.5.100:1400 -> > >>>>> 192.168.5.203:3306 > >>>>> > >>>>> I've seen this demonstrated successfully here: > >>>>> > >>>>> https://serverfault.com/questions/326819/does-the-tcp-source-port- > have > >>>>> > >>>>> > - -to-be-unique-per-host > >>>>> > >>>>> As someone on that page pointed out, while it is possible, it does > >>>>> not > >>>> commonly occur in practice "because most TCP APIs don't provide a > >>>> way to create more than one connection with the same source port, > >>>> unless they have different source IP addresses." This leads to the > >>>> 64K maximum client port range, but it is really a limitation of the > >>>> APIs, not TCP. > >>>>> > >>>>> So how does tomcat handle things? Is it limited to a maximum 64K > >>>>> client > >>>> source ports, or is it 64K per destination, as it should be? > >>>> > >>>> To be honest, I can't remember to have seen a web- or application > >>>> server that accepts 64K concurrent connections at all, let alone to > >>>> a single client. > >>>> > >>>> I can't come up with any reason to do so, I'd assume that there's a > >>>> DOS attack if I get 100 concurrent incoming connections from a > >>>> single IP, and a programming error if the server sets up more than > >>>> 1K outgoing connections > >>>> > >>>> Maybe I'm missing the obvious, or have only administered > >>>> meaningless installations, but I fail to see the real world > >>>> relevance of this question. > >>>> > >>>> > >>> > >>> I don't blame you for being puzzled, but this not about tomcat > >>> accepting connections. It's about tomcat acting as the client, where > >>> MySQL is the server. I'm referring to client connections from tomcat > >>> to MySQL. We have about 1800 instances of tomcat running. This > >>> question comes up once in a while when tomcat can't connect to > >>> MySQL. Trust me, it can be an issue. > >>> > >>> --Eric > >>> > >> > >> The question is : is there even any Java API (method) (or even OS > >> API) which allows a client to open a (client, non-LISTEN) socket AND > >> specify the client IP address and/or port ? > >> > >> I mean, if there is none, then the question may be interesting in the > >> absolute, but ultimately pointless. > >> > >> I believe that the IP address of client packets, will be determined > >> by which /route/ the OS determines that the target server address can > >> be reached (which will determine through which network interface the > >> packets "go out", which will determine the sender IP address inserted > >> in the packets). I don't think that the application-level software > >> (here a java webapp) can determine this in advance. And the client > >> port will be decided by the OS-level TCP stack, in function of which > >> ones are not yet in use (which a java webapp can also not determine > >> in advance). > >> > >> Example of creating a client socket : Socket echoSocket = new > >> Socket(hostName, portNumber); The hostname (or IP address of > >> ditto) and port numbers passed as arguments, are the IP:port of the > >> server you are connecting /to/, not the ones of the local socket. > >> > > > > Addendum : > > > > https://stackoverflow.com/questions/11129212/tcp-can-two-different-soc > kets-share-a-port/11129641 > > > > > > > > From which I gather that, although it may be possible (in some > > languages or using some API) to open several client connections (to > > different target IP/port) using the same local port number, you may > > still have other issues when doing this : - the host's TCP/IP stack > > has to keep track of all the simultaneous connections, and if the list > > gets very large, this may become very resource-intensive > > Those resources must be available, used or not. You can't have a TCP/IP stack > which is documented to support 64k connections but only actually supports > 32k or 16k. > > Also, 64k entries in a connection table isn't large. It can even be indexed > in a > way that makes it *very* fast to look them up, either by hash or even just > port-number(s). Your are more likely to be using-up your computer's > resources moving bulk data around than just trying to manage the > connections moving that data. > > > - there may be a limit at the OS level, to how many sockets are > > allowed at the same time > > Yep, 64k. There may be some kind of "reserved" pool that the OS wants to > maintain and e.g. refuse to allow services to listen to local ports jut in > case > clients need to be able to spin-up. That would be a little weird, but I'm no > networking expert. > > > - to each connection, corresponds some kind of a "file descriptor". > > There may be limits, at the process level (in this case the JVM > > running tomcat), or even at the host level, to how many of those may > > be in use at any one time (So if you were running on a host one JVM > > for a tomcat instance, it would compete with other processes running > > on the same host and also using file > > descriptors) > > Yes. 1800 Tomcat instances on a single server seems... high to me. > > > It seems also thus possible that the reason why you are running > > against a problem not being able to make additional connections to a > > MySql server, is not necessarily the usage of all 64K port numbers, > > but one of the other limitations above. > > Or even the server refusing to allow that many connections. We have limits > on our database for the total number of active connections mostly to protect > the database from some kind of application bug/attack/etc. There just > should be no more than X non-admin connections established to the > database because otherwise even simple queries (in huge numbers) could > bring it down. > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5+SQ0ACgkQHPApP > 6U8 > pFgVcQ//XvoaW7ydljiOT6AjWD0ErMkU9XoR+VtpIRp22oknw1DnMO/l8kiDRX > 7O > I5Tv/3Z8PJ4GFfEc6uZBrb7/jNqnZqN9KW3y9mY/bAr3kZN4ig5TolciBg4YL9Vw > H+7UaRu8vPH4lg9mvKriQRSf09TvSq5VnjRhjQfC7K0tHKR7WG7s1zBXF5QMXy > f/ > jfZLFDMD904CW2pbvFuyF3T2u+aIqIbSCoQeBY57Vlnj5AJMQstmxVn300h9N3 > Vi > Bp5CmRIy5eF/2bHWZoWDkAtjrSU6dIKQ4kGqJS8TE6ecQLFQFMl+Cc5wO+xG > PfiZ > 9ANCMBUpFu/5T5dY1+72j38QgW6J/6VBDrCnTHljj+e0iknQCNqcLdUoQsIE6u > DN > UGVqIot8A6IMImzt3U79AOt7pX/J0QJYJyq7oqfouSyX3zGz74pzbJOEmLnPTXI > F > pkkaByHQgzMfHsU5ZG03UboajkWLuR+3VYexmv9lMAZ5TgMQMeoyde3VrIP > rPE2W > XQiblcR16Q6bNIWN5XGj05a+l7uBiCMwUExus/v8jqLPmuaAAzt5EoS7CakQYW > mt > kMKQJQuh1gUdAngkyb74f0zrZBc1fUwFN+Ihm8bmziPEtzy/sQtITK8KcchhfM > bH > RL7yiJi1KkwegzyrinhudzdPuVlL1nXY5/lJET5FUJ8cs3y0gHQ= > =4Sf6 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > 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.
