View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004040 | unreal | ircd | public | 2011-08-11 17:17 | 2012-02-26 21:45 |
| Reporter | somenet | Assigned To | syzop | ||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.9-RC1 | ||||
| Summary | 0004040: remove: class::pingfreq should be a reasonable value (30-600) | ||||
| Description | please remove this restriction. I have users that use mobile dialup and have sometimes much higher spikes. my current pingfreq is 1800. | ||||
| 3rd party modules | |||||
|
|
This is not a bug, so it can't be "major". It's a feature request. Second a pingfreq of 1800 is 30 minutes! That's no where near reasonable and if you have clients that need such settings they need to complain to their ISP because being connected to an irc server is the least of their worries. |
|
|
functionality that was there has ceased working: so its imho a regression or a bug. > pingfreq of 1800 is 30 minutes! That's no where near reasonable... If you take into account, that on most (if not all) linux-firewalls TCP-Established timeouts after 5 *DAYS* a pingfreq of 1800 pretty much *IS* reasonable and i dont see why an ircd should limit the admin's choices, just because most users will go for small values. And about the clients themselves: they run a local proxy and most of their daily internet activities work acceptable, however they have sometimes spikes for some minutes. Its not that they did not complain, but you know... it would be a little expensive to lay a wired line somewhere thru the mountains... and setting the pingfreq to 1800 made their problems go away. |
|
|
You are comparing apples to oranges. Firewalls and mail servers have timeouts measured in days, but even web servers, ssh sessions(when thus configured), dns, trace and most all other protocols have timeouts measured in seconds. None of the above have the same time sensitive demands of IRC. IRC considers 6+ seconds as latency and many people consider 6 seconds unacceptable. I doubt many, if any, people will watch a seemingly dead channel for 30+ minutes only to find they pinged out 25 minutes ago. In fact, most scripts that have any form of lag meter built in ping the server every few seconds or less. It's not reasonable to expect IRC servers to go so long without liveliness. The protocol just simply isn't designed to be used that way. My fear is that it can cause undesired results at the network level including but not limited to rogue ghosts. |
|
|
talk about comparing apples to oranges... * Web servers (HTTP(S)) is a connectionLESS protocol unlike IRC, XMPP, ICQ, ... * DNS is not even using TCP if not required. * OpenSSH (which is the most widely used SSH implementation) doesnt even HAVE an option to set a connection timeout - as this would not make any sense by protocol design. (in b4 keep-alive messages) - there is ClientAlive*, which is NOT enabled by default AND setting the 2 options to 1800 and 100 did not made sshd unstartable. Now if you wanna say "$server mesures timeouts in seconds, if configured" im gonna respond with "yes, but it DOESNT NEED to be configured, if the admin doesnt want it" >It's not reasonable to expect IRC servers to go so long without liveliness. Please point me to the paragraph @ RFC ... oh there is nothing? how come? >The protocol just simply isn't designed to be used that way. what way? with longer waining for clients? It can do absolutely NO harm, as this is client <-> server stuff. >My fear is that it can cause Thee who know nothing have to beleave and fear. srsly, please stop arguing, your arguments make no sense. Can we summerize that as: all of your technical arguments are invalid? Nice. Now the social one: Yes, there are many people, who use scripts and consider anything above 6 sec unbearable. (me too sometimes) But does that allow you (or me) to DENY COMMUNITACTION to those who have nothing else than to cope with it? IMHO: NO. Also if ppl in a channel know (or share the same fate), that some others can have spikes and that they will respond later, ppl talk in longer sentences, allways referencing what they respond to AND IT WORKS. It is one of our nicest and relaxed channels, as noone will ever flood and noone will write anything out of context. srsly, you might dont like 6+ sec lags, but that gives you NO RIGHT to force your opinions on others. I filed a bug that a max pingfreq of 600 is unreasonably small. Please stop trying to convince me, that it is not because you said so (your technical arguments are void) The undenyable effect of the now forcefully decreased pingfreq is obvious: ppl are getting slowly frustrated. |
|
|
To be honest, I find a 1800s ping timeout rather, insane, by lack of a better word. A pingfreq of 1800 means that a connection may be held for up to an hour (or 59m59s)! We would have a lot of problems with users setting pingfreq too high if we would max it at that. If you really have clients whose connection goes down for like half an hour, wouldn't some kind of BNC service be better suited? If we up the current limit from 600 to 900, would that help? |
|
|
Set the priority to normal (from high) and the severity to tweak (from major). |
|
|
Doesn't sound like this change would make much sense. I'll stick with the current max of 600. Having dead users online for up to 1200 seconds (20 minutes) is bad enough. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-08-11 17:17 | somenet | New Issue | |
| 2011-08-15 04:00 | katsklaw | Note Added: 0016741 | |
| 2011-08-15 20:29 | somenet | Note Added: 0016742 | |
| 2011-08-15 20:31 | somenet | Note Edited: 0016742 | |
| 2011-08-15 20:32 | somenet | Note Edited: 0016742 | |
| 2011-08-15 20:32 | somenet | Note Edited: 0016742 | |
| 2011-08-20 00:30 | katsklaw | Note Added: 0016743 | |
| 2011-08-20 00:32 | katsklaw | Note Edited: 0016743 | |
| 2011-08-20 01:48 | somenet | Note Added: 0016744 | |
| 2011-09-26 19:22 | syzop | Note Added: 0016752 | |
| 2011-10-30 22:30 | Stealth | Note Added: 0016765 | |
| 2011-10-30 22:30 | Stealth | Priority | high => normal |
| 2011-10-30 22:30 | Stealth | Severity | major => tweak |
| 2012-02-26 21:45 | syzop | Note Added: 0016923 | |
| 2012-02-26 21:45 | syzop | Status | new => closed |
| 2012-02-26 21:45 | syzop | Assigned To | => syzop |
| 2012-02-26 21:45 | syzop | Resolution | open => no change required |
