OS recvfrom() failure

5 posts / 0 new
Last post
Offline
Last seen: 10 years 1 month ago
Joined: 02/03/2014
Posts: 3
OS recvfrom() failure

What causes the error, "NDDS_Transport_UDPv4_receive_rEA:OS recvfrom() failure, error 0x4"?

Offline
Last seen: 10 years 1 month ago
Joined: 02/03/2014
Posts: 3

Also, would this error keep a message from being received?

rip
rip's picture
Offline
Last seen: 12 hours 27 min ago
Joined: 04/06/2012
Posts: 324

The OS_recvfrom() error codes use the underlying socket error codes.  4 is an interrupted system call:

Berkeley description: An asynchronous signal (such as SIGINTor SIGQUIT) was caught by the process during the execution of an interruptible function. If the signal handler performs a normal return, the interrupted function call will seem to have returned the error condition.

WinSock description: NOT same as Berkeley, but analogous. In WinSock it means a blocking operation was interrupted by a call to WSACancelBlockingCall.

(hat-tip to http://www.sockets.com/err_lst1.htm)

Generally I see the OS_recvfrom() errors from Windows.

This is something "low level" and so underneath DDS.  If it is a BE reliability qos, the data is lost.  If it is a Reliable reliability, the dropped sequence number will be noted and repaired via the normal method, assuming your history is deep enough.

 

Offline
Last seen: 10 years 1 month ago
Joined: 02/03/2014
Posts: 3

Thanks for the information.

Offline
Last seen: 4 months 2 weeks ago
Joined: 01/15/2013
Posts: 14

Hi,

Some of our customers have worked around this error by disabling the signals during Participant and DataReader creation:

  • Block all signals before calling the three API calls that create DDS threads (create_participant(), enable(), create_datareader() ).
  • Unblock the signals right after the API calls return. Signals only have to be blocked/un-blocked for the create_datareader() call if the subscriber is using multicast for user data.

If you have access to the code that produces the signals (e.g., in the case of signals produced by timers), the following approach is also a possible workaround:

  • Modify the signal mask in the main routines to block the real-time signal used by the timers. This masks that signal off in all of the threads created within the process.
  • Then modify the threads created by the timers to allow only that signal.