Socket.Connect

GrahamS · May 21, 2013, 9:21am

Hi,

OK - so I have trawled the forums and can see LOADS of stuff about Socket.Connect not working properly in 4.x.

Some say it is/will be fixed in 4.2 - well its not.

I have an EMX board in a custom PCB. Now using VS2012 (boy is that SLLLOOOWWWW! with NetMF), and using GHI 4.2 with MS 4.3 - as recommended.

Just rebuilt my code (after a year or so where its been working based on 4.1 ??)

First I find that DHCP is broken (see separate thread under my name) and there is no proposed fix yet…

Now I find that if my remote (PC Windows Service) code is not running, the EMX code just hangs in Socket.Connect(endpoint). It doesn’t come back when the service starts, and the thread is completely dormant - ie HUNG.

The only thing I can think of doing is a watchdog reset of the board if I can detect this event ???.

Now - this problem has been reported for at least a year in the forums.

So is there any chance of a fix for this in the near future please ???.

This is BASIC Networking 101. If a socket refuses to connect, doesn’t time out or even raise an exception then its a fundamental flaw in the OS, as there is no code I can add to ‘handle’ the error - except of course reset the board - which is simply a ‘sledgehammer to crack a nut’ problem.

I am currently viewing 4.2/4.3 ‘upgrade’ as a total downgrade - and thinking about moving back to 4.1 even.

I’ll be honest - this is completely putting me off using NetMF - it seems to be going the same way that Windows CE went - ie down the pan :-((. Yes I deployed that MANY years back until realising that MS were simply NOT even giving it lip service in terms of REAL support.

As a programmer of MANY years standing (30+ in fact!!) I am finding that todays generation of software is getting less reliable by the day (more complex but less reliable :-((. We seem to have forgotten ‘the basics’ - like a working product :-O.

The thing is - no-one seems to even ‘own’ the problem :-O.

I anyone can comment on when a fix for these basic issues may come out - please do respond :-)) - I could do with some good news ;-)).

Severely dis-heartened…

Graham

Chris_MC · May 21, 2013, 10:36am

Hi GrahamS,

Did the TCP Socket.Connect hang for you on 4.1? It always did for me. Unfortunately it was one of the first things I discovered on starting development work with NetMF. My solution/work around was to reverse the process and make my windows service initiate the TCP connections to my emx application. That way I was never calling Connect from NetMF.

I agree that it is a very poor reflection on NetMF when they can’t even get the basics of networking stable. Now it does appear to be a Microsoft rather than GHI issue, and reading the notes of 4.3 it may now be solved:

Work Item 1396 - Socket.Connect still blocked after reinsert ethernet cable

Currently - someone else correct me if I’m wrong - even though you are targeting 4.3 for visual studio 2012, your framework version (GHI etc) is still 4.2.

Maybe when GHI move to 4.3 this issue will finally be resolved - I see 4.3 is at the RTM stage, I think GHI usually wait to see if there are any QFE releases.

GrahamS · May 21, 2013, 10:52am

Andre,

Just typed a FULL response, pressed send, was logged off and the message trashed - I’ll have to type it all in again !!!

This forum drives me nuts in this respect :-(( - as this keeps on happening…

Graham

GrahamS · May 21, 2013, 11:02am

Chris,

Thanks for the response…

Well I ‘think’ it worked under 4.1 but cannot be 100% sure - without trying it again.

The difference is simply that the service was up and running most of the time I was testing the code. This time I used a new server, and took it down to add new messaging. Hence I found this problem :-((.

I cannot reverse connect as my EMX units will be behind various client firewalls, unknown routers etc. etc. - thats why I always initiate the conversation from the ‘client’ end, and have a multi-channel server ‘listener’ - gets around ALL firewall issues - always assuming you can get an IP address in the first place (see DHCP issues) and that the box doesn’t hang of course :-O.

Glad that you agree this to be fundamental to TCP/IP ;-)).

I am not trying to point any fingers - I just want a working solution - so if its MS or GHI makes no odds to me. My guess is MS - as the problem has also been reported for a long time on non-GHI products as well ;-).

Its VERY similar to the situations which arose with Windows CE - basic fundamental flaws in serial port handling even = very similar in fact !!.

Thanks again.

I will be responding again to Andre as my last reply was trashed by the forum code (logged me out as it was a LONG reply ;-)). I really MUST try to remember to copy the response before sending…

Best Regards

Graham

GrahamS · May 21, 2013, 11:09am

Andre,

OK lets try that again. A shorter version…

Old build from a box which has been untouched for a year :

Ping… TinyCLR
HalSystemInfo.halVersion :4.1.2821.0
HalSystemInfo.halVendorInfo :Microsoft Copyright © Microsoft Corporation. All rig
ClrInfo.clrVersion :4.1.2821.0
ClrInfo.clrVendorInfo :Microsoft Copyright © Microsoft Corporation. All rig
ClrInfo.targetFrameworkVersion :4.1.2821.0
SolutionReleaseInfo.solutionVersion: 4.1.8.0
SolutionReleaseInfo.solutionVendorInfo: GHI Electronics, LLC
SoftwareVersion.BuildDate: Dec 22 2011
SoftwareVersion.CompilerVersion: 410561
LCD.Width: 320
LCD.Height: 240
LCD.BitsPerPixel: 16

New build from the box currently under test (identical hardware) :

Ping… TinyCLR
HalSystemInfo.halVersion :4.2.0.0
HalSystemInfo.halVendorInfo :Microsoft Copyright © Microsoft Corporation. All rig
ClrInfo.clrVersion :4.2.0.0
ClrInfo.clrVendorInfo :Microsoft Copyright © Microsoft Corporation. All rig
ClrInfo.targetFrameworkVersion :4.2.0.0
SolutionReleaseInfo.solutionVersion: 4.2.10.1
SolutionReleaseInfo.solutionVendorInfo: Copyright © GHI Electronics, LLC
SoftwareVersion.BuildDate: May 1 2013
SoftwareVersion.CompilerVersion: 410713
LCD.Width: 320
LCD.Height: 240
LCD.BitsPerPixel: 16

Now I can’t be 100% sure that the old box didn’t also lock up if the server end was not running - maybe not something I tested adequately…

Right now however, the box connects perfectly in milliseconds if the server is running. If the server is NOT running, I have to reboot the box to unlock the task.

NB Unlike many other reports in various forums - my other threads are still running.

Summary: my old dev PC was trashed, so I had to rebuild the NetMF environment and am now running VS2012 Pro. Used the GHI instructions to install under VS2012, and use the new config tool (Alpha) to program the unit (and get the above details).

Hope this helps to clarify the problem…

Sorry for the negativity but what should have taken a couple of hours has now gobbled up 3-4 days+ :-O.

Thanks for your ongoing assistance.

Best Regards

Graham

NB Copied this to clipboard this time in case your forum is over-zealous again ;-)).

