problem with socket recvfrom in Neutrino 6.1

QNX Newsgroups (Archives) qdn.public.qnxrtp.embedded
1

I am sending/receiving UDP messages using the standard sendto/recvfrom
socket API using the non-blocking option. The problem that I am running into
is that upon the return of the recvfrom system call, the data may not always
be in the received buffer even though the returned value from recvfrom was
greater than zero. To patch this problem, I called recvfrom with the PEEK
option turned ON to make sure my data was there before fetching it. This
patch works fine except that the recvfrom call with the PEEK option takes a
long time, about 160 usec. For our application, 160 usec was not acceptable.
I verified the socket is non-blocking and the option RECV_TIMEOUT is zero.
Without the PEEK option, the recvfrom takes only a couple usec or less. Has
anyone run into a similiar problem ? and what was your solution ?

Thanks,

Mike Lee
Berkeley process Control
mikel@berkeleyprocess.com

2

I made a mistake on my measurement. The recvfrom call takes 160 usec
regardless of the
state of the option. You could set the flag to zero or MSG_PEEK, and it
would still take
160 usec to complete. I am using a MIPS 5000 series CPU with 256 MB ram.
Have anyone done any timing measurement on these socket calls ?

Thanks,
Mike Lee


“Mike Lee” <mikel@berkeleyprocess.com> wrote in message
news:auab5t$hq3$1@inn.qnx.com…

I am sending/receiving UDP messages using the standard sendto/recvfrom
socket API using the non-blocking option. The problem that I am running
into
is that upon the return of the recvfrom system call, the data may not
always
be in the received buffer even though the returned value from recvfrom was
greater than zero. To patch this problem, I called recvfrom with the PEEK
option turned ON to make sure my data was there before fetching it. This
patch works fine except that the recvfrom call with the PEEK option takes
a
long time, about 160 usec. For our application, 160 usec was not
acceptable.
I verified the socket is non-blocking and the option RECV_TIMEOUT is zero.
Without the PEEK option, the recvfrom takes only a couple usec or less.
Has
anyone run into a similiar problem ? and what was your solution ?

Thanks,

Mike Lee
Berkeley process Control
mikel@berkeleyprocess.com