#21 handle reconnect better

[Will Pierce]

instead of re-exec()'ing the bot when the server dumps us, we should be smarter and actually reconnect the oscar connection.

I would then be able to maintain much more state between restarts without being persistent for some things (like history which is surprisingly more complex than it feels like it oughta be)

[Will Pierce]

Logged In: YES
user_id=1979544
Originator: YES

hmm, how to set up a test env for this...
maybe i could set up a bot to connect to a local port, and use netcat as a tcp proxy to the aim server? then kill netcat to simulate a server/network drop, and then either wait to restart it (simulate extended downtime), or immediately restart it (immediate reconnect).

challenges may be in avoiding the "connecting too frequently" limitation from the server, so i need to keep track of the RATE of connect()s to aim, and self-rate-limit so I don't trigger that problem.

[Will Pierce]

Logged In: YES
user_id=1979544
Originator: YES

also, need to ensure i can clean up the Net::OSCAR object... and ensure i don't have any global references, and also clean up the user state to reflect an unknown/offline state... hmm. that internal user class is looking more and more necessary now.

[Will Pierce]

Logged In: YES
user_id=1979544
Originator: YES

Here's how to do it with netcat and a pipe file (mknod):
rm backpipe; mknod backpipe p; nc -l 5190 0<backpipe | nc login.oscar.aol.com 5190 2>&1 1>backpipe

then telnet localhost 5190 will connect you to the aim server... the server wont wait forever for the aim connection protocol from a client after you issue this command, so it's not 100% perfect

a better way is to do this through inetd, and have it spawn nc login.oscar.aol.com 5190 on connections to the local port 5190, but that's a bit more risky since it effectively becomes an anonymizing proxy - if you forget to shut it down, you could become a relay for IM spammers.