Socket Pools?

  • Thread starter Thread starter Jacob
  • Start date Start date
J

Jacob

Is there any tutorials or documentation that you could point me towards
regarding pooling requests for a limited number of sockets?

I want users of this class to be able to request a socket and if one isn't
available, their request will be queued and a socket returned when it is
available. Consequently, if a socket is no longer in use, how to return it
to the pool. This is all in an attempt to not make so many connections to a
particular port, but use one if it has already been established.

Does anybody know what I'm talking about?

Any help is appreciated.

Thanks,
Jacob
 
I would have a look at threading to control the sockets.
Get the users to use a UDP Port to request a Connection, when this
connection is successful send back a UDP Message withthe connection detail
for a TCP Port to connect to (Also Send a Hash value say the IP Address and
port as well as some secret Code, to be used to verify that the incomming
connection is allowed to connect at this time)
 
Almost but not really. You talkin about clients sending requests or a
server that listens for incomming socket connections?
 
Clients sending requests....

Just looking for a really smart way to manage the requests/sockets. (If the
analogy helps, think of it like a SQL connection pool, but for sockets).

Thanks,
Jacob
 
Thanks for the link... a good refresher on .Net sockets, but nothing new,...
or more importantly, nothing to help me in the direction I'm going. Perhaps
I'm not explaining it well. Let me put it in an example.

Say I'm connecting to an HTTP server on port 80. The server allows me a
maximum of two connections, but I have a rich client that could want to
interrupt any of the current connections, use them, and then return them to
what they were doing already. The easy way would be to terminate connections
and connect on each request, but I'm trying to improve efficiency by
creating a socket abstraction layer so that when I pass a connection to
something else, it will think that a connection was just made when in
reality, it's an already established connection. And consequently, when
whatever is using that connection calls Close, it will actually just go back
to the pool.

Any help would be appreciated.

Thanks,
Jacob
 
Have two initial swags at this (if I understand your requirements)
1) Create a pool object. This object will contain two (or more) connection
objects that abstract a socket and they will keep their socket open. Use a
semaphore with a count of 2 to protect the number of owning connection
objects that can be out at any one time. More requests will just block
until someone that owns a connection object closes it. When closed, the
connection object will release 1 semaphore to add it back to the pool.

2) Abstract connection at a higher level. Have one connection object and a
C-queue that client object can put requests into. The connection object
then just services the queue and you figure out who to send reply back to -
maybe another reply queue for each client.
 
Your first suggestion is the conclusion that I came to also. Talking it out
has really helped me to figure out what I need to do. Also these resources
I found regarding SQL connection pools have really helped:
http://msdn.microsoft.com/library/d...nectionpoolingforsqlservernetdataprovider.asp
http://cvs.hispalinux.es/cgi-bin/cv...SqlClient/SqlConnection.cs?cvsroot=mono&rev=1

I think I have a pretty good handle on it. You've been very helpful.

One more thing, regarding the blocking of a connection request until one
becomes available... that's the best idea I can come up with too. Any other
suggestions on how I might handle that? Maybe returning a result indicating
it's not available?, maybe throwing an exception? or maybe some sort of
callback notifying when it is available? ... any last thoughts would be
appreciated.

Thanks,
Jacob
 
Depends how you invoke it (another thread, UI, etc) You could block on a
monitor or semaphore, mutex, etc. or start a thread pool thread worker that
will block on it until next one is free - that way you can let the monitor
scheduler handle fifo queue.
 
Back
Top