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

Hang on socket connect

socket NP2 hang

  • Please log in to reply
10 replies to this topic

#1 Duefectu

Duefectu

    Advanced Member

  • Members
  • PipPipPip
  • 34 posts

Posted 06 November 2013 - 01:16 PM

Hello:

 

I have several (12) NP2 with 4.2.2 firmware.

 

I use an IP socket to request the time to a server. Simply send "DATETIME" and it returns the time.

 

When I use socket.connect, and the server is down, the program hangs. No exception and no continue.

 

This is the simple code:

var ipB=new byte[]{ 192, 168, 0, 100 }var ep = new IPEndPoint(new IPAddress(ipB), 4000);Debug.Print("Connecting...");soc.Connect(ep);Debug.print("Connected!");

The console shows "Connecting...", but never "Connected!" or exception is the server/service is down.

 

To avoid hang of the NP2, I run this code in a new Thread. The application still running, but never continues to "Connected!", and the application hangs after time (minutes/hours).

 

Curiosity: If I abort the socket thread, I receive an IO exception when try to write to the SD card and when try to Access to IO ports.

 

Any suggestion?

 

Thanks for your time!



#2 SteveS123

SteveS123

    Member

  • Members
  • PipPip
  • 21 posts
  • LocationMissouri

Posted 31 March 2014 - 04:14 PM

I have the same problem.  Did you ever figure out a solution?  I also have seven ND+2's and they all hang when I try to do a socket.connect to a device that isn't connected to the network. The only way I am able to get out of the hang is to power cycle the device.  I also leave the ND's powered up over night and at least three of the seven will not be pingable in the morning.



#3 jrlyman3

jrlyman3

    Advanced Member

  • Members
  • PipPipPip
  • 67 posts
  • LocationNorth St Paul. MN

Posted 01 April 2014 - 02:47 AM

After you create the socket you need to set the Blocking property to false.  Now when you connect you get an exception (you'll need to put it into a try/catch block) which just says the connection couldn't be completed immediately.  You can then call Socket.Poll to wait for the connect to finish, and then check if the socket is connected.  I know this is probably not enough, I haven't found a good example, I'll try to come up with a simple example ...



#4 SteveS123

SteveS123

    Member

  • Members
  • PipPip
  • 21 posts
  • LocationMissouri

Posted 01 April 2014 - 10:23 PM

Thank you for the reply jrlyman3.  This may sound pretty bad but where is it that I set the socket blocking to false.  I am able to stop the program with a breakpoint and edit the property "m_fBlocking" to false and this will make the code throw an exception but I am unable to set the blocking mode through code.  I tried "setSocketOptions" there are no properties there to set the blocking mode.  I tried "NoDelay" and had no luck.

 

Thanks again,

Steve



#5 Duefectu

Duefectu

    Advanced Member

  • Members
  • PipPipPip
  • 34 posts

Posted 05 April 2014 - 11:22 PM

I'm very disappoined about the ND2 network quality.

I solved the problem opening the socket in a new thread. If it hangs not freeze the main thread.

But at long time, I have hangs on the ND2, only if the Ethernet cable is pluged.

I try to change to UDP sockets, with less hangs, but many as desired.

No good quality for me, not for industrial use!



#6 jrlyman3

jrlyman3

    Advanced Member

  • Members
  • PipPipPip
  • 67 posts
  • LocationNorth St Paul. MN

Posted 16 April 2014 - 11:33 PM

This turns out to be harder than I expected, due to the fact that the .Net Micro Framework does not include everything from the full framework.

 

If you try to connect to a host on the network that doesn't exist, or just isn't responding, your thread will lock up until the host responses (which may be never).  Although the .Net Framework theoretically handles all of this with no problem, the 4.2 version of the .Net Micro Framework is missing a number of important properties and methods.

 

According to the documentation the normal way to handle this situation is to set the Blocking socket option to false, then the Connect() method will throw an exception because it can't connect immediately (the TCP connect protocol takes some time). You catch the expection and wait for the connection to be be completed, and if it doesn't complete quick enough then you return an error. No hang.

 

Unfortunately, the 4.2 .Net Micro Framework is missing the Blocking and Connected properties, and the Send() method does not work as documented. The following code shows how to get around this ... but it's a kludge. 

 

using System.Net.Sockets;
using System.Reflection;

int TIME_PORT = 37;
IPEndPoint iep = new IPEndPoint(
    IPAddress.Parse("192.168.3.3"), TIME_PORT);
Socket socket = new Socket(AddressFamily.InterNetwork,
    SocketType.Stream, ProtocolType.Tcp);

Type sType = Type.GetType("System.Net.Sockets.Socket");
FieldInfo blockingInfo = sType.GetField("m_fBlocking",
    BindingFlags.NonPublic | BindingFlags.Instance);
blockingInfo.SetValue(socket, false);

try {
    socket.Connect(iep);
} catch (SocketException se) {
    // Ignore this exception, it takes time to complete the connection.
}

This code uses reflection to access the blocking property which is not publicly available to us.  It catches the exception during Connect() and ignores it.

 

The problem is how to we know if the connect completes.?The documentation says that you should get an exception if  you call Send() with a zero length and  the socket hasn't finished connecting, but it doesn't.  If you call Send() with a non-zero length then it hangs whether blocking is true or false.  And if you call Receive() it just returns 0 bytes.

 

The good news is that the SendTimeout property does work.  If you set it to 300 the send will wait for 300 milliseconds and then throw an exception (might as well set the ReceiveTimeout value to 300 too).

 

So add the following code and you should be good to go.  There is a slight chance that you'll need to wait a little bit for the connection to complete, or maybe retry the first send a few times before giving up.

socket.SendTimeout = 300;
socket.ReceiveTimeout = 300;

byte[] cmd = new byte[1];
try {
    int xx = socket.Send(cmd, 1, SocketFlags.None);
} catch (SocketException se) {
    // Unable to send data - probably no connection.
}


#7 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 22 April 2014 - 11:58 AM

Hi jrlyman3,

Thanks so much for sharing your reflection workaround.

All--what other features/methods of System.Net would you like to see exposed in NETMF vNext?

Chris

#8 SteveS123

SteveS123

    Member

  • Members
  • PipPip
  • 21 posts
  • LocationMissouri

Posted 22 April 2014 - 05:38 PM

Thank you jrlyman3 for your work-around.  I was able to test it today and the ND that I unplugged was caught and threw an exception.  
The whole reason that I originally had this problem is because I have seven ND+2's connected on a network but they drop connection at random times.  I'm running two threads on them, one is listening for incoming ethernet requests and the other is running SPI for LED strip lights.
Do you have any idea why the uC's drop out randomly?
 
Here is the post I started but have yet to get any replies.
 
Thank you again,
Steve


#9 jrlyman3

jrlyman3

    Advanced Member

  • Members
  • PipPipPip
  • 67 posts
  • LocationNorth St Paul. MN

Posted 23 April 2014 - 03:09 AM

Steve,

 

Glad that helped.  It turned out to be much more of a problem than I expected and it didn't fix my random freeze problem :( either.

 

If you are repeatedly creating and closing sockets on a Netduino it could be running out of socket resources, each closed socket hangs around for a while to support the TCP CloseWait time.  I haven't explored this on a Netduino, but it's one theory.  Have you tried keeping the socket to each peer open?  Do they need to be fully connected, or could connect them in a ring?  Or have one as the master?

 

I've read some posts that indicate some issues with the network, especially if there is a lot of traffic.  I'm thinking that a marginal power supply might also cause hang conditions.  If I come up with a solution I'll post it.

 

Good luck.

 

John



#10 jrlyman3

jrlyman3

    Advanced Member

  • Members
  • PipPipPip
  • 67 posts
  • LocationNorth St Paul. MN

Posted 23 April 2014 - 03:14 AM

Chris,

 

I haven't started a list yet, but off the top of my head I miss:

 

  • StringBuilder class
  • Blocking and Connected properties of Socket class
  • List<> class and templates in general

My only other complaint is the lack of coherent documentation.

 

On the plus side the forums are great!

 

Thanks,

 

John



#11 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 23 April 2014 - 01:42 PM

Hi John,

Thank you very much for sharing your request list. A few quick notes...

  • StringBuilder class
System.Text.StringBuilder is built into NETMF 4.3.1. Is it missing features that you need?

  • Blocking and Connected properties of Socket class

Noted. Let me see what can be done about that.

  • List<> class and templates in general

Just FYI: at BUILD, Microsoft mentioned that they are working on adding generics ("modern language features") support for NETMF vNext.

My only other complaint is the lack of coherent documentation.


Very true. There was some work done to clean up the NETMF documentation in 4.3.1, but it hasn't been posted to MSDN yet. Here's a link to the raw help files:
http://netmf.codeple...oads/get/790725

On the plus side the forums are great!

We can give our awesome community members credit for that one. :)

Thanks for all your contributions to the community too, John.

Chris





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.