Programming

i am programming a tcp_ip server which intends to listen permanently to a client . the client can disconnect and connect again and the server accept it(by this point it works).The problem is when the client lose connection without a disconnect command and my code can't get it and keeps waiting for some message to come with the read command considering that socket still working. i need it to exit from read command and close the socket in order to accept another one...
I thought to use a separate thread which consider the connection lost if it doesn't read anything from the client for a certain period of time...but it seems strange to me that there's not a prepared function in some tcp library that already does it.
ANY SUGGESTMENTS? THANKS A LOT
Massimo
Here's a piece of the code:

void die(char * message)
{

perror(message);
exit(1);

}

void copyData (int from, int to)
{

while ((len = read(from, buff, sizeof(buff))) > 0)
{
interpreta_messaggio(buff);

}
close(from);

}
void main()
{
struct sockaddr_in address;
int sock, conn, i;
size_t addrLength = sizeof(struct sockaddr_in);

if ((sock = socket(PF_INET,SOCK_STREAM,0)) < 0)
die("socket");

i=1;
setsockopt(sock,SOL_SOCKET,SO_REUSEADDR, &i,sizeof(i));

address.sin_family = AF_INET;
address.sin_port = htons(7000);
memset(&address.sin_addr, 0, sizeof(address.sin_addr));

if (bind(sock, (struct sockaddr *) &address, sizeof(address)))
die("bind");

if (listen(sock,5))
die("listen") ;

while (( new_socket = accept(sock, (struct sockaddr *) &address,&addrLength)) >=0)

{
copyData(new_socket,1);
}

if (new_socket < 0)
die("accept");

close(sock);
//return EXIT_SUCCESS;
}

I guess you're asking how to time out a read. There are lots of ways. My choice would be to use select().

select can monitor your fd and return when a read will succeed without blocking. Then you just read the data. But select also can be give a timeout. And it will return when time expires.

It's so easy, it's almost cheating.

poll() is another system call that is similiar to select().

Another approach is to use setitimer() or alarm() to request a SIGALRM and some point in the future. Then just do the read. Assuming that the SA_RESTART option is off for SIGALRM, the system call will not be restarted. It will fail with a EINTR error.

You could also put the read inside a signal handler for SIGIO. Then use fcntl() to arrange for the SIGIO when data is available for reading.

But these ideas are all generic stuff and you want something in the tcp library. In that case you can turn keepalives on. But since keepalives must comply with the rfc's, you have very little control over them.

I still say select() rocks. But it's your program.

i definitely think select rocks too ...i just put it in the main a infinite loop with select inside


while (1) {
build_select_list();
timeout.tv_sec = 1;
timeout.tv_usec = 0;

readsocks = select(highsock+1, &socks, (fd_set *) 0,
(fd_set *) 0, &timeout);

if(readsocks>0)
read_socks();
}


and then accept the sock and go to read my buffer.

i also made every sock that connects nonblocking by setting the flags with fcntl(i don't know if it's the best thing)

In this case the server never ever block and that's good, but it happens sometimes the client (which is a control system with a readymade module for TCP IP client that i cannot change) goes up and down with the connection for hundreds times in a row before staying connected ... is the tcp ip so instable or there's something wrong?
anyway thanx again for your precious helping

TCP/IP has security problems and if you try to break it you will probably succeed. Other than that it seems very stable to me.

The complaint in your first post was: you can't detect a dropped connection. That is a common complaint. A TCP connection can persist forever until it is explicitly shutdown. Even with keep-alives, it can last for hours.

Your new complaint is: connection goes up and down hundreds of times. That's an unusal complaint to make about TCP/IP. Either your server or the client is explicitly dropping the connection. And the client is choosing to reestablish a connection. I can't tell you why this is.

I guess, the question is "How to find when the peer has closed its connection?"

There is a simple solution to find out when the other end of the socket has closed.

When the server reads from a closed socket, the read() call returns 0. This indicates that the client has terminated its connection.