CyberPsychotic wrote:
> > > while(1)
> > > {
> > > close(sock_a);
> >
> > The first time that you get here, sock_a will have a random value, so
> > you don't want to close it here. You should close it in the parent
> > process after the fork().
>
> hmm. But I don't have any other descriptors opened. (which may've been
> randomly closed). And following the man page, if I don't have any opened
> f-descriptors, close would return -1 and EBADF.
You do; you have the listening socket (sock_s) open. If you closed all
descriptors prior to the `sock_s=socket(...)', then sock_s will be
zero. If sock_a happens to be zero initially, then you will end up
closing the listening socket.
> However, actually this close(sock_a) thing was the source of trouble, when
> I removed it. (I close the same descriptor in process_connection()
> function, called by child), things started working.. hmm. looks like the
> problem with libc, I guess.
Looks like sock_a may have been zero to start with.
> > > while(waitpid(-1, NULL, (int) NULL) > 0);
> >
> > You should pass WNOHANG as the third argument to waitpid(), otherwise
> > this loop won't terminate.
>
> yes I see. By the way, I played with my code foralittle, and killed it
> while it was transforming data, when i ran it again, it couldn't bind to
> the same port, i tried netstat, and here's what I got
>
> tcp 1 45761 192.168.230.4:2000 192.168.5.4:1146 LAST_ACK
> ^^^^^ machine were server runs.
>
> Looks like I broke the connection, and kernel still waits for last_ack
> from remote. Is there way to flush such things?
The kernel should keep resending the FIN until the other end
acknowledges it. There isn't any mechanism to forcibly change a
socket's state (although I guess you could use spak to send a fake
ACK).
> > Neither of these seem likely to cause accept() to fail to accept a
> > connection.
>
> yeah.
Unless you've closed the listening socket, that is. Although this
should cause accept() to return immediately with errno set to EBADF.
--
Glynn Clements <[EMAIL PROTECTED]>
