Question on VxWorks socket and non-blocking I/O

[Kenneth Arakaki]

Hello,

I am debugging some socket code for a ZIATECH SBC. A socket is created:
socket(AF_INET, SOCK_STREAM, 0)
setsockopt(socketfd, IPPROTO_TCP, TCP_NODELAY, ...)
connectWithTimeout(socketfd, .....)
and
ioctl(socketfd,FIONBIO, (int)&on)

this should configure a socket: non-blocking,immediate,TCP

the issue is that the socket is polled:

ioctl(socketfd, FIONREAD, (int)&bytesUnread)

if bytesUnread != 0

while (bytesUnread != 0)
read(socketfd, (char*)onebyte,1)
ioctl(socketfd, FIONREAD, (int)&bytesUnread)

my contention is that this will grab anything in the port,
and because it is non-blocking it might be mid message stream

Shouldn't select() (software interrupt) be used to monitor
the port?

Thank you for any help.

[Paddy]

Yes you should use select.. because the task that is doing the polling read
will spin until data arrives, using up valuable CPU time and preventing
lower priority tasks from running. Select in effect blocks waiting for
activity on a socket (select is really most useful where multiple sockets
are involved as one select can monitor multiple sockets). Selecting on one
socket is almost the same as just using a blocking socket (select does give
a useful timeout feature though).

If you want to stay with existing code, I suggest you use something like
taskDelay(10) within the polling loop to allow other lower priority tasks to
execute.

regarding mid stream messages reception, that is possible because tcp/ip
sockets are more like pipes, you will need to provide some method of
synchronization within the data to sort out the data coming in on the
socket.

patrick

"Kenneth Arakaki" <ara...@nortelnetworks.com> wrote in message
news:396DFC72...@nortelnetworks.com...

[Jon Baggott]

Blocking or non-blocking has nothing to do with it. TCP sockets are always
"mid-stream" - a read can return an arbitrary number of bytes up to the
number you specify, and has nothing to do with the size of the corresponding
write at the other end; ie, a TCP socket is a pipe. If you're sending
messages, you have to use your own synchronization scheme. This is different
from UDP sockets, which do send and receive complete messages (but they
might not arrive at all).

What this code appears to do is to suck dry the pipe, keeping only the last
byte sent. Presumably, the other end is sending status bytes. You could do
the same thing with select and a zero timeout.

--
Jon Baggott
General Dynamics Electronic Systems
"The views expressed are the author's and do not necessarily reflect the
official position of GD or any of its subsidiaries"