3 ms·

Just a small bit of polite anecdata, but I've fled IRC partly due to some pretty extreme quality-of-service problems - and these were on the major servers and c

by Jetrel 6y ago

Just a small bit of polite anecdata, but I've fled IRC partly due to some pretty extreme quality-of-service problems - and these were on the major servers and communities that were really the only raison d'etre for using it in the first place - things like Freenode and stuff. Basically we had a lot of cases of silent failure where messages would completely fail to go through, and this led to some pretty nasty social awkwardness, because there was no indication the service wasn't being 100% reliable. I only ever discovered it after several years, when I had a bouncer logged in from a rather different network address, and it was pretty terrifying how much was getting dropped (sometimes up to 10% of messages - although usually it was "periodic" failures where a whole conversation would essentially be dead for one side. I observed this over several months, and it was just mindblowing. It was the silent failure that was the most insidious thing - there was absolutely no indication things weren't working perfectly, and it was only after we discovered this that we had the horrible realization that all of those communication problems we had in the past were not because individual "people" were bad communicators (or were ignoring you, being rude, etc), but because they genuinely weren't receiving entire paragraphs of text. At random, with no indication anything was dropped. There are a lot of other extreme frustrations we had with IRC, but this "hidden QoS problem" was the last straw. A lot of the work we were trying to coordinate on it (gamedev stuff) involves more than just text, and just trying to share images across the thing constantly felt like being a second-class citizen (manually uploading something to an FTP when even AIM/MSN could transfer stuff no problem with a copy-paste). The fact that I was forced to use it for over a decade ... I've lost thousands of manhours of my life fighting with it when almost any modern tech stack would have avoiding those particular wastes of time, and that's just something I can't forgive. As irrational as it may be to do so - I can't help but hate it. :(

bArray 6y ago
Dropping messages is something that should notify you - in the raw protocol this is entirely possible, so it's just something that needs to be added to the client. The problem of adding files is something that it would be nice to solve, I think in general the IRC servers themselves wouldn't want to potentially sacrifice the ability to handle text whilst being overloaded with attachments. It feels like something that could be solved with a third party server and a client that supports it, with a short-ish TTL to keep the server freed up. Receiving side it would simply be a case of opening a link or deciding if the content can be displayed inline. I quite like not being available when I'm offline. I don't want to logon to have a quadrillion messages to read back through - most out of date and don't concern me. We have email for this kind of thing.
- progval 6y ago
  > Dropping messages is something that should notify you There is an IRCv3 extension to get an acknowledgement the server received your message: https://ircv3.net/specs/extensions/echo-message-3.2 https://ircv3.net/specs/extensions/echo-message-3.2 > It feels like something that could be solved with a third party server and a client that supports it Some IRC clients, such as IRCCloud or the Matrix bridge already do this.
