Your front-page example

[erikh]

If ping_timeout is not set the connection to freenode will immediately timeout.

Sorry I don't have more bandwidth than to seagull. Perhaps next time! :)

[cemeyer]

Duplicate of #207 , I think.

[erikh]

Not precisely; I figured it out later. In the 0.14.0 crate, no ping timeout is being set. Quite literally setting this to any reasonable value (I used 180, the default in the source code) will work.

[erikh]

I am using Config::default() with a "default" struct and also configuration files; you can find my source code here (it's a mess, I'm new to rust, I'm sorry in advance)

https://code.hollensbe.org/erikh/robutt (it's my name and I like it)

[cemeyer]

Ah, my mistake, sorry. I am also new to rust!

I am also not sure how ::default() is supposed to work, or why this code does not set the 180 we might expect it to:

https://docs.rs/irc/0.14.0/src/irc/client/data/config.rs.html#571-582

My read of it is the Config struct derives the Default trait, which provides ::default(). The derived trait derives default values from the trait in the individual members. Default for ping_timeout: Option<u32> is None, so I'm surprised this doesn't work.

[aatxe]

@cemeyer Your understanding is correct. The issue here is that the default ping timeout is 10 seconds, not 180 seconds as @erikh has suggested. This is too low for freenode's connection process which is... extremely slow for whatever reason. The confusion is between ping_timeout and ping_time which represent different things. ping_time is supposed to indicate how frequently the client sends a ping, and the timeout is how long it will wait to receive a response before considering it a failure.

This problem is exacerbated by the fact that the migration to tokio 0.2 seems to have stopped using ping_time altogether, instead setting the interval to half of the timeout (meaning that the client is, by default, sending a ping every five seconds).

[erikh]

I've examined this a little; I think the proxy scan + VERSION CTCP freenode immediately sends are the issue, perhaps not making the CTCP ping time (a TCP timeout should be different) something that can affect connection until after the MOTD is sent would be best? Maybe an option?

[erikh]

And before you say it; I agree, computers are terrible. :P

[aatxe]

I'm going to close this with the understanding that #222 resolved it, but please let me know if I'm missing something and that isn't the case.

[cemeyer]

Seems plausible to me, thanks!