[Ace-users] Re: recv_n and send_n with No Timeout

Saul srodriguez at innovative-dsp.com
Mon Aug 6 12:20:46 CDT 2007

Hi Dr, Schdmit,
ACE version: 5.4
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

#include "ace/config-win32.h"

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

I understand we can use timeouts and have somekind of keep-alive
messaging, but I wanted to explore this possibility.

Thank you.
God bless you,

Saul Rodriguez
Software Engineer

On Aug 5, 8:19 am, schm... at dre.vanderbilt.edu (Douglas C. Schmidt)
> Hi Saul,
> To ensure that we have proper version/platform/compiler information,
> please make sure you fill out the appropriate problem report form
> (PRF), which is in
> or in
> in older versions of ACE+TAO.  Make sure to include this information
> when asking any questions about ACE+TAO since otherwise we have to
> "guess" what version/platform/compiler/options you've using, which is
> very error-prone and slows down our responsiveness.  If you don't use
> the PRF, therefore, it is less likely that someone from the core
> ACE+TAO developer team will be able to answer your question.
> Naturally, we encourage and appreciate other members of the ACE+TAO
> user community who can respond to questions that they have the answers
> to.
> >I am using ACE as a client. I do a recv_n / send_n with timeout = 0.
> >Now; I am running into the following scenario:
> >1. The other side is an embedded system.
> >2. If for some reason the Host Computer (where I am running ACE)
> >detects that the embedded system has crashed (i.e. some time has
> >passed and recv_n / send_n have not returned); is there a way I can
> >quit waiting so that I can proceed to do recovery work on the
> >communication threads (i.e. the ones using ACE) ?
> Can you simply use timeouts to do this?
> >a) I read something about ACE having support for
> >WaitForMultipleObjects, but not sure how I can relate this to my
> >ACE_SOCK_Stream object doing the send_n / recv_n.
> Please see Chapter 3 of C++NPv1 <www.cs.wustl.edu/~schmidt/ACE/book1/>
> for info on using timeouts with the send*/recv* methods.
> >b) Can I close the socket from within another function and expect
> >send_n/recv_n to return with some error code ?
> It's not clear what you mean here - can you give a short example please?
> >I am reading ACE Practical Design Patterns for Network and Systems
> >Programming, but have not been able to get the answers to neither of
> >my questions.
> Please see C++NPv1.
> Thanks,
>         Doug
> --
> 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.schm... at vanderbilt.edu

More information about the Ace-users mailing list