Closing an open socket from another program

Hi All - I have written a socket server as a service in VB.Net2.  Configuration is by registry settings entered with seperate config program.  I want to be able to close certain socket connections that have been created by the service, from an external program, in this case the config program.  I have tried creating a socket with the IPEndpoint of a previously created socket, and then tried closing it but get the error 'Only one usage of each socket address'.   So its obviously trying to create a new socket, not access the first one. Any herlp would be appreciated.
Dim ipAddr As System.Net.IPAddress
Dim ipEndPoint As System.Net.IPEndPoint
Dim socketAddr As System.Net.SocketAddress
Dim MySocket As System.Net.Sockets.Socket
 
ipAddr = IPAddress.Parse("127.0.0.1")
ipEndPoint = New System.Net.IPEndPoint(ipAddr, 1234)  'the socket I want to close
socketAddr = ipEndPoint.Serialize()
MySocket = New Socket(ipEndPoint.AddressFamily, SocketType.Stream, ProtocolType.Tcp)
MySocket.Bind(ipEndPoint)
MySocket.Close()

Open in new window

LVL 2
PNRTAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

VoloxCommented:
One solution would be to host remoting calls within your service that allow a caller to control the sockets of the service.  Then your configuration program can make a remoting call to achieve closing a socket.
I don't know whether there is really a way to gracefully close a socket that is owned by a different process, but even if there is, I would consider this 'poor form' because the 'owner' of the socket wouldn't have any idea of why the socket got pulled out from underneath it.  The remoting approach I provide above would allow the 'owner' to remain in control of the socket and know why the socket is getting closed.
PNRTAuthor Commented:
Hi - I'm afraid you lost me on 'host remoting calls'.  Could you explain that a bit perhaps with an example.

Also, I should have explained, the reason I need to close the socket would be for connections that have 'hung' or that the server has not had comms with for a given period.    I originally wrote this into a program that worked well and allowed me to control the sockets by keeping track of them in a hashtable.  But there are very high numbers of connections - sometimes about 10 a second - so I needed to make it faster, hence the service.  I've tried to make the service process as little as possible, hence the need for some control outside of the service.  I hope this explains a little clearer.
VoloxCommented:
Providing an example for .Net remoting would take up too much space here.  Instead, try checking out this primer...  http://www.codeproject.com/KB/IP/Net_Remoting.aspx
Essentially your service would be able to be remotely controlled by another process (your configuration application).

If the only problem you are trying to solve for is hung connections, then why don't you create a thread within your service that watches for hung connections and kills them automatically.  Generally you would want this type of recovery functionality to be self contained within the service; otherwise the hung socket stick around until someone fires up the configuration application.
PNRTAuthor Commented:
Thank you very much for your suggestions, I've looked at remoting and I think I could acheive similar results with the servicecontroller class, but I was particularly interested, as I indicated, in a manual process of closing the sockets externally. There are a number of reasons why the process should not be automated and the program TCPView has exactly the functionality in regards to the socket control, that I was looking to duplicate.
VoloxCommented:
Given that TCPView is part of sysinternals, chances are that to duplicate it's functionality will require cracking open some system APIs.  Closing another processes socket isn't the type of thing the .Net frameworks are typically going to provide functionality for.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Programming

From novice to tech pro — start learning today.