[ace-users] recv_n and send_n with No Timeout
Douglas C. Schmidt
schmidt at dre.vanderbilt.edu
Tue Aug 7 03:02:06 CDT 2007
>Hi Dr, Schdmit,
>ACE version: 5.4
BTW, I recommend you consider upgrading to ACE+TAO+CIAO x.5.10 (i.e.,
ACE 5.5.10, TAO 1.5.10, and CIAO 0.5.10), which you can download from
under the heading: "Latest Beta Kit".
The DOC groups at Washington University, UC Irvine, and Vanderbilt
University only provide "best effort" support for non-sponsors for the
latest release, as described in
Thus, if you need more "predictable" help for earlier versions of
ACE+TAO, I recommend that you check out
for a list of companies that will provide you with ACE+TAO commercial
>OS: Windows XP, not sure what winsock version.
>Compiler: we compile under Borland BCB 6, Borland Turbo10,
>MSVC .net2003 and MSVC .net2005. We use all these compilers
>Contents of config.h:
>// ACE Config.h Borland C++ 6.0 ACE header
>I have no problem with supplied examples.
>There are occasions when the peer (embedded DSP system acting as the
>server) may stop responding to send_n/recv_n due to a crash.
>Our application is a DSP board running embedded software. We provide
>the network communication library software and our customers put their
>analysis software. On the other side of the network there is a Windows
>PC acting as a client and that is where ACE is running.
>Our problem is the following: We would like to use only blocking calls
>to send_n(..) and recv_n(..) since we do not know how long the DSP is
>going to take to respond to our queries (i.e. it may be busy doing
>signal processing). Now, in the case where the DSP crashes we would
>like to re-establish communications with the board; so I am
>researching the possibility of having a supervisory thread (on the PC)
>monitoring DSP-board status and if gone, then abort any pending
>recv_n / send_n.
>So the question is: is there a way to abort a recv_n / send_n which
>have no timeout (infinite wait time) ? I was reading NPv1 and I was
>uncler if ACE_SOCK_Stream::close() or shutdown() would achieve this
There's no portable way to ensure this, i.e., you can't rely on
closing a socket to unblock recv*/send* calls.
>I understand we can use timeouts and have somekind of keep-alive
>messaging, but I wanted to explore this possibility.
I recommend you use some kind of timeout and/or keep-alive. There's a
discussion about this in one of the sidebars in C++NPv2. Looking for
something like "Handling Silent Peer".
Dr. Douglas C. Schmidt Professor and Associate Chair
Electrical Engineering and Computer Science TEL: (615) 343-8197
Vanderbilt University WEB: www.dre.vanderbilt.edu/~schmidt
Nashville, TN 37203 NET: d.schmidt at vanderbilt.edu
More information about the Ace-users