Upcoming changes to hyperion, our ircd software

We’re working on rolling out some new changes to hyperion, our ircd software. If everything goes well, we should be running with these changes in a few weeks. However, you should note that we’re releasing these changes as hyperion 1.0.3, and we don’t particularly encourage any other networks to try to run this code (there are better, more modern ircd software out there). In addition, hyperion 1.0.3 will probably be the last release we make of hyperion. (We are collaborating with Stuart Walsh and TJ Fontaine, the authors of oftc-hybrid which have some great ideas for a next generation ircd tree for freenode!)

This update will add some fairly modern features to the ircd’s I/O engine to allow it to operate more efficiently and fix a few internal bugs that have been noticed during the run of hyperion 1.0.2b. These changes will be going live on a testnet in the next few days most likely, at which point I will write another post with information on how to play around on the freenode testnet with the updated ircd code.

We have also added support for a commonly requested feature, CALLERID (umode +g, server side ignore) in this update, and we have added support for the NETWORK property in our 005 numeric (IRC client authors will probably be thrilled). We have also implemented support for the Linux epoll mechanism, which may provide a marginal performance boost on some of our client servers.

If anyone else has any suggestions or bugs, please note them as comments to this story or come discuss it in #hyperion. We would love to hear your feedback. The more technically inclined can download the in-progress 1.0.3 working tree from our subversion repository at http://svn.freenode.net/hyperion/trunk.

4 thoughts on “Upcoming changes to hyperion, our ircd software

  1. Unreal contains a lot of features we don’t need or want and is too monolithic (I mean carbonite solid) to adapt to our needs. In addition, the I/O code needs an entire overhaul — it’s sad to say, but hyperion’s is actually easier to work with.

    Additionally, the Unreal server protocol is too unreliable, and Unreal has never been proven to be scalable up to the amount of users we deal with on a day to day basis.

  2. I happen to sit on #inspircd. It’s a great IRCd, however, it is too new and not yet proven for networks the size of freenode.

    As I said, the current plan is to go with hybrid along with OFTC and develop a new ircd based on hybrid in tandem. Hybrid has been chosen due to the fact that it’s so old that most of the bugs are either known about or have been fixed up.

    As a sidestep, heavily modular ircds probably will not scale very well to our specific requirements. Freenode processes a lot of messages per second, and as such symbol table lookups in a dynamic module may provide a major performance penalty.

Comments are closed.