Last attempt at solving a socket.Write error

Archive
21

Few things I can think of to keep the investigation moving are
Call _clientSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.Debug) and see if that sheds any light (after it’s created in the ListenerLoop).

The Socket.Send method will be synchronous, even though it is not explicitly specified, and if anything goes wrong during the send, it can just block forever.

In your timer handler call Debug.GC(true) before you create your string. The Cerberus has a very small amount of RAM and when the debugger is attached it has even less.

Does it fail faster if you send more data? i.e. try sending 10x as much…use a for loop around your Send maybe…

22

@ byron - I have tried the SetSocketOption as below:

  private void ListenerLoop()
        {
            while (_clientSocket == null) // exit method after socket is found
            {
                    Debug.Print("listening...");
                    _clientSocket = _hostSocket.Accept();
                try
                {
                // Blows up here
                 _clientSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.Debug, true);
                }
                catch (Exception ex)
                {
                    Debug.Print(ex.Message); 
                    throw;
                }
                    Debug.Print("Accepted Port 60504 connection from " + _clientSocket.RemoteEndPoint); 
                    _shortTimer.Start();
            }
        }

Unfortunately, it blows up where I marked it it gives error 10042 “bad protocol”

23

@ Tal_McMahon - If the socket conection fails and you cannot find the reason, perhaps the problem can be solved in a way that your client sends a receipt message, if you do not get the rigtht receipt message, abort the listener thread - thread.abort() -, make a new one and send the lost message again.

24

@ Tal_McMahon - Hi Tal, can you give us the code of the client which receives the messages?

25

Hi Tal,
I think I found the reason for your problem. I got your application running on my spider. It runs without problems for many hours. When I slow down the used client with a sleep of 5 seconds between the readings of the next block of data, the server on the spider crashes after some minutes. The reason propably is, that the send-buffer of the socket is full. I think you should implement a receipt message from the client and wait with sending of the next block until you got the receipt.
Roland

26

@ roSchmi The Client is any 3rd party ap that subscribes to the feed. I do not control that. That af course also means I cannot put in any sort of Ack/nack for when the data was received.

I am fairly confident that the socket is the issue and I am working on putting it onto a background thread with a flag that would signal when It was complete. I will keep you posted

Tal

27

@ Tal_McMahon - Did you get it running in the meantime?
Regards
Roland

28

I abandoned the platform. I reworked the code in a full .Net framework and am using an Atom processor based solution.

I spoke with someone at Microsoft and he told me that he had heard rumors that the TCP/IP socket in the micro-framework was flaky for long term open connections. He was also quick to point out that the micro-framework was now open source so I could dive into the TCP/IP stack and fix it myself. As most people are writing request/response type apps now days, the errors I am seeing are never encountered. There just aren’t many people doing what I was trying to do (open an old school socket and use it indefinitely). As a result, there isn’t a lot of buzz in the community addressing this scenario, and I am fairly new to this low a level of programming, going one step lower into the source code is just not appealing to me. As a result, I have abandoned the platform for work related stuff…maybe I will build a quadcopter.

Tal

29

@ Tal_McMahon - This is sad news to us. Please do not give up on NETMF just yet. I agree the switch in TCP/IP stacks in NETMF caused many little issues, that we are working very hard on nailing down as quickly as possible. The good news is that now we all have the complete source codes, including networking.

It maybe too late for this project but please consider NETMF again in the future.

30

@ Gus - Did anybody from GHI have a look on Tals issue? Not? …no wonder…
Regards
Roland

31

@ RoSchmi - of course we did but with SDK release last week we have limited time. His problem is not a 5 hour fix but days of work, which is still on the list of improvements.

32

@ Gus - Thanks, good to hear! I can imagine, that it is hard to get it running on all the different and great new mainboards. Keep on running, I appreciate your work. I’m shure can!
Regards
Roland

33

It would be great when this part is fixed. Unfortunately for me, I was trying to use this for a production solution at work and blew through a few deadlines and had to move onwards.

Just for the record, When I was using the Cobra (first version) I never had the problem, so what ever was different between that build and the Spider/Hydra/Cerberus build’s TCP stack was at issue.

Thanks for the contributions and suggestions.

Tal

34

The whole networking stack was changed. We are on it so no worries, just need time.