Re: Preventing ERC automated channel disconnects

[Bob Proulx <bob@proulx.com>]

Alan Schmitt wrote:
> Bob Proulx writes:
> > I use an irc bouncer proxy to maintain a persistent connection.
> 
> I did not know about IRC bouncers, so I looked it up, and I really like
> the idea

It works pretty well.  It means that on my laptop when I am connected
that I have a local client for my typing instead of the many terrible
high latency WAN connections that I happen to be on at various client
sites.  It means I get a local notification (beep, balloon) when I am
messaged.

The local client connects when it can and retries when it can't.
Without a bouncer it would mean that my account presence would be
coming and going and coming and going all of the time which is
somewhat annoying to others unless I only used a persistent server.
Also when offline I would be unavailable for messaging.  With the
alternative of a persistent remote server I would be suffering from
the terrible network connections I too often work in.

The local notifications are the main advantage I like of using the irc
bouncer.  It allows me to be coordinating with other team members more
effectively when working a problem without needing to be checking
(polling) my remote irc client during the work.

Meanwhile this doesn't remove the advantage of having a persistent
server keeping the session alive.  The advantage there is that my team
members can always message me even when I am offline.  When I come
online I will check my messages and see anything that was sent to me
and be able to respond.  In many ways it makes this more like email.
Generally I prefer email.  But others prefer other things and this is
a compromise that sits between.  And also when the conversation starts
up again it is just normal irc again.

> (I'm currently using weechat in a tmux session on a server to stay
> connected,

I am doing almost the same thing using 'screen' and 'irssi'.  I go
back and forth on using 'mosh' (the mobile shell) or not.  It has some
quirks that one needs to know about, specifically it will leave orphan
processes behind unless you avoid doing so.  But I am back to using it
again and it has advantages if you drive it.

  https://mosh.mit.edu/

If you haven't tried 'mosh' then in your situation I suggest giving it
a try.  It is very clever.  It uses normal ssh to start a UDP
connection for the communication between.  It is specifically designed
for use in high latency, high packet loss, and unreliable networks.
That part it does very well.  That is the main reason I use it and
like it.

But mosh has a basic flaw that it doesn't specifically address.  The
mosh server side creates a persistent presence somewhat like screen and
tmux do.  Which is how it allows you to reconnect seamlessly.  But if
the client side dies while offline nothing ever cleans up that remote
shell.  And since the client has died nothing will ever be able to
connect to that server side of the session again either.  The server
side of the session will be left as an orphan.  Anything running in
that session will hang around and consume memory and resources until
it is manually killed.  Periodically it is a good idea to run a ps
listing and look for orphan processes and clean them up manually.

But here is the trick to avoid it.  Never run a simple shell on the
remote side of a mosh connection.  A simple shell could be left
hanging with no way to reconnect to it.  Instead start up a screen or
tmux session and only use mosh to resume a running screen or tmux.
That way when a new login comes along and resumes the screen / tmux it
will cause the mosh server to see that the process is finished and the
mosh server will exit too.  If you only run mosh resuming screen
sessions then it won't ever leave orphaned processes behind.

  mosh -- myserver.example.com screen -dR

The '--' is needed because 'mosh' also inconveniently looks for its
own options anywhere on the command line.  For a command that runs
other commands that is an unfortunate choice.  Using '--' tells mosh
that it has no more options to the right and the -dR is then passed
through as part of the 'screen -dR' command on the remote system.

For screen the -d option detaches the remote session first so that it
can be re-attached.  Then the -R resumes the unattached session.  Same
as -r but -R starts a session if one is not running.  Resume or start.

I know you said you were using tmux.  I am sure it is similar things
there too.  But I only know screen and therefore I only talked about
screen.

> but it's outside of emacs which is sad).

Which is exactly why I would like to be able to use emacs too.  But at
the moment using erc means that it disconnects everything every time I
use it.  Bad.  (Unless I take extreme measures to cut the network
before it can disconnect, then exit erc while it can't tell the remote
end to leave channels.)  Otherwise I would be using emacs erc as my
irc client.

> Which irc bouncer would you recommend using?

I don't have any specific recommendation.  I happen to be using irssi
because through my route through irc clients it was the one I liked
and was using and irssi also provides an irc bouncer proxy.  Therefore
I happen to be using it.  And the bouncer feature works well enough.
But if someone were wanting *only* an irc bouncer I don't think irssi
is particularly outstanding if that is the only task it is doing.

A good friend of mine is using 'Bip'.  It sounds interesting.  I have
been wanting to set it up and try it.  I think if you were going to
start somewhere that Bip might be a good place to start.  But note
that I haven't tried it yet myself.

Bob