Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Logging on to Internet Relay Chat (IRC)

This month's simple and incredibly small tool lets your applications write output to IRC

By Thomas E. Davis, JavaWorld.com, 10/20/99

In the first couple installments of this column, I alluded to revisiting an object pooling discussion I started back in June 1998. I was going to explain how to build a better pooling mechanism by using a combination of certain tools more recently discussed here. However, plans have changed. Other pooling discussions have surfaced (see the Resources section below) and, with Java 2's rising popularity, my design is no longer avant-garde. Thus, I won't revisit this issue; instead, I'll discuss how you can log on to IRC in order to monitor your application's debugging output.

An introduction to IRC

Internet Relay Chat (IRC) was once the de facto standard for realtime communications on the Internet. In a nutshell, there are IRC clients and IRC servers; you use a client to connect to a server. Once you are connected, you can join (or create) a channel. Other clients that enter the same channel may converse with each other via text messages broadcast by the server. The standard protocol for client/server communication is defined in Request for Comments (RFC) 1459 (see Resources).

Why log on to a channel?

A few years back, I was working on a project in which we had to remotely deploy a service whose output had to be monitored in realtime. Our biggest debate was over the method by which we would receive the service's output. We could have built our own multithreaded server-socket modules into the service so that we could connect to it via a home-brewed client and monitor its status. Back then, there wasn't much Java library support for standards like SNMP. By rolling our own solution, and essentially reinventing the wheel (a major software development faux pas), we would have created a maintenance nightmare. The protocol and service would have eventually been hacked, requiring us to rearchitect and redeploy the project.

My solution was to tackle the problem from the other side. What if the service initiated the connection? What if the service acted as a client to an already established standard? This would alleviate most of the headache. We wouldn't have to worry about designing and coding a multithreaded socket-monitoring server, which would use precious CPU cycles and inevitably turn into a security-maintenance issue.

We already had an IRC server set up so that telecommuters could electronically attend internal company meetings. My idea was to have the service connect to our IRC server, join a channel, and log its output. Thus, whenever we needed to check on the service's status, all we had to do was load up our favorite IRC client application, connect to the IRC server, and join the channel to which the service was sending its output. It worked out beautifully. It's been in production almost three years now and we've deployed half a dozen different types of services using the same solution.

Trimming the fat

To keep the examples simple and this article short, I have severely trimmed down the tool. The original version -- a mission-critical module -- had to be able to deal with server disconnections, network outages, channel management, and so forth. The version I will present to you simply demonstrates how to connect to the IRC server, join a channel, and dump some output. I leave the advanced features as an exercise for you.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.