How to design multiple timeout in Socket Programming(Linux C)

[Sophie000]

I am implementing a peer-to-peer program: When a computer A receives “get file XXX” from stdio, it broadcasts (floods) a request packet to ask others. Both Computer B and C have the file so they send back responses. Computer A pick up B and sends confirm to B. at the same time, it creates a server socket to listen to connection. After Compute B receives the confirm from A, it creates a client socket to connects to A.

I set timeouts to both request and confirm packets. If no response is received by A after timeout, A needs to flood a new request packet again. Otherwise, A cancels timeout of the request. For the same reason, if B does not connect to A, A will send a confirm to C so that C can connect to A

My Questions: How to set timeout?
a. I can use select(). But since I already put a select() with timeout parameter as NULL in a while loop to monitor stdio, request, confirm/response packets, it seems that there is no place to put other selects with timeout parameters。
b. I can use alarm(). But there is no way to know, which request/confirm of which file the alarm() is for. And if I cancle a timeout using alarm(0), other timeout using alarm() is also canceled.
c. I also thought about using fork（）+ select() or alarm: But after the child process is terminated, how do I know it is terminated because of timeout or because response or connection is received? Besides, If it is terminated because of timout, In which part of program should I re-flood the request or re-send the confirm packet?
d. maybe I can use SIGALRM to set status in my child process, and use wait()/waitpid? But I do not know where to put waitpid() so that the parent process does not block other process.

I want to solve the problem and need your help. Can any guru answer the question? Thanks

[sicarie]

What language are you implementing this in?

[Sophie000]

c in linux.thanks.

I think I need to implement sth. so that the interrupts of child processes can be caught by parent process anytime. At the same time, parent processes can do other things without being blocked by its child process. But how?

[sicarie]

Moved to C/C++ Forum.

[Sophie000]

I am implementing a peer-to-peer program: When a computer A receives “get file XXX” from stdio, it broadcasts (floods) a request packet to ask others. Both Computer B and C have the file so they send back responses. Computer A pick up B and sends confirm to B. at the same time, it creates a server socket to listen to connection. After Compute B receives the confirm from A, it creates a client socket to connects to A.

I set timeouts to both request and confirm packets. If no response is received by A after timeout, A needs to flood a new request packet again. Otherwise, A cancels timeout of the request. For the same reason, if B does not connect to A, A will send a confirm to C so that C can connect to A

My Questions: How to set timeout?
a. I can use select(). But since I already put a select() with timeout parameter as NULL in a while loop to monitor stdio, request, confirm/response packets, it seems that there is no place to put other selects with timeout parameters。
b. I can use alarm(). But there is no way to know, which request/confirm of which file the alarm() is for. And if I cancle a timeout using alarm(0), other timeout using alarm() is also canceled.
c. I also thought about using fork（）+ select() or alarm: But after the child process is terminated, how do I know it is terminated because of timeout or because response or connection is received? Besides, If it is terminated because of timout, In which part of program should I re-flood the request or re-send the confirm packet?
d. maybe I can use SIGALRM to set status in my child process, and use wait()/waitpid? But I do not know where to put waitpid() so that the parent process does not block other process.

I want to solve the problem and need your help. Can any guru answer the question? Thanks

[sicarie]

Sophie000-

I have moved your original question (above). There is no reason to double post (which happens to be against the rules of this site). Please have patience for someone to answer your question.

[RRick]

Select is the function that is usually used for these types of socket problems.

The problem is that select has a global timeout, which means that the application maintains the value.

If your server is idle, and has no clients, then the timeout is NULL.

If you are processing one or more requests, then you need to keep a list of timeout values for each request and update them each time select returns.

For example, lets assume you are waiting for a single client with a timeout of 10 seconds. If a new request comes in after 4 seconds, then you create a client request with a timeout of 10 seconds and send the request out. The existing request must have its timeout adjusted to 6 seconds.

Now you start up select again, with the smallest timeout (i.e. 6 seconds). And away you go.

[Sophie000]

Thanks RRick. I Got it. So I have to create a list that stores all tasks, their corresponding information and their timeout. And it seems that I do not need fork().

Is there other ways to do it? such as interrupt. signal, wait..? Anyway, it is a very good idea to use select() in this way. I never thought it before.

P.S. Sorry for duplicating my article in two broads since I thought the forum leader wanted me to move to another broad.

[RRick]

You don't want to use signals (like alarm) unless you really know what you are doing. Signals and select and IO generally don't mix very well. There are lots of caveats and each platform is different.

Fork/exec creates a new process and this is a another common approach to socket communication. Now you can have multiple selects running and they don't get in the way of each other. You just have to make sure that you can complete the task at hand in a single executable.

One downside to forking is the time it takes to start a new process. The process creation time can be longer than it takes to complete the task.

[Sophie000]

Based on my understanding, we use select() to monitor multiple tasks which are TO BE DONE. And when these tasks are BEING DONE, in order to avoid them from blocking other tasks, we can set the sockets of these tasks as non-block before using them. My questions are:

1. Why some examples I saw use select() + block-based socket mode and some others are select() + non-block-based socket, why not just using select() + non-block-based socket?
2. Suppose one socket is doing send() but TCP buffer is full, if we use select() + block-based socket mode, then send() will block. If finally send() fails, error is reported. While if we use select() + non-block-based socket mode, when data is waiting to be moved to TCP, computer will execute other tasks and let kernel to keep on moving data to TCP buffer. In this case, if send() finally fail, where does computer catch error?

[RRick]

As for #2, don't expect select to fix problems with send and other IO routines. The problem you describe is an IO deadlock situation between two processes and select won't/can't solve it.

Your protocol (i.e. comunication between 2 processes) has to deal with situations like this and make sure the buffers are dealt with in a timely manner. I like to think of the bare socket communication as a "Wild West" scenario. Anything goes and anything can happen! Its up to you to control the situation.

[Sophie000]

It is very kind of you to answer me so many question. I appreciate it.
Would please let me know if I have understood your meaning:

suppose I have a select() in loop:
while(1){
...
select();
...
if(...){
recv a response packet from a remote server
connect(sockfd, &remove_server, sizeof(remote_server));
...
}
}
unfortunately, the remote server is busy with a lot of other connections and it does not have time to accept my connection. If sockfd is non-blocked, then this connection not be blocked. And later on, nobody wiil know if it is finally connected or gives up?

[Sophie000]

And it is my work to design the code to catch the result? I do not have good idea how to solve it. Maybe in this case, blocked socket is better.

It is very kind of you to answer me so many question. I appreciate it.
Would please let me know if I have understood your meaning:

suppose I have a select() in loop:
while(1){
...
select();
...
if(...){
recv a response packet from a remote server
connect(sockfd, &remove_server, sizeof(remote_server));
...
}
}
unfortunately, the remote server is busy with a lot of other connections and it does not have time to accept my connection. If sockfd is non-blocked, then this connection not be blocked. And later on, nobody wiil know if it is finally connected or gives up?