Direct Connect: Just These Guys, Ya Know?

File information in searches

A frequently requested feature in DC++ is the ability to search for files, and also specify (and get back) certain information about the actual file. (Normally called “metadata”.)

This information is eg the ID3 tag in MP3 files or the author of a Microsoft Word document. That is, information about a file, that isn’t really the content of the file.

The request is quite fine and valid, but it’s going to be quite difficult to implement in a good way.

In NMDC, you can’t send “ohh, by the way, the ID3 tag is this and that” when you’re about to send a search reply. If you’d wanted to do that, you’d have to write a totally new command, since no other client would probably understand your normal search reply.

In ADC, you could add a new parameter to the search, but it’s going to be ugly. If you add a new parameter for ID3 tags, you’re opening yourself up to the query “how about authors in Microsoft Word documents, then?” So, you’ll have to add a parameter for that. And for that other file information. Etc. Etc. Basically, ending up in a huge sea of annoying parameters.

Yes, you could add a new command or parameter that will say “send me everything about the file”. That’s going to a huge overhead in traffic. The hub is going to get so annoyed by the vast amount of bandwidth required to broadcast, that they’re just simply going to kick the clients supporting this. (Yeah, yeah. That’s up to the hubs, sure. But let us face it. Most hubs think of user count; This is going to have a severe impact on that.)

Yes, it’s quite a nifty feature. Yes, I’d like for it to happen with DC(++), too. But likely, the implementation is going to be quite ugly.

(Note: I have no idea how other P2P-networks do it, but I’m sure it’s not so damaging there. Why? Because they’re most likely not centralized, as DC is.)

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

CTM tokens in ADC (or why the NMDC protocol is terrible, part 2)

ADC’s CTM command contains a token parameter. This solves NMDC’s problem of certain client-client connections being only loosely connected with any hub connection, which in turn solves several secondary issues in NMDC, such as inhibited multiple share support; easy nick-faking in client-client connections; and causing a potentially incorrect nick to be returned by the client receiving the C-C connection if nicks alone don’t unambiguously return. I’ll describe these individually in future blog posts, but this one will just focus on the mechanics of the token and how it authenticates a C-C connection to the hub through which it originated.

The potentially easy case, and the one which in any event the NMDC protocol is competent to handle, even if DC++ isn’t necessarily: one can determine what hub a client-client connections spawned from if a client has received a $ConnectToMe/CTM and thus initiates the C-C connection. In such an event, the bookkeeping is entirely local and therefore not in principle dependent on which protocol one uses – if the client trusts that the hub isn’t spoofing the other user’s messages, then it can transfer that information directly, that local socket N was created in response to a CTM from hub H. Any further communication on socket N can therefore be tied unambiguously to hub H.

The remote end of socket N has a more difficult problem, since it must match just a nick – not a hub nor any other information about a user that NMDC reliably transmit – with a hub. This in even theoretically cannot be done without, at best, heuristics. DC++’s works tolerably, but it’s still guessing. A couple of issues exist – that nicks are public information and therefore trivially spoofable and guessable means that there’s no reliable guarantee the client on the other end is even on of the same hubs one’s own client is, undermining the exclusive nature of hubs; and commonly, that a given nick appears on multiple remote hubs. Whether those nicks represent the same user cannot be unambiguously determined [*], so one cannot just assume that any choice of user associated with that nick is as good as any other. Instead, the remove end, which sent the $ConnectToMe, must guess. This historically seems to have stemmed from the original Neo-Modus client not supporting multiple hubs and therefore the protocol behind it not needing at the time to distinguish these conditions, but it isn’t a reliable way to run a P2P network.

ADC’s token solves this problem, and thus the triggered secondary issues, with minimal computation and bandwidth overhead, by involving only the two clients in question and the hub in transferring thusly private and only per-C-C-connection valid information which all parties involved can use to authenticate the origin of the connection, both the hub and specific user.

In order to do so, though, this token should be generated in a manner such that a third party would find it difficult to forge – otherwise several of the previous flaws would reappear. A good random number generator, though ideally with at least 64 independent output bits and suited for cryptographic applications, should suffice.

If this precondition is established, then only the two clients between which the client-client connection will be created and the hub. This precludes, barring the a hub’s potential untrustworthiness [**], either a rogue user unaffiliated with any hubs spoofing a DC client into interacting further with it or a DC client’s being forced to guess which hub a user is from.

[*] Yes, there are multiple ways of attempting to narrow this down. They’re all ugly and unreliable.

[**] Such hubs create more significant problems. SSL certificates avoid them.

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

Don’t hijack me

Or, well, rather /me.

In most IRC-clients, you can use a command usually called /me. You use it when you want to say something in third person. Like “/me like apples”, and it will appear “* joe like apples” if your nick is “joe”. (Other variants exist, but this is probably the most common.)

As this is a chat feature, it also caught attention to DC clients and hubs and their developers.

In NMDC, you can’t say “this is in third person” and then “this isn’t in third person”, because everything is in the latter category. Unless you invent a completely new command to do this, of course. Which would be rather awful. However, some clients and hubs offer this functionality, in a different way.
Hubs can allow this by creating a new command. Like “+me like apples”, which the hub would then send out as “* joe like apples” (as the hub can do pretty much anything it want). This is rather simple, but the problem is that not all hubs allow this. (Either it’s because their software don’t let them, or because they dislike the feature, or just plain don’t know they can do it.)
The clients do it in a different way, which is really ugly. When you write “/me like apples” in your client, the client will send it out exactly like that. Like it’s a standard message. However, when the client see “/me ” beginning someone’s message, they display instead “* joe like apples”. Basically, they’re highjacking the /me; The original user may have intended that as part of their actual message, and not for the “/me”-functionality.

In ADC, you don’t need to hijack the message. Instead, you can simply add a parameter to the message that’s being sent out, and the other client need to show it “* joe like apples”. (You could even have different types of “/me”s in ADC, but I think they’re “restricted” at the moment.) (Yes, I’m aware the protocol state that it should be “*joe like apples”; Note the lack of a space… Whatever…) You can even do this in a private chat, which I doubt any NMDC hubs support (that support +me).

So please, if you’re writing an ADC client and you’ve been damaged enough by NMDC; don’t hijack me.

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”