non-blocking socket sends in Vx/Works 5.3.1

[Tim Sell]

Using Vx/Works 5.3.1 and iq960rx BSP with Dec21x4xEnd ethernet, I'm having a
lot of trouble getting my socket send() to work correctly after I set my
socket fd to non-blocking mode. The symptom I'm seeing is duplicate data
being transmitted across the socket in cases where I must retry a send()
after a previous EWOULDBLOCK or EAGAIN error. (I used network monitor
traces to help arrive at my conclusion.) Does anyone know of any bugs in
this area? If so, I would GREATLY appreciate any suggestions for a
workaround. My basic goal is simply to never block on a socket operation --
I don't really care what I must do to make it work.

One of the things I have tried to do to overcome my problem with
non-blocking mode is to use select() to tell me when the socket becomes
"writable". Unfortunately, this can still result in the send() blocking
because an fd apparently becomes "writable" when 1 byte can be written to it
without blocking. I need some way to ask "can I write <n> bytes to the
socket now without blocking?"; select() just answers "can I write 1 byte to
the socket now without blocking?". Vx/Works doesn't appear to implement the
SO_SNDLOWAT (send low-water mark) socket option, which I believe could be
used to modify the behavior of select().

FYI, I describe my algorithm below for handling non-blocking sockets.

Set the socket non-blocking after opening it:
int on = TRUE;
ioctl (sock, FIONBIO, (int)&on);

Issue each send() in a loop, which handles these error conditions:
1. send() returns -1 with an errno value of EWOULDBLOCK or EAGAIN -- I
recover this case by simply sleeping and re-looping. (My finished version
of code will probably do something more important than sleeping, but for
testing that is sufficient.) I have observed executing this code in my
testing. However, it seems like whenever I get into this code, there is
extraneous send data that gets delivered over the socket.
2. send() returns -1 but the errno value is neither EWOULDBLOCK nor
EAGAIN -- blow up with an error and close the socket. I have not observed
this happening in my tests.
3. send() returns 0 -- blow up with an error and close the socket. I have
not observed this happening in my tests.
4. send() returns a positive value -- increment the buffer pointer by the
positive value returned, decrement the bytes-left-to-send value by this
positive value, and re-loop.

[john_...@my-deja.com]

Hello,

There was a bug in the first release of SENS (1.0) that did exactly what
you describe. The SPR number for the problem is 20948, and there is a
patch available on WindSurf for it.

HTH,

John...

In article <8v9eum$jqa$1...@trsvr.tr.unisys.com>,

Sent via Deja.com http://www.deja.com/
Before you buy.

[Tim Sell]

Thanks! That did the trick. Actually I downloaded SENS 1.1, which
apparently includes the fix for SPR 20948. For some reason I couldn't
download the patch for SPR 20948 by itself; I kept getting an error about a
file being missing.

<john_...@my-deja.com> wrote in message
news:8vap05$stv$1...@nnrp1.deja.com...