Functional Description Document ICQ-Compatible Server Project Proposal February 12, 1999 Bishop Bettini Derek Jordan Mike Walton Table of Contents Overview..........................................................1 Major Features....................................................2 ICQ Features......................................................4 Demonstration Plan................................................6 Resources Needed..................................................6 Appendices Interaction Diagrams..............................................7 Definitions.......................................................8 Calendar..........................................................9 References.......................................................10 Overview ICQ is a wide-area communication system whose core design is remarkably similar to Athena Zephyrs. ICQ goes a few steps further by integrating direct client-to-client (DCC) email, voice mail, and file transfer capabilities directly into the ICQ client, thus making communication between users more natural and conversational. Since its inception in November of 1996, ICQ, which was derived from the term "I Seek You," has "taken the Internet by storm" according to Mirabilis, Inc. In our research, we discovered that the original, copyrighted ICQ client had been cloned to run on many different platforms, but a compatible server had yet to be cloned. Knowing this and also seeing that the Free Software Foundation's GNU project has such a server listed as one of their needs, we decided to clone the server. Our mission, therefore, is to design and create a free ICQ-compatible server which we hope will be widely distributed to create an option for company-wide messaging systems, and greater deployment of the ICQ system. Our goal is to create a compatible server that provides all of the functionality of the copyrighted server as well as more. Additionally, we will strive to provide extensibility, configurability, localization and internationalization, and most importantly freedom of code. To this end, we have notified GNU of our selection of their ICQ-compatible server need. We have also contacted the ICQ development newsgroup and informed them of our project. Both GNU and ICQ-devel fully support us on this project. Major Features One of the mandates of any GNU software package is portability across UNIXes as well as conformance with a standard operational interface. With these in mind, we have designed our server from the ground up to be portable and to conform to GNU interface standards. This portable, standard interface will aid in the deployment of our server as a network-wide communication facility. We have had to design our server from two sources. First, we looked at the information available in the form of protocol and packet data that the clients expect. We are using this information to build a server that can interface with current clients. There are presently two major versions of the ICQ protocol: version 2 and 4. These versions are in use in all UNIX clients plus the Windows 3.x and Windows 95 clients which predominate the ICQ client market. Because, however, version 4 is sufficiently more complicated than version 2, we will initially support version 2 with plans to migrate to version 4 in the future. We have discovered through our research that new Windows 98 and Windows NT 4.0 clients are using a new version, version 5, of the protocol. Again, this is more complicated than version 4, so we will hold off on supporting the higher version until we have established a solid code base in earlier versions. This is a reasonable decision, as all version 4 and 5 ICQ clients can still communicate with version 2 ICQ servers; we, therefore, will not isolate any users based solely on their clients. Our second source of information came from an analysis of communication systems currently available. We investigated traditional UNIX talk, Athena Zephyrs, and Internet Relay Chat (IRC) servers. From these current systems we picked out a subset of functionality that was compatible with the ICQ methodology and will incorporate them into our server. The particulars of our extra features are described in the "ICQ Features" section. ICQ Features In order for a client to participate on an ICQ network, the client must register at the server. A client begins by sending a UDP "login" packet to the server on the ICQ well-known port, traditionally port 4000 (see Figure 1 in Appendix A). This login packet contains a UIN user identification number (UIN), password, TCP port and other information; in version 2 of the protocol, this information is all sent clear-text. The ICQ server looks up the UIN in its user database and verifies that the password is correct. If the password is invalid, a negative acknowledgement packet is sent back to the client. If the password is valid, a login acknowledgement packet is sent back, after which the client will send its contact list. The server will then lookup the state of each UIN in the contact list from the server's state database and return status information about each UIN in the list. After this point, the client is considered "logged in." The server will, finally, search its notification database and will notify all other clients who are interested in knowing that the given client has logged on. Included in this notification packet is the TCP port that the client listens on for client-to-client (DCC) communications. The client from now on will almost exclusively use DCC communications to talk on the ICQ network (see Figure 2 in Appendix A). The client will send a "keep-alive" packet every so often (up to 3 minutes between packets) to notify the server that it is still there. If more than two "keep-alive" packets fail to arrive, then the server will consider the client offline by silence; this is in opposition to the client specifically sending a "logoff" packet. In general, client-to-client communication (which is beyond the scope of this project) is handled by TCP DCC connections. Client-to-server and vice versa connections are handled by variable length UDP packets. What if, however, the UIN was not found in the user database? We are uncertain of how the current ICQ server system handles this scenario, but presumably it just sends back a "user not found" packet. In our implementation, however, the ICQ server can act as a proxy (see Figure 3 in Appendix A). If the user is not found in its database, then the server will forward the login packet to its forwarding server and ask it. That server can then either return a "login acknowledgment" packet (assuming the UIN is found and the password is valid), or also proxy the packet forward. This setup provides us with extreme flexibility in creating distributed ICQ networks. Under this scenario, no one server has to hold all UIN information. This also allows companies to have a secure intranet ICQ network while still allowing local ICQ clients to participate on the external network. Resources Needed Since one of our major goals is portability across platforms, it will be necessary to have access to many platforms to develop our server. The development of the server will be done on a PC running Slakware Linux 2.x. Additionally, the server will be coded to run on machines running RedHat Linux 5.x, HP-UX 10.x, AIX 3.x.x and 4.x, SunOS 4.x, and Solaris 2.x. At the present time, we have access to all of the resources we need for development and testing. However, for our final presentation we will need access to three computers, each running a different supported operating system, and connected together over a TCP/IP LAN. On one machine, we will compile and run the server. On the other two machines, we will be running a variety of ICQ clients. We will demonstrate the server functionality by logging in and noting that each client becomes visible to the other. Demonstration Plan During our demonstration, we will have multiple clients set-up and our server on a different machine. We will demonstrate how the server saves the messages for offline clients and then how it sends a message out when a new client comes on to all of the other clients that have it on their contact list. Then we will display how the server helps set up a direct connection between two clients. Currently, our plan is to be able to demonstrate these features on different platforms to show our server's ability to handle them, but that will depend on our amount of time and resources we have for the demonstration. Appendix A Interaction Diagrams Fill in pictures Appendix B Definitions Contact list: a list of UIN for which a given client is interested in knowing the status of. DCC: An acronym for direct client-to-client. UIN: An acronym for user identification number. A unique identifier that is assigned to each new user. Similar to a username in conventional UNIX parlance Appendix C Schedule January Fri, 08th: project description Tue, 12th: begin design phase; website created; confer with GNU Wed, 20th: infrastructure coding mostly there Fri, 29th: diagram client-server interaction February Mon, 01st: rough draft of proposal due Tue, 02nd: solidify server design Fri, 05th: draft proposal presentation Tue, 09th: primary messages put in C-struct form Tue, 09th: login packet working; complete client-server negotiation Fri, 12th: final draft of proposal due Fri, 26th: login packet tied in with database; user's contact list is updated March Mon, 01st: multi-user testing possible; version 0.1.0 (alpha) Wed, 03rd: offline message store code in-place Fri, 05th: rough draft of design due Fri, 05th: user state change (login, logout, etc.) sent to other clients Mon, 15th: design presentations begin Fri, 19th: installation works (ie, make install) Mon, 22nd: design presentations end Mon, 22nd: dbm/ndbm code working Wed, 24th: offline message store code works Fri, 26th: final draft of design due Fri, 26th: servers can proxy (ie-mirror) databases Wed, 30th: beta-test coding completed; approx. version 0.1.1 (beta) April Thu, 01st: add alarms where appropriate to receive/send calls Fri, 16th: code robustness, full packet support Mon, 19th: end testing phase Fri, 23rd: projected completion date; version 0.1.2 (release) Fri, 23rd: project documentation due Mon, 26th: final presentations begin Fri, 30th: final presentations end Appendix D References GNU ICQ-compatible Server Homepage [http://www4.ncsu.edu/~cbbettin/gicqd/] This is the website that we have created and currently maintain to describe our project and keep all interested parties up-to-date on it's status and progress. GNU Homepage [http://www.gnu.org/prep/tasks.html] This is the GNU site that has the lists of projects that they wish to be completed. Our project is on this list under the subheading 'Network Projects.' Mirabilis' ICQ Hoempage [http://www.icq.com] This is the home of the original ICQ server. Mirabilis, the company that first created ICQ, describes on this page the history of ICQ, the purpose of it, breaking news, and how to download it. The ICQ Protocol Site [http://www.student.nada.kth.se/~d95-mih/icq/] This is a foreign page that contains a wealth of information on the protocol used by the Mirabilis ICQ client and server, and the different clones that have been written with the same protocol. Meistern's ICQ Hacking Page [http://www.globalserve.net/~jphowe/icq/] This is another page containing information on the protocol used for communication between ICQ clients and servers. Linux ICQ Homepage [http://www.portup.com/~gyandl/icq/index.html] This is a page of ICQ for Linux. It contains links to nine different cloned clients. Mirabilis hasn't created a client for Linux as of yet, so this is a location you can go to download a Linux client. GICQ Site [http://www.korsoft.com/gicq/] This is just a page with some interesting information on ICQ that helps provide some background research.