RFC: Drop notice: KNetwork

[Thiago Macieira]

With all the recent news [1] on QtNetwork, I have been reevaluating our 
module. It's quite central to KDE (since we're a network-transparent 
desktop), but it has been ageing in Subversion. I haven't had time to 
maintain it.

The most important point is that I have no idea if it works on Windows. 
And I have no plans to make it work on Windows if it doesn't. On the 
other hand, QtNetwork does work on Windows. And since I know a bit of 
QtNetwork's internals, I know how tricky and buggy that platform is. That 
only compounds my efforts to not dare touch Winsock API, even with a 
ten-foot pole.

What's more, KNetwork and QtNetwork share a common ancestry: the 
discussions I had with Trolltech developers that wrote and maintained 
QtNetwork (Rainer Schmidt initially, now Andreas Hanssen). They differ in 
the front-end functionality because I tend to try to allow everything 
possible, while Trolltech settles for "what's really needed".

The present email is an analysis of the situation. It's quite lengthy. I'd 
like some feedback, though.

I am proposing that KNetwork as it currently stands be dropped. It could 
be moved to K3Network if necessary to support migration. In its place, 
we'd have a few wrapper classes that would be just for convenience around 
QtNetwork. (Those classes would move out from the namespace and would 
keep their names as they exist today).

Functionality that both frameworks share:
1) TCP sockets, in buffered and unbuffered modes
2) UDP sockets
3) unauthenticated HTTP proxying 
   (not really easy in KNetwork)
4) IPv6 lookups
   (QtNetwork does it "wrong" IMHO by placing the IPv6 addresses at the 
end of the address list, instead of ahead of IPv4)
5) IDN support for a white list of TLDs (which is modifiable)
6) non-blocking DNS resolution

Functionality that QtNetwork brings us:
1) SOCKS5 proxying
1.bis) SOCKS5 proxying without using Dante and a its config file
2) HTTP proxying with authentication, including plain, LOGIN, CRAM-MD5, 
DIGEST-MD5 and NTLM support out-of-the-box
3) Windows support
4) QNetworkInterface

Functionality that is missing from QtNetwork:
1) Unix sockets ← MAJOR
2) multiple parallel DNS lookups
   (I don't think any application requires this)
2.bis) parallel lookup of IPv4 and IPv6
2.ter) starting IPv4 lookups before IPv6
   (the latter two are "would-be-nice")
3) "unknown family" lookups and automatic future expansion to SCTP or 
other address types
   (I also guess no one uses this or will need it any time soon)
4) IPv6 domain blacklisting
   (We've barely needed it at all in KDE 3 since I introduced it)
5) SRV-based lookups and connections
   (present in KDE3, not present in KDE4)
6) reinitialisation of libresolv if /etc/resolv.conf changes

1) Since we can't do without Unix sockets, I have to wonder if TT will 
implement that. It's definitely a non-portable feature, so I have to 
wonder if they want to add a whole new class that won't work in Windows. 
Maybe, instead, they can call it QLocalSocket (AF_UNIX is an alias to 
AF_LOCAL, its official name anyways) and, on Windows, use some kind of 
socket-like structure. I don't know.

If Qt 4.3 implements it, great. If it doesn't, I'll provide it in the 
wrapper classes, KStreamSocket and KDatagramSocket. Since Windows lacks 
this functionality, it won't be implemented there. Applications that 
depend on this feature may break (and I won't care).

2) these are nice-to-have features. We can do without them. The only 
application I know of that starts a lot of parallel socket connections at 
the same time is Kopete. And since Kopete is transitioning to a possibly 
multi-process approach, I'm not worried.

The reason why KNetwork::KResolver did parallel IPv4 and IPv6 lookups was 
to improve lookup speed. Since they happen in parallel instead of 
serially, it should be twice as fast. But the main reason why it was done 
like this was to make IPv4 lookups happen first: some broken DNS servers 
used to reply with a wrongful reply for IPv6 lookups. By issuing IPv4 
first, your local cache would "iron out" those bugs.

3) really, not needed. If your application needs SCTP or DCCP, you're 
going to have trouble finding support for that. Also, people using other 
socket addresses than IPv4 and IPv6 will have support problems. Not 
intended for portable stuff.

Yeah, I had designed KNetwork to support all of that internally without 
requiring external changes to applications. But apparently the SCTP and 
DCCP API would require changes anyways...

4) I'm proposing that we drop this feature. This is not 2001 anymore and 
most DNS servers that had trouble are gone. The blacklist file lists 
doubleclick.net, but I haven't tested in a while.

5) There are exactly two real-world implementations of this functionality 
that I know of: XMPP (Jabber, Google Talk) and DNS-SD. The latter won't 
be used directly, so we don't have to worry about it. That doesn't solve 
the first one.

So I am also proposing a wrapper class for this feature, using libresolv 
directly, on Unix. Like I said, I don't care about Windows, so it'll be 
up to someone else to write the code.

6) Potentially a big problem. KDE applications tend to be long-running. 
Since the dial-up users are likely to log in to KDE before they connect 
to the Internet, /etc/resolv.conf will change under them and applications 
won't be able to resolve any hosts.

I cannot provide this in a wrapper. Either it's fixed in Qt, or it will 
show up in applications.

[1] http://labs.trolltech.com/blogs/2007/02/28/ssl-proxies-and-md5-sums/
-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070228/f6bc5114/attachment.sig>