Hi Salim,

If you need to support thousands of users (incoming connections) and your
applications opens many further connections (outgoing) for each incoming
connection, then you could quite easily run out of sockets especially if the
connections you make take a second of more to complete. TCP protocol uses a
16-bit port number, so you can have no more than about 65500 connections
open at any given time.

However, that should be plenty for most applications. If you need to support
thousands of users, then there are three things I can suggest (not in any
special order):

1. Conserve the sockets for example with a pool, or, make the use of your
outgoing sockets sequential instead of firing all queries at once.

2. Make the outgoing connections faster or eliminate them altogether for
example with a cache, or by improving performance on the other end-point.

3. If the above won't work or can't be easily done, then load balance the
queries into one or more server(s). There are appliances available that can
show a single IP address to the outside world, but still maintain a farm of
servers behind it. If you are having thousands of users, I believe the costs
for an additional server + the said appliance are easily justified. I'd
estimate they could be in the range of $5,000-$10,000.

Hope this gives food for thought. There's only so much software alone can
do.

If you're bumping into these limits, you're going to need multiple IP
Addresses.Recycling of ports is something that can happen, but in boundry
cases - where it may take several minutes for the O/S to close a TCP
connection - you could still exhaust things.

We we did our big scalability tests, we had 4 network cards, each with 10 IP
Addresses bound to them. For incoming connections, we relied on basic
client-side DNS randomization. That is, we assigned 10 IP Addresses to
"host1", 10 to "host2' , 10 to "host3", etc. When the client picks an IP for
"host1", it's supposed to randomize which of the 10 addresses it uses. All
the standard DNS lookup tools will take care of this.

Now, for LDAP queries using .Net API's, if you're opening and closing
sockets that frequently, you've got bigger problems. You really should build
some sort of LDAP Connection Pool, which allows you to re-use LDAP
connections. You don't want to setup and tear-down an LDAP connection for
each query. Given the load this introduces, it's a big scalability hit.