Re:A major reason for departures at Slack was “remote work r...
by dijit on Monday May 25, 2020 @04:26AM
(#23299166)
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.
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.