GrahamS · May 22, 2013, 4:39am

Guys,

As mentioned by Chris - work item 1396 might just be the answer to these issues. This was implemented in MS 4.3…

So - can anyone at GHI please tell me what the timrframe is for your 4.3 release please ??.

Obviously I am stuck with this problem until that arrives - then it might or migh not be fixed ??.

Hopefully the reported DHCP problems might even be fixed as well :-)).

NB This is exactly where I found myself over a year ago - with the promise that similar networking issues would be fixed with the new and awaited 4.2 release…

Many Thanks

Best Regards

Graham

GrahamS · May 22, 2013, 6:21am

OK - so I had to get this going - so adopted the sledgehammer approach.

I added code so that I can detect if the initial connect works (just sets a flag is it ever returns - leaves it false if it hangs).

I also have code which detects errors if we cannot send data (ie the box disconnects after successful initilaisation) running in my ‘TX’ thread.

I now have (in my main application idle loop) a check to see if we are still connected. If not - simply sit in a tight loop (wait(true) and let the watchdog do its thing (its set to reboot after 30 secs if the app hangs anyway).

This now appears to work - allowing me to reboot if the socket.connect hangs.

So I can (relatively happily) deploy this into the field for trials !!.

I DO still have the DHCP issue however (at least with my router), so will have to fix the IP if this fails when deployed to site.

This raises another question:

In your new Alpha config tool. I can set up a default static IP etc. and then take that if DHCP is NOT enabled. This works great.

BUT if I enable DHCP and it doesn’t work, then run your tool again - my config has now been trashed. Can this not be written somewhere the application cannot reset it ???. This ought to be treated as a ‘factory default’ config settings shouldn’t it ???. Would be GREAT if that were the case ;-)). I like this new tool but this 'limitation (IMHO) bugs me…

Thanks again.

NB Info of 4.3 update would still be appreciated though please ;-)).

Best Regards

Graham

Valkyrie_MT · May 22, 2013, 10:43am

@ GrahamS - You could try mIP. And if the DHCP doesn’t work, I’ll fix it. http://www.ghielectronics.com/community/forum/topic?id=7703

GrahamS · May 22, 2013, 12:18pm

Hi,

Certainly looks like an interesting project you have set up there ;-)).

Not really sure however how it can fit in with my EMX board hardware. I don’t have the luxury of adding more hardware at this time - as the PCB’s already exist.

Now - if it can run using the EMX Ethernet IF and stop the netmf firmware from using it - thats a different matter :-)).

If you think it can be made to work with the EMX ethernet then I’ll try to give it a go ;-)).

Thanks again

Graham