Thread: strange read() problem

Hi,

I'm doing some raw socket UDP send and receive. After establishing a UDP "connection" using connect()*, I use read() and write() on the client side to send/receive char data.

My client code works if I simply calls read in the following manner

Code:

n = read(sd, recBuf, numBytes);

So I am putting a timeout mechanism around it using alarm():

Code:

signal(SIGALRM, sig_alarm);
alarm(5);
n = read(sd, recBuf, numBytes);
//handle errors here; Note: there exists a signal handler for SIGALRM
alarm(0);

All of a sudden read() no longer works. I keep getting n = 0 bytes. I changed the server to send nothing and the timeout doesn't work either. The code return almost immediately with n = 0.


I don't get how setting a signal can affect descriptor operation... SOS

Thanks


*UDP is connectionless. However, using connect() on UDP allows me to use read()/write() instead of sendto()/recvfrom().

> It seems like when the file is written, it will end up with 7 character.
In Linux, you get exactly what you asked for.

Post your code which writes 6 characters, but you end up with 7 in the file.

You're not making the mistake of using feof() to control a loop, because that too will give the "appearance" of there being more data in the file than there is, which is why you shouldn't do it, and there's a FAQ on the subject.

> So I am putting a timeout mechanism around it using alarm():
A better approach would be to use the timeout you get with select()

echo normally appends a newline. Do "ls -l" on the file after you've created it.

Try the -n option with echo:

Code:

DESCRIPTION
       NOTE:  your  shell  may have its own version of echo which
       will supercede the version described here. Please refer to
       your  shell's  documentation for details about the options
       it supports.

       Echo the STRING(s) to standard output.

       -n     do not output the trailing newline