Issues w/ non-blocking sockets?

[philipp]

Has anyone used non-blocking sockets successfully?

I noticed that Net/src/SocketImpl.c uses ioctl(FIONBIO) instead of fcntl(F_SETFL, flags | O_NONBLOCK) for instance.

Also that ::recv() is called in the same module inside a loop, regardless of whether _blocking is set or not.

I've submitted fixes for both of these issues, but I'm also noticing some artifacts related to how the poll method works on Linux (using edge-triggered events with epoll() vs. select() on other platforms and level-triggering).

Which makes me wonder if anyone else has used Poco with non-blocking sockets.

-Philip

[cesaraus]

Hi.
I'm using non-blocking sockets to implement a TCP-IP client.
It works BUT I'm having concurrency troubles in changing the SocketReactor::timeout

If I first set a long timeout (e.g.: 10 sec), then I set a short timeout (e.g.: 1 microsec) and send a request to a server that needs few seconds to be answered, I noticed that sometimes (concurrency) the answer is managed by the reactor via the Socket::select(readable, writable, except, _timeout) call that was still listening with the old 10 sec timeout.

If I protect SocketReactor::setTimeout and the Socket::select(readable, writable, except, _timeout) call with a mutex all works.
But setTimeout has to wait for Socket::select to finish, that is not that good if the old timeout is 10 sec and no data comes in the meanwhile.

Any suggestion?

- Cesar

[cesaraus]

Hi Philipp.
What kind of changes have you proposed?
I'm implementing a non-blocking TCP-IP client and I am exploiting a sort of concurrency problem in changing the SocketReactor timeout.

Regards
Vito

[alex]

What kind of changes have you proposed?

He asked for a FIFO buffer that would notify on read/write operation (un)availability. See revison 1829 in trunk.

I'm implementing a non-blocking TCP-IP client and I am exploiting a sort of concurrency problem in changing the SocketReactor timeout.

I'll take a look at this but I'd say if you set timeout to 10 seconds, you should be prepared to wait so long. I'll see if anything can be done there to modify the behavior.

[cesaraus]

Thank you Alex.
The timeout concurrency problem is when I switch from 10sec to, e.g., 250 us. If then I ask the server for an answer that takes long time to come, e.g. 3 sec, sometimes timeout expires (because still using 250us).

[alex]

The timeout concurrency problem is when I switch from 10sec to, e.g., 250 us. If then I ask the server for an answer that takes long time to come, e.g. 3 sec, sometimes timeout expires (because still using 250us).

The described behavior is by design - SocketReactor select() call will keep on going until the timeout expires. Since Socket::select() is a static function, timeout is passed in as a function argument; the only way to signal Socket::select() to stop and accept new timeout would be through a static variable, but then threads could overwrite each other's timeout settings. In your case, the opposite happens - SocketReactor ignores the new setting until the old one completes.

Is it possible for you to run multiple reactors, one for each thread? Obviously, in such a design, reactors should operate on disjoint sets of sockets.