SV: [dcdev] Anyone still alive?
Gustaf Räntilä <[email protected]>
2005-01-04 1:04
"'Direct Connect developers'" <[email protected]>

Hello all,

If adc finally is moving into 'stable' state, I have a few concerns...
First of all 2.1 states:

  "All text data in the protocol that is not entered by the user, including
protocol names, extensions etc may only contain viewable characters that may
be encoded by one byte in the UTF-8 encoding (ASCII codes 33-127). Although
the protocol is case-sensitive, names distinguished only by case are
disallowed (upper case is preferred)."

Here, "names" are nick-names I suppose. Should they (as they once Are
"entered by the user") be able to contain multi-byte UTF-8 chars or
single-byte > 127? I believe that's what "All texts must be sent as UTF-8,
including file lists, searches, nick’s, hub lists etc." means.
In this case, hubs must include full UTF-8 supported case insensitive
matching I suppose... This is not a complaint or anything; I just wanted to
be clear of the issue that true Unicode enabled string functions are
required in ADC generally. As in contrast to 'regular DC' were currently,
any non-utf-8 enabled string function will (probably) do (no matter what
internal string encoding is used, for instance with dc++ gui being Unicode
nowadays), since UTF-8 is a nice encoding, and since DC doesn't support
anything but 'ACP'. So relying on current implementation when it comes to
string functions isn't a good idea I suppose. (Just a hint for any
"ADC-developer" if I have got it all right.)

Secondly, I've said this before (far over a year ago) I like the idea of
encrypting the traffic, and I barely see theoretical limitations to this,
even though p2p data speeds are 'high' nowadays. I know of certain internet
providers (universities for instance), that have taken action against users
simply because of filenames in shares (that are being sent clear-text as bz2
filelists). They are using programs analysing this kind of traffic
automatically (you all probably know this, I know). This is not 'our'
problem, but I think it's not more than fair to try to develop a 'native'
support for an encryption base in the main protocol.
P2P encryption is probably not very difficult with individual key-pairs or
anything similar, but what's probably not so easily done is search replies
(and eventual client-hub encryption). Maybe something like the
GPA/PAS-routine could be done for client-hub ciphering to avoid usual
encryption keys (if this is heavy for hubs to generate/encrypt/decrypt). If
encryption becomes native, a key-propagation in the search message should be
easily implemented, so the clients encrypt the search reply with the given
Note; if this is Not natively implemented in the base protocol, then future
implementations are a lot more difficult, since there is no exchange of
"extended client features" in the usual client2hub communication. /There are
no way to know another clients public key/ in other words. This could be
sent in a wider INF for sure, but I'm not certain it would be any more
efficient, so "making room" for this natively could be a good idea.

I have the feeling that encryption isn't something most of you are
interested in, but I still want to know how you feel about it. And I would
like feedback on my urge for the native support of (I agree, maybe _future_)
key exchanges in the base messages presented by the protocol.

/Gustaf aka 'Opera' (and yes, I'll convert from outlook to thunderbird one

-----Ursprungligt meddelande-----
Från: [email protected] [mailto:[email protected]] För
Jacek Sieka
Skickat: den 28 december 2004 17:11
Till: 'Direct Connect developers'
Ämne: RE: [dcdev] Anyone still alive?

> I recently went through the whole 0.8 draft (but I only skimmed the
> attachment you sent). It looks good, but one feature I am missing is;
> if one client via a hub wants to request a connection (CTM) and the  
> requesting
> party cannot connect (connection refused, firewalled/timeout 
> or whatever).
A DSTA will do just that, adding an error type for it probably makes

> There should be a notify-message that the connection could not be  
> established.
> (Only if the connection attempt had a token).
> This can for example be done with a RCM using the same token 
> back to the  
> origin.
> This way both parties can be aware that the connection cannot 
> be made, not  
> just
> the connecting party. And thus, this aids network diagnostics.

> Extending this, a passive client can send a RCM to another 
> passive client
> which will answer with RCM and the same token. Now, both 
> clients know that
> they are passive and cannot communicate directly.
Client passivity can already be deduced from the INF

Another thing I'm considering (suggested by some dcdev people =) is a
publish-subscriber message type that gets a channel id and where the
messages are only sent out to the clients that have subscribed. This could
be used by extensions for instance to only send out a particular command to
clients supporting a particular feature...the only thing that worries me is
that it potentially makes the hub a bit more complex...on the other hand,
almost all message passing protocols have these three types, direct,
subscriber and broadcast so...