Socket.Accept - Blocking?

Archive
1

For the class GHIElectronics.NETMF.Net.Sockets.Socket the method Accept() is blocking. Is there a non blocking way to accept client connections?

2

@ andre.m no as in it’s impossible?

3

You can simply start a new thread where you call socket.Accept()
That’s the same thing as AccptAsync
The Assync pattern is not implemented in NETMF.
You could also use my ThreadPool to do so:
https://www.ghielectronics.com/community/codeshare/entry/806

Same thing for socket.Read()

4

Is there anyway to poll to check if there are any requests available?

5

You could use UDP instead of TCP. By this anyone can send messages to the board at any time. All you need to do is check weather there is data available for the socket.
But you need to take care of message integrity your self then (checksum, resend, … that’s all TCP stuff).

6

@ Reinhard, taking care of it myself would negate even offloading the TCP stuff :frowning: sob

Is there a way to know what the remote IP is before you socket.accept?

7

Not that I know, but you can check the IP and close the socket immediately without sending/receiving anything if you don’t like the incoming IP.
If you want to prevent a DOS attack then wait a bit before you close the socket.

8

Yes, what’s the reason to want to filter the IPs that you’ll accept the connection from ? What problem are you trying to solve?

9

I’m seeing a problem when there are to many threads (like 3) Visual Studio is unable to connect to the Fez to begin debugging. To this end I’ve had to write a blocking check

            while (!Debugger.IsAttached) {
                Thread.Sleep(5000);
            }

… at the start of the main thread. To this end I want to eliminate all threading that I can from the application and just have a big “game loop” running in a single thread to do all operations including TCP. I wanted to be able to check (without interrupts) if there is a waiting connection and handle that request as it comes.

10

A better idea is actually to sleep the main startup action for 5 seconds or a button press, so that there’s plenty of free time for the debugger to respond. kind of like a “delayed start” service.

11

That doesn’t work. Once the program starts running. it is very difficult to get the debugger attached.

12

I never had this problem. My apps uses a lot of threads. I run between 10 to 20 threads in parallel.
And usually the debugger is connected before my network interface is fully initialized (Using G120 + ENC28). Before that I do not start any parallel thread. So I don’t see why the treads are related to your debugger issues.

13

I’m using an older Fez Rhino, with a Wiznet Module. Not as powerful as the G120

14

I have seen this but only when the threads are running full whack, ie in a while (true) loop, most threads should be sleeping on an event etc

15

So the typical use-case is you restart your app and connect the debugger at that point. That’s why a 5-sec delay or button-press to proceed assists, because it’ll give plenty of time for the debugger to attach.

It seems like in your case that you want to connect to the debugger at some future point in the execution. So there, as Peter points out, if you give the processor no free time then the debugger thread won’t be allocated time. Make sure all your threads at least leverage sleep(1) which should see the debugger get some time - longer might be necessary.

I’ve used USBizi a lot, and never seen this behavior except where I was tying up the processor unnecessarily.

16

Yes, this pretty much sums up my problem. I’ve got to stop using those while(true) loops. Perhaps writing the application to be event based would be a better idea than function based.

17

A simple sleep at the end of each of your while loops will go a long way to addressing this. I love the idea of event driven code, but some problems do not break down into that :slight_smile: