-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Eric,
On 3/27/20 16:39, Eric Robinson wrote: > 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. The likelihood that you end up with more than one connection with identical source addr:port + dest addr+port is quite high in this situation. You have to be VERY careful that you don't overlap or you'll find that you have mass chaos on your hands. > FYI, I don't have 1800 tomcat instances on one server. I have > about 100 instances on each of 18 servers. So is this just of academic interest to you, then? 100 client connections per host doesn't seem like you have a problem to solve. > 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? MySQL is open-source. They have forums, mailing lists, a public bug-tracker, etc. You can also download the source and read through it to find out how things are being done. - -chris >> -----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? >> > 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-po rt- > >>>>>>>> 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 >> >> --------------------------------------------------------------------- >> >> 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 > -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6CF3sACgkQHPApP6U8 pFhE+g//R260qFNgtxhrnM1ABP4RAQJmwevHwG73Ydz+LExd30sJSTqr7WKVzJMk eiztsWGs/tu8brsjzsw8fABnTgTRAjUtTMv8a6kejwXTdm+zF2mIgKZtu0NRsP5b Rvoj5tByh5t6VM722xrulxiNgJgKVBvowyTUEp52SYykDhVCsYS+r8rfwLS0tZnr IWH67eZE/ssStTAIACCtamUtk9OadCh86lSUz2wzY2q0i31672Ym/7vEBH/LCdFm KMsUS8Qu6cZ3CDi0IEWmYwF5vH6izEhETZrR5THTBTmEkspVQnMcN1edOlrOsu2s zNYDZwYpfA7yDmntsGQjZfleXjIV12FKrqTETP+FqfzuGw4pLaMVHC+IFOTDMxGH 9aKYzubCF5H0r2nBs7SZjT3DRdeEgxBPDYR6ndiA+34KF0ZtmwHLGxI2kW0+4xHO WEOZbkUg2CnKrg4sSCZeyPgLbGGnpOxcAe0XBdnphQTwu8rrBXSkDXXFZbRGoHdE DNBNfV2tLNqMclEkbSlQqME5TyLxAEOBH4Tx3B7m8FvfSQTh5UCKS3lsnb+0Ju1Y v7EpJl/yOXOBPIFTo0+NpLaotAyUoPEC4BNDSBeEPRleDCIlW1DDc6/N0tvkhHM9 GTV6VGtZXEGb44GmBi7WOBg37Xm9Sav1D1uTd7T8szBEGelbjG4= =7FhJ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
