Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connecting timeout issue #116

Open
ghost opened this issue Jul 11, 2021 · 3 comments
Open

Connecting timeout issue #116

ghost opened this issue Jul 11, 2021 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@ghost
Copy link

ghost commented Jul 11, 2021

Dear Kirc Staff:

I would like to suggest a small modification. It does appear that in some cases kirc gets stuck while trying to connect to a remote host that may have strong firewall policies. I can think of this example:

./kirc -s www.google.com -n test

Kirc will be hanged and will wait for remote host response for a very long period of time. I recommend the following solutions (requires including <sys/time.h>):

Adding in line 669:

struct timeval timeout;
timeout.tv_sec = 3;
timeout.tv_usec = 0;

where a timeout of 3 seconds is set, and then adding the following to line 680:

setsockopt(conn, SOL_SOCKET, SO_SNDTIMEO, &timeout, sizeof(struct timeval));

This will cause Kirc to exit and display an error message as a connecting timeout of 3 seconds is reached.

I'm open to feedback or ideas, and certainly discuss further if this is not a proper solution.

@mcpcpc mcpcpc self-assigned this Jul 12, 2021
@mcpcpc mcpcpc added the enhancement New feature or request label Jul 12, 2021
@mcpcpc
Copy link
Owner

mcpcpc commented Jul 12, 2021

Hi Carlos,

I think it's a reasonable solution. I am not sure about the timeout of 3 seconds though... we may want to increase that.

-mcpcpc

@mcpcpc
Copy link
Owner

mcpcpc commented Jul 26, 2021

Hi Carlos,

I apologize for the updates that have been far and few in between. After having spent a little time looking over this issue, I have come to the conclusion to not use setsockopt() due to portability concerns. In fact, implementing this solution makes no difference in my development environment (e.g. the timeout is ~3sec regardless of the setting for timeout.tv_usec). The most robust solution I can think of would be to (1) create the socket connection (2) set the fd to non-blocking mode and (3) use poll() to check this status of the fd and see if some predetermined timeout condition is met.

More to come in the next week or two... I figured I owed some explanation for the delay. =S

@ghost
Copy link
Author

ghost commented Jul 26, 2021

Thanks for responding, Michael.

What you propose sounds like a better approach, certainly.
I will be following this issue!

Have a great week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant