public byte Receive(out int ReceivedBytes)
if (cli.Available == 0) return null;
ReceivedBytes = cli.Receive(buffer);
Application is complex, but shortly there is a “receive” thread which put received bytes into a rounding buffer, a “sending” thread who send message and a processing thread which takes bytes from the rounding buffer to process them
I didn’t really understand your change that improved things. First you say you changed to a While() + Sleep(), and then you say “removing completely”. What do you mean?
When I see a Sleep() improving things I suspect you’ve got a tight loop that’s consuming processor time and not relinquishing for a different thread to handle some of it’s processing… the forced sleep means the dispatcher gets to timeslice over to another thread. Is your app heavily threaded?
The application is obviously heavily threaded, but threads are synchronized to avoid an heavy CPU concurrency. Since we can use VS2012, I can easily monitor my threads to be sure they are not running crazy.
The code has been optimized (I clearly don’t mean optimized by adding some Sleep()) but code performance improvement.
I remove the entire block that was looking if there are any bytes available on the socket. It seems that the call to that function is heavy or risky.
Nowhere in my code there is a “while something” that run without releasing the dispatcher.
The only thing that I suspected in a major CPU consumption was a byte array copy (probably 700 byte to copy inside an array for buffer releasing place) It’s running sometimes
This is another part that I removed (the byte array copy) and the system looks more stable.
The point is, that may be we could use a lot of CPU (and I will), but even if I understand that the connection/socket crashes, I don’t agree with the IP stack crash.
As far as the tests are running, It now looks better. It’s not totally stable yet, so I also added a code to “reset” the networking interface.
I hope to get a totally clean networking layer asap
So, it seems I finally find the cause of the “unstability”, but may be it’s the normal case, I don’t know…
I explain :
I have a Raptor+Enc28 (no matter what the purpose is), which connect at startup to a TCP server (on Windows).
Raptor send a status message every 0.5 second and the server send messages every 0.25 second.
As soon as you are not in the receive method (because you are processing the received message), if some messages are arriving to the Raptor, your network stack is crashed.
So, no matter the CPU availability (I overload the code with some While(true) Thread.Sleep(1)) the problem is with some buffer (I suppose) related to the network stack.
If you do a socket.Receive on the Raptor after packet are effectively arrived, it seems to crash the ENC28 NetworkInterfaceExtension