exio4 / ipoirc Goto Github PK

The IRC connection somewhats doesn't even properly starts

It should reconnect in those cases, or at least gracefully exit.

IPoIRC actually needs to run in a priviliged user to be able to alloc the tun

ATM IPoIRC uses a hardcoded Makefile, it should be able to be compiled (without changes) on non-debian systems (libdumbnet/libdnet), and use something like CMake to the dependency checking and so.

Freenode and others network actually kill (or throtle) users/connections that PRIVMSG a lot of messages in some small amount of time, IPoIRC should try to avoid it (if some-option is enabled)

There should be a way to make it realize the handshakes and related stuff under a query with other master bot instead of a channel, more like a stealth mode, would need #2 fixed with it.

rework the "tun threads" a bit and somewhat hardcode stuff about it, it is a special case when doing this. (only one tun thread)

this should include a rework in the internal protocol (zeromq-based) to be able to allow >1 client to 1 server (where the tun sends one string and ONE irc thread sends it to the irc-network)

this depends of #2 somewhat, as if this gets implemented right now, it would cause a mess with some irc thread receiving data from other and relaying it back to the tun itself

edit
now this is half-implemented, now it need #2 fixed and implement basic things for the "living" of the different instances of the same bot in the same channel

IPoIRC should be able to handle an external config file, and use getopt to deal with the username, network, etc

There are a lot of places (like the main function) where we alloc stuff and never gets deleted, or places where it crashes instead of checking if the data was properly alloced.

Implement somewhat a way to protect the bot of receiving/allowing base64 from everywhere.

IRC threads are using pointers in an unsafe way (specially the irc session pointer)

This meaning, an IRC thread might try to write to an invalid IRC session if it was invalidated (e.g. disconnection) in another thread, and it didn't reconnect in time.

A possible solution might be to lock the IRC session on those "critical" sections

A (possible) list of things which need some love/work:

• ltun_t
  • moving ltun to a self-contained class may be nice
• confuse -> yaml-cpplua
  • confuse relies on mutable literal strings, iow, it's not valid C++11 code 😕
• switch away from raw PCRE and use C++11's regex library
• remove uthash dependency (replacing it with std::map)
• make base64.cxx work with C++ data structures
• replace char* with std::string where possible (channel names, etc, interacting with the C library using c_str)
  • this would reduce the need of gotos
• replace? the IRC library with something more C++11-friendly (function pointers and explicit wrapping isn't very C++11-ish, we have std::function dammit!)
• zeromq
  • replace? it with a concurrent queue which has a max number of elements.
    • just a wrapper over std::queue with extra lockss
    • it should keep the round-robin behavior of zeromq (or improve the "fairness" by looking at packets sizes)
  • maybe zeromq doesn't need to be replaced at all?
  • this could solve the anti-flood issues, and maybe having a timeout (of certain ms) would allow us to drop packets
• modules
  • replacing the irc_, tun_ stuff with a centralized interface which classes have to implement, thus simplifying the multiple-protocol support
    • now, which methods should that interface have? that's the hard part..
• find a place to use boost even though it's completely unnecessary

Related to #6, implement a way to quit the bot with some internal packet? (fix #2 first though), or signal handling (SIGINT/SIGTERM)