- Connections to the clients.
- Connections to peers.
- Connections to other (dependent) services.
Now, I can easily argue the first set isn't a "pool" in the traditional sense, but it is a collection of connections that must be managed in some fashion. The second one is normally used for replication or synchronization. And the last one is the one we normally make connection pools for -- typically for database connections.
Take a database server for example. Knowing your clients will be intentionally keeping long running connections, it makes sense to pre-allocate resources for connections or keep the connections open and idle. The only real difference on the two sides is who initiated the connection. Keep-alive, long polling, and server sent events, the client as a connection pool starts to make a lot more sense.
That leaves the peers. I like to think of peers as essentially client AND server initiated connection pools. They require solutions on both sides, as some peer will connect to them, and they, in term, will connect to some other peer.
Right now, I am looking at the logjammin' code, neglected for a year, and questioning why I treat all three pools distinctly different? The Connections to clients is handled through the normal listen. The connection to the peers is handled in a different thread. And the dependent connections aren't implemented at all.
I have another trip to Dulles this weekend, and I want to play around with creating a pool of connections concept to replace the "Server" concept I have built right now. Something like each Logjammin' instance is a collection of 1 or more connection pools which deal with resource management, and initiating a configurable series of stages or events.
Update 10/10/2014: It took a while, but finally pushed it.
Update 10/10/2014: It took a while, but finally pushed it.