RFC: Drop notice: KNetwork

[Matt Rogers]

On Wednesday 28 February 2007 13:28, Thiago Macieira wrote:
> 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.
>

Thanks for this.

> 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/


All of this sounds fine. 

Kopete will want UPnP support. UPnP support will need multicast sockets. Is it 
possible to subclass from QUdpSocket (or QAbstractSocketBase, if need be) to 
get this or does Trolltech intend to support this feature at some point in 
the future?

Thanks
-- 
Matt
-------------- 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/015dce55/attachment.sig>