[23] in 6.033-lab
Re: "select" problem
daemon@ATHENA.MIT.EDU (Jeffrey Hu)
Wed Mar 26 05:04:53 1997
From: Jeffrey Hu <jhu@MIT.EDU>
To: "Minh T. Thai" <mtthai@MIT.EDU>
Cc: 6.033-lab@MIT.EDU
In-Reply-To: Your message of "Wed, 26 Mar 1997 01:56:11 EST."
<199703260656.BAA05700@cinderelly.mit.edu>
Date: Wed, 26 Mar 1997 05:05:17 EST
> I ran into another problem. I try to re-send a packet if I don't
> receive ACK from the receiver, so I use a timer with "select".
> Assuming my receiver is down (ie I turn it off), so the first timer go
> off, no response. When I try to block it again with "select",
> "select" return right away, saying that packet (ACK) arrives, I then
> try to read from that port with "recvfrom" then I get a "connection
> refused" error. Shouldn't "select" return at the second block?
Did you reset your timeout before calling select again? What
could be happening is that you are not reseting your timeout when you
call select. Your call to select effectively has a zero timeout
and thus it returns right away. Your recvfrom is saying
"connection refused" because you don't have a server bound to the
port on the machine that the client is trying to contact. Select
blocks at the select() statement, not at the recvfrom statement.
You loop should look like this:
while( sec < initialsec + TIMEOUT_PERIOD ) {
FD_ZERO( &readfds );
FD_SET ( s, &readfds );
timeout.tv_sec = 1;
timeout.tv_usec = 0;
res = select(s+1, &readfds, NULL, NULL, &timeout);
if (res == -1) {
perror ("select");
}
if (res > 0) {
bytes_read = recvfrom(...);
if( bytes_read < 0 ) {
perror("recvfrom");
}
printf("Received: %s\n", msg);
break;
}
<check timers>
}
The only times I get a "connection refused" error from recvfrom or
sendto for the client is when I don't have a server bound to the port with
which the recvfrom or sendto function is trying to communicate. I'm
guessing that's probably why you got that problem that you described.
Jeff
