On 15-jul-2005, at 18:11, Ned Freed wrote:
> The specific case I've seen is with IMAP4. IMAP4 has the > characteristic that you often have a huge number of incoming > connections, only > a few of which are active at any given time.
I know what you mean, I've seen my Mac generate more than a dozen simultaneous IMAP sessions on occasion. However, are you saying that ONE client would use more than 64k IMAP sessions?
I'm saying that one source system can generate more than 64K IMAP4 sessions. These are systems running various sorts of proxies, so they are in effect hosting many clients at once.
That would be inefficient, to say the least.
It would be if it was a single client, I guess. But it isn't.
Also, since the clients don't tend to coordinate their port use, it's common for servers to see lots of sessions where both the destination port (duh, that's the well known one) and the source port are the same. (When people connect to the IMAP server after booting their source port is one of the first dozen or so that their OS uses.) Since the server address is also fixed under normal circumstances, the source address is a key ingredient in the demultiplexing. Fortunately, there are enough of those for this purpose, even in IPv4.
> But that doesn't mean nobody is hitting the 65536 limit imposed by > source port > numbers. They are, it causes problems, and this needs to be kept in > mind.
If they are, they're probably using some kind of proxy or NAT setup, for instance, having SSL sessions decrypted and then forwarded to the actual server port, making all the sessions seem to come from the same address.
Exactly. SSL hardware is certainly one reason for such setups. Others include webmail, content filters, content transformers, auditing/monitoring, and IMAP4 before SMTP coordination. I actually don't recall a case where NAT was conflated into all this, but that may well be due to my not having asked the right questions at the right time. Ned _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf