Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

how to stop the socket.connect() function if it stucks?

threads

  • Please log in to reply
3 replies to this topic

#1 henryyao

henryyao

    Member

  • Members
  • PipPip
  • 19 posts

Posted 31 January 2013 - 09:57 PM

I'm facing a problem of stop the socket.connect() function. Sometimes the physical link between my local machine and the remote machine might be good, but due to some reason, the remote endpoint cannot be accessed, maybe a firewall or the port on the remote machine is closed. In such cases, the socket.connection() function will be stuck there and waits for an infinite long time...Even the firewall is disabled later, the function will still stuck there forever.

So I tried to find a way to stop the socket.connect() when faces the above situations.

The thing is I'm using a .net micro framework in which I dont have timeout mechanism or task or socket.beginconnect();

I'm trying making the socket.connect() itself a thread and tried to abort() it after 2 seconds if (!thread.join(2000)). However, I dont quite understand the abort() function and i've heard its an unwise way to do so and it does not work afterall.

Also I'd like the socket keep trying until it succeed in connecting.

Now i dont know what to do about it? can anyone help? thx a lot. it's a netduino plus board

main function {

remoteEndPoint = new IPEndPoint(IPAddress.Parse(IP_add), 30000);

while (true){ m_socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);//Set up socket m_socket.Connect(remoteEndPoint); myThread.Start(); if (!myThread.Join(2000)) { Debug.Print(myThread.ThreadState.ToString()); myThread.abort();

m_socket.close(); }

else

{break;} } } private static void socket_connect() { m_socket.Connect(remoteEndPoint);//Connect to remote device }

 

 

I'm also have the following code by creating a new thread each time.

 

 

while (true) { try { m_socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);//reset up socket myThread = new System.Threading.Thread(new System.Threading.ThreadStart(socket_connect)); myThread.Start(); if (!myThread.Join(2000)) { throw new SocketException(SocketError.AccessDenied); } } catch (Exception ex) {

m_socket.Close();

Debug.GC(true); } } } private static void socket_connect() { m_socket.Connect(remoteEndPoint);//Connect to remote device }

 

The above code will allow the GC to deal with the useless threads instead of using abort(). This code will run like 10 mins before it stops running anymore. And I've checked the memory, it still have more than 45M. Can anyone tell me why this happens?



#2 HiredMind

HiredMind

    Member

  • Members
  • PipPip
  • 25 posts

Posted 31 January 2013 - 11:25 PM

Maybe you could use an event wait handle to do the same thing as Thread.Join(), something like this:

    public class Connector	{		private IPEndPoint _remoteEndPoint;		private AutoResetEvent _waitForConnection;		Socket _socket;		public Socket ConnectTo(byte[] ipAddress, int port)		{			_remoteEndPoint = new IPEndPoint(new IPAddress(ipAddress), port);			_socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);			while (true)			{				_waitForConnection = new AutoResetEvent(false);				var connectorThread = new Thread(WaitForConnection);				connectorThread.Start();				if (!_waitForConnection.WaitOne(2000, false))				{					connectorThread.Abort();					_socket = null;				}				return _socket;			}		}		public void WaitForConnection()		{			_socket.Connect(_remoteEndPoint);			_waitForConnection.Set();		}	}

 

What makes Thread.Abort() dangerous is that you don't get the chance to clean up anything you've done inside the Thread.  Threads are usually used for long-running operations and so normally you need to clean up any resources you've allocated.  But that's not the case here - you're using a thread simply as a timeout mechanism.  If you make sure to keep the thread code as simple as possible, and you never need to clean up anything, then you should be fine. 

 

Worst case scenario here is that a connection is established between _waitForConnection.WaitOne() and _waitForConnection.Set(), so we have a connected socket that we think is unconnected.  But the socket will be disposed of anyway, so I don't think that will cause problems.



#3 henryyao

henryyao

    Member

  • Members
  • PipPip
  • 19 posts

Posted 01 February 2013 - 06:36 PM

Maybe you could use an event wait handle to do the same thing as Thread.Join(), something like this:

    public class Connector	{		private IPEndPoint _remoteEndPoint;		private AutoResetEvent _waitForConnection;		Socket _socket;		public Socket ConnectTo(byte[] ipAddress, int port)		{			_remoteEndPoint = new IPEndPoint(new IPAddress(ipAddress), port);			_socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);			while (true)			{				_waitForConnection = new AutoResetEvent(false);				var connectorThread = new Thread(WaitForConnection);				connectorThread.Start();				if (!_waitForConnection.WaitOne(2000, false))				{					connectorThread.Abort();					_socket = null;				}				return _socket;			}		}		public void WaitForConnection()		{			_socket.Connect(_remoteEndPoint);			_waitForConnection.Set();		}	}

 

What makes Thread.Abort() dangerous is that you don't get the chance to clean up anything you've done inside the Thread.  Threads are usually used for long-running operations and so normally you need to clean up any resources you've allocated.  But that's not the case here - you're using a thread simply as a timeout mechanism.  If you make sure to keep the thread code as simple as possible, and you never need to clean up anything, then you should be fine. 

 

Worst case scenario here is that a connection is established between _waitForConnection.WaitOne() and _waitForConnection.Set(), so we have a connected socket that we think is unconnected.  But the socket will be disposed of anyway, so I don't think that will cause problems.

 

I see what you mean. Thanks for the explanation on abort().

And is there a difference between join() and autoresetevent in this situation?



#4 HiredMind

HiredMind

    Member

  • Members
  • PipPip
  • 25 posts

Posted 01 February 2013 - 07:19 PM

I see what you mean. Thanks for the explanation on abort().

And is there a difference between join() and autoresetevent in this situation?

 

We're using to different types of classes to accomplish the same goal, but I can't think of any non-trivial differences in the two techniques.







Also tagged with one or more of these keywords: threads

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.