dcclib, a client library for DirectConnect

or

Reinventing the DirectConnect client wheel

As with so many other things, this happened because of a need and of a lack of understanding. I needed to get my hands on a good enough DirectConnect client and Google gave me DCLIB with its DCGui-Qt. DCGui-Qt, in its latest version (at the time of writing), depends on Qt-3.x or higher and I have a system with Qt-2.1 installed. Since upgrading Qt isn't an option (it would mean to upgrade my glibc first), I decided to try to use DCLIB to write a simple and barebones command line client.

After spending a couple of hours per day for a couple of days trying to understand the design and inner workings of DCLIB, I finally decided to rewrite everything from scratch in C and drop the threads and singletons and whatnots that lurked in the C++ entrails of DCLIB and made things too complicated. After less time than I had spent on trying to understand DCLIB I had something that could shake hands with a DC-hub and inject passive searches.

After a few more days I had a message queue connected to the hub structure and a really simple client could use these messages to display everything needed to initiate a search, collect the replies and start a download. It took a day to get the client to client handshaking to work and I did a little dance when the first file had been downloaded.

I have also developed a simple GUI on top of the library.

From there on, it's all about features and a simple matter of programming. ;)

Structure and capabilities of the library

The library relies on two select loops, one for connected hubs and one for connected clients. The application that uses the library can choose freely how often these loops should be run and then check for messages to see what happened.

The library can deliver seven types of messages to the client application:

MESSAGE_OPLIST, a list of who are operators on the hub
MESSAGE_NICKLIST, a list of the nicks of all users on the hub
MESSAGE_CLIENT_INFO, when a user logs on or updates his info
MESSAGE_QUIT, when a user leaves the hub
MESSAGE_SEARCHREPLY_PASSIVE, replies to the passive searches done by the client
MESSAGE_CHAT, whatever the hub has to say as a welcome message or security notification and what other users send as chat to the hub
MESSAGE_CHAT_PRIVATE, private chat from another user

The library can, at this time, send 17 types of commands:

dc_send_lock
dc_send_key
dc_send_key_client
dc_send_mynick
dc_send_direction
dc_send_get
dc_send_send
dc_send_canceled
dc_send_validatenick
dc_send_version
dc_send_getnicklist
dc_send_myinfo
dc_send_search_passive
dc_send_connecttome
dc_send_revconnecttome
dc_send_chat
dc_send_to

It is worth noting that only passive searches are possible at the moment. Active searches requiers one listener that can read UDP packages and one listener to handle the TCP connections and do the file up- and downloading. Since I protect my computer with a firewall and only have port 22 and 80 open for connections from the outside, active searches is something of a future feature.

DirectConnect protocol handling

The library can understand and handle the most important parts of the DirectConnect protocol. As of now, the following commands/tokens are understood:

$Lock
$Key
$HubName
$HubTopic
$ValidateNick
$ValidateDenide
$LogedIn
$Hello
$ForceMove
$Version
$GetNickList
$MyINFO
$NickList
$OpList
$Search (passive with "Hub:")
$SR
$Quit
$ConnectToMe
$RevConnectToMe
$MyNick
$Direction
$Download
$MaxedOut
$Error
$Send
$Get
$FileLength
$Canceled
$To:
$From:
< > (chat)

Any weird spellings of the protocol tokens are there because the protocol is written that way. Do not ask me why it is permitted to continue and propagate with every new client. There is work done to try to flesh out the next generation of the DirectConnect protocol but I guess people just thinks "It works, don't try to fix it because it might break." and continues to use what they've got as long as it works good enough.

Reflections regarding DirectConnect and my implementation

DirectConnect looks like something that came out of the wrong end of several really heavy keg parties. With that said, I can only agree with the people that are working on a revised protocol that it is badly needed and that it should have been done the day before yesterday. The lack of control of who sent what when as a reply to what regarding what makes the whole thing a bit unsteady if anyone on a hub is the least bit malicious. If everybody plays according to the rules stipulated in the protocol specifications things work most of the time but that really isn't enough if you ask me.

In my own implementation I try to go by the book and I end up with something fast that easily fills my 4.3MBit ADSL line with joyful "entertainment data" even when compiled without any special optimization. I didn't really aim for streamlining but it seems like it got to be like that anyways so I will try to tread carefully if I end up adding more features.

Features available now

After making things work on a somewhat basic level, I ended up adding some features. When I think I should do that, I guess I can say that I am pretty close to done. ;)

Resume of old downloads (dcclib)
Update of the number of users logged on to the hub (GTK client)
An actual transfer control window (GTK client)

Future improvements and features

Some parts of the library would benefit from some inspection and perhaps a slight rewrite to make things a bit more consistent. I also think that if anyone is going to be able to use this, besides myself that is, it has to be documented and broken into some smaller parts. Right now, everything resides in four files, dcclib.c, dcclib.h, protocol.c and protocol.h. That is 66292 bytes of undocumented slosh (but with error handling) and I think that might be hard to digest for any casual developer wanting to use it.

These are the specific features that I can think of now that might be interesting to add:

Active searches (this includes listeners)
Configuration options (where to save files, nicks on different hubs, hub info and the such)
Replies to other people's searches (I just discard them now and that is related to the next feature)
Handling of local files to be able to share files with other users

Since I wrote this library to be able to download files and not for sharing files most of these features won't make it into existing unless I get really motivated.