Arnavion 6y ago
Sounds like your client wasn't configured to send periodic PINGs. Usually you set your client to send a PING every 30-60s, and disconnect if there is no server PONG for two to four times the ping interval. That way you have an upper bound on what messages from you may not have reached the server. (IRC is over TCP, so if a server sends a PONG for a PING, then every message you sent before that PING has reached the server.)
- rtpg 6y ago
  This is unlikely to be the case. Almost all servers out there require fairly frequent ping/pongs and if your client doesn't work right it'll just be entirely unusable (like "disconnect every 5 minutes")
  - caf 6y ago
    IRC servers do not require PINGs from the client. What they typically require is a message of some sort sent regularly from the client, and if they haven't received anything in a while, they'll send a PING to elicit a response from the client (if it's still alive). Most servers don't even check that the PONG matches the PING they sent, they're just happy to get something back before the timeout, although there are servers that send a cookie in a PING at connect time that they require to be reflected back correctly as a countermeasure for certain kinds of proxy abuse. For example, EPIC is one of the oldest clients and it doesn't send its own PING messages unless scripted to do so, and it works fine.
    - bArray 6y ago
      > although there are servers that send a cookie in a PING at > connect time that they require to be reflected back > correctly as a countermeasure for certain kinds of proxy > abuse. That tripped me up when writing an IRC bot - it worked on many servers but failed on one particular server that sent the PING cookies.
    - rtpg 6y ago
      I stand corrected, I might be misremembering experiences from trying to write IRC boys, like sibling. Thanks for the clarification
numpad0 6y ago
Things are starting to sound to me like if there was an authenticated HTTP “endpoint” that juuust echo $line >> www-root/channel/latest.log, then that could replace ~80% of all intents and purposes of Slack and IRC and Wiki with million-fold resource savings...
- 6510 6y ago
  A unix timestamp in the url dropping the last few digits. Or no wait, we need to invent a kind of paper that you can write on with a pen and have it magically mirrored on n similar paper documents.
dijit 6y ago
I run an IRC network (this one: ircs://irc.darkscience.net/darkscience) and there are shortcomings with the protocol for sure. I've been a staunch advocate for IRC for a while, but the truth of it is that there's nothing built-in for reliability. It assumes reliability from TCP. If the TCP connection is interrupted, you will be disconnected. If a route on the internet changes, you will start losing incoming and outgoing traffic; and you will be kicked from the server with a ping timeout. Losing messages shouldn't be possible without a route change on the internet that drops state, but I suppose if there is a leaky bucket style buffer cache somewhere in the pipeline it could happen? In a similar vein; mattermost, when I ran it, would deliver messages out of order or not at all- I believe this was caused by nginx and a limited amount of buffer caches. I suspect that the reason slack forces you to use their client is because they're working around protocol limitations like this with retry logic, because I've had messages not delivered with programs like wee_slack or my python bot (which thinks it delivered the message). Anyway, if you want a more reliable connection for IRC there is RobustIRC which alters the protocol to be more reliable. Also ircv3 extensions largely attempt to solve issues inherent with relying solely on tcp.

by Jetrel 6y ago

bArray 6y ago

Dropping messages is something that should notify you - in the raw protocol this is entirely possible, so it's just something that needs to be added to the client. The problem of adding files is something that it would be nice to solve, I think in general the IRC servers themselves wouldn't want to potentially sacrifice the ability to handle text whilst being overloaded with attachments. It feels like something that could be solved with a third party server and a client that supports it, with a short-ish TTL to keep the server freed up. Receiving side it would simply be a case of opening a link or deciding if the content can be displayed inline. I quite like not being available when I'm offline. I don't want to logon to have a quadrillion messages to read back through - most out of date and don't concern me. We have email for this kind of thing.

progval 6y ago
> Dropping messages is something that should notify you There is an IRCv3 extension to get an acknowledgement the server received your message: https://ircv3.net/specs/extensions/echo-message-3.2 https://ircv3.net/specs/extensions/echo-message-3.2 > It feels like something that could be solved with a third party server and a client that supports it Some IRC clients, such as IRCCloud or the Matrix bridge already do this.

Arnavion 6y ago

Sounds like your client wasn't configured to send periodic PINGs. Usually you set your client to send a PING every 30-60s, and disconnect if there is no server PONG for two to four times the ping interval. That way you have an upper bound on what messages from you may not have reached the server. (IRC is over TCP, so if a server sends a PONG for a PING, then every message you sent before that PING has reached the server.)

rtpg 6y ago
This is unlikely to be the case. Almost all servers out there require fairly frequent ping/pongs and if your client doesn't work right it'll just be entirely unusable (like "disconnect every 5 minutes")
- caf 6y ago
  IRC servers do not require PINGs from the client. What they typically require is a message of some sort sent regularly from the client, and if they haven't received anything in a while, they'll send a PING to elicit a response from the client (if it's still alive). Most servers don't even check that the PONG matches the PING they sent, they're just happy to get something back before the timeout, although there are servers that send a cookie in a PING at connect time that they require to be reflected back correctly as a countermeasure for certain kinds of proxy abuse. For example, EPIC is one of the oldest clients and it doesn't send its own PING messages unless scripted to do so, and it works fine.
  - bArray 6y ago
    > although there are servers that send a cookie in a PING at > connect time that they require to be reflected back > correctly as a countermeasure for certain kinds of proxy > abuse. That tripped me up when writing an IRC bot - it worked on many servers but failed on one particular server that sent the PING cookies.
  - rtpg 6y ago
    I stand corrected, I might be misremembering experiences from trying to write IRC boys, like sibling. Thanks for the clarification

numpad0 6y ago

Things are starting to sound to me like if there was an authenticated HTTP “endpoint” that juuust echo $line >> www-root/channel/latest.log, then that could replace ~80% of all intents and purposes of Slack and IRC and Wiki with million-fold resource savings...

6510 6y ago
A unix timestamp in the url dropping the last few digits. Or no wait, we need to invent a kind of paper that you can write on with a pen and have it magically mirrored on n similar paper documents.

dijit 6y ago

I run an IRC network (this one: ircs://irc.darkscience.net/darkscience) and there are shortcomings with the protocol for sure. I've been a staunch advocate for IRC for a while, but the truth of it is that there's nothing built-in for reliability. It assumes reliability from TCP. If the TCP connection is interrupted, you will be disconnected. If a route on the internet changes, you will start losing incoming and outgoing traffic; and you will be kicked from the server with a ping timeout. Losing messages shouldn't be possible without a route change on the internet that drops state, but I suppose if there is a leaky bucket style buffer cache somewhere in the pipeline it could happen? In a similar vein; mattermost, when I ran it, would deliver messages out of order or not at all- I believe this was caused by nginx and a limited amount of buffer caches. I suspect that the reason slack forces you to use their client is because they're working around protocol limitations like this with retry logic, because I've had messages not delivered with programs like wee_slack or my python bot (which thinks it delivered the message). Anyway, if you want a more reliable connection for IRC there is RobustIRC which alters the protocol to be more reliable. Also ircv3 extensions largely attempt to solve issues inherent with relying solely on tcp.