mbed official / WiflyInterface

mbed official WiflyInterface (interface for Roving Networks Wifly modules)

Dependents:   Wifly_HelloWorld Websocket_Wifly_HelloWorld RPC_Wifly_HelloWorld HTTPClient_Wifly_HelloWorld ... more

Henry Leinen

Issue: Non-blocking verson of accept method in TCPSocketServer

Currently the accept method only works in a blocking way for me. The Problem is that I need a non-blocking version which allows me to process other stuff while waiting for an incoming connection.

I have made a local modification in the following way :

proposal for a non-blocking Version of accept

int TCPSocketServer::accept_async(TCPSocketConnection& connection) {
    int nb_available = 0, pos = 0;
    char c;
    string str;
    bool o_find = false;
    while(wifi->readable()) {
        nb_available = wifi->readable();
        for (int i = 0; i < nb_available; i++) {
            c = wifi->getc();
            if (c == '*') {
                o_find = true;
            }
            if (o_find && c != '\r' && c != '\n') {
                str += c;
                pos = str.find("*OPEN*");
                if  (pos != string::npos) {
                    wifi->flush();
                    return 0;   //  success
                }
            } 
        }
    }
    return 1;
}

Is it possible to add this functionality somehow so that it is contained in the head revision and available per default ? Is the proposal a robust solution in your opinion ?

2 comments:

David Smart
31 May 2013

Hi Henry, I'm far from an expert, but was also looking for a non-blocking version. What I found is that Socket has a 'set_blocking(...)' API, but setting it to false didn't make it non-blocking. I followed that for a while, but didn't get to a solution. And then in looking at your suggestion, I have to wonder if it is possible that one call to this might end up getting "*OP" and the next call picking up "EN*" - which then wouldn't match. In some code I was working with, the fragmentation happened a few characters into a subsequent line, so I had to cache those from call to call.

Henry Leinen
02 Jun 2013

Yes, you are right, I have experienced this Problem already. Maybe an increase of the cyclic receive buffer (which is large enough to capture a Connection request) is sufficient ? Of course one would should not call any other wifly functionality between two accept calls in this case.

Unfortunately the RTOS library is not working together with the WiflyInterface. If it would there would be no need for a non-blocking Version for me anymore.