Older blog entries for thiagom (starting at number 11)

25 Jan 2003 (updated 25 Jan 2003 at 12:03 UTC) »

I think this weekend I'll have some more coding time.

I'm still stuck with a question: some resolutions might require another resolution to be done. So, that is, a thread will have to notify the manager that it's done and another resolution must be fired. When that one is complete, another post-processing must be performed. And it must not block a thread.

How do I do that?

I can think of two possible cases for that: one is a simple class that instead calls upon the gethostbyname2_r() resolvers to lookup IPv4 and 6. Another is a SRV-based lookup, that might require several lookups afterwards.

If you didn't know, the code I was referring to below has been accepted and integrated into KDE a long time ago. It was released with KDE 2.2 and has received many a fix since. Not many new features have been added since, though.

However, now I'm in the process of rewriting what I wrote before. This time, it's to fix some of the architectural mistakes I made the first time. And to simplify the whole thing, which is regarded as bloated.

Yea, I agree with that assessment. For instance kextsock.cpp is the third largest file in kdecore.

Ok, now to the new thing. This time, the class KHostname I mentioned two years ago is actually getting written, in the shape of the KDE::Network::Resolver (yay for namespaces!). Interesting how things wound back to haunt you a few years later, ain't it?

I've started the process this time by writing text describing what would need to be done and getting peer feedback. And still is there the possibility of making this code into Qt.

What is now written: the Resolver API, most of its internals, plus the resolver manager and a few helper classes. The classes that do the dirty work itself are not yet written.

Right now, I'm asking myself the question: how can I make a worker class request another lookup and still be called for post-processing, without blocking a running thread?

Code is here.

I'm still on the same regarding the little project I started.

I got in contact with Martin Konold of KDE and he said he'd give me write access to the kde-core-devel mailing list. Well, I don't know if he got to that or not, because my e-mail seems to be filtered out of KDE's mail server. (must be a rule regarding @mail.com)

So, I'm still waiting for an answer, and it seems people are going on vacations already

Oh, the other idea I had was to create a still new class in kdelibs, called KHostname. Its constructor would receive a text hostname and then someone could call KHostname::lookup() and receive all the data in a QList<KSocketAddress>

Problem: I'd use getaddrinfo() to do the lookup, which would either be:

  • a repetition of the code needed in KExtendedSocket to do the same loookup
  • called by KExtendedSocket to do the lookup, which in turn means KHostname would need port/services

Given that, I am in doubt whether this class would be better integrated into KExtendedSocket alone.

I have had some new ideas for the IPv6 implementation in KDE. First and foremost, I thought that maybe I should not try to make it in kdelibs, but in QT. I have seen that KDE and QT duplicate a lot of code and effort, like QSocket and KSocket, QUrl and KURL. So, question is: would we all benefit more from a IPv6-transparently-enabled QSocket or KSocket?

Let me emphasize the word transparent. Both QSocket and KSocket already support IPv6 in a manner or another. But neither implementation is good enough, to the point that KSocket's implementation is practically non-existant. Even if the preprocessor directives were enabled in KSocket, it still wouldn't work.

I am currently aiming to make my work to kdelibs. That is, all the code left behind in QT would be left unused. However, there's (so far) nothing preventing change into QT (read: KSocketAddress and others would fit nicely in QSocketAddress).

Problem with QT is: QSocket would change signature, while KSocket wouldn't necessarily have to.

I have just concluded writing a couple of classes for KDE in the new project I am starting, regarding full IPv6 support. The classes are:

  • KSocketAddress
  • KInetSocketAddress
  • KUnixSocketAddress

Those classes are simple and actually change nothing in current KDE's implementation of sockets. Next step is now to add class KExtendedSocket (probably inherited from QIODevice), which will do everything sockets need to do. After that is done, I'll rewrite KSocket from the scratch, keeping the same signature, to use KExtendedSocket.

Mail me if you want the files

Later yesterday, I got kdenetwork 1.92 and set off to enable IPv6 on it. Now, I've got a question for kdenetwork's developers: did you know there was a class called KSocket that you were supposed to use?

Well, the only major program to not use KSocket was knode. There was some well-written code there, but completely redundant, to open a connection. I say redundant because that's exactly what KSocket was supposed to do. So, all in all, I removed that code (#if 0/#endif) and added half a dozen lines to enable KSocket in its place. That done, knode now speaks IPv6.

Kppp also uses socket() but I haven't had the time to check on what. What I did have time to change was the addition of some devfs serial devices that weren't present on it. Since you are not allowed to type your own dial-out device (should that be changed?), I added four new devices, /dev/tts/0, /dev/tts/1, etc.

That also meant checking the locking code for Kppp, since you can't create a file with a slash in its name. I'd like to know what we're supposed to replace it with. I used an underscore ('_').
Also, I noticed that the locking code is still not correct. From what I know, you're supposed to lock the file you were given and lock any other devices your file pointed to, in case it was a symlink.

Patch is here: kdenetwork-1.92.1.diff

I've got version 0.0.1 of allifdump ready. It seems to work here, at home.
The problematic bug I was facing was using realloc() and still keeping a pointer to the old buffer. Since I fixed that, it seems to work fine now. Threaded mode is still not-done.

Since I decided to enable IPv6, I needed an IPv6-enabled tcpdump. So, I got tcpdump 3.5 and it understands IPv6 fine, but it can only show one interface at a time.

I decided, then, to write a small wrapper program that would run several tcpdumps, one on each interface, and parse the output into a simple output, indicating the interface the packet came from.

I'm calling it allifdump.

I've been trying to get some IPv6 code working for the past few months. Some attempts at it worked, but not much more than simple connection opening and listening programs. Recently, I've managed to work out some real IPv6 IPs on the 6bone, via FreeNet6. If you're interested, you can (could) reach me at:

loki.br.freenet6.net (3ffe:b00:c18:1fff::1e7)

Given that, I decided I needed an IPv6-enabled browser. Since I already had determined to make KDE2 IPv6 enabled, I set off making Konqueror able to talk at 6bone.net. Guess what?
It worked.

The patch is here and must be applied on top of a clean kdelibs 1.92 (beta 3 -- korner) code. It'll completely replace the KSocket & KServerSocket classes and will add some patches to kio/http/http.cc and kio/ftp/ftp.cpp (why don't everyone use .cpp?).

For the moment, only HTTP browsing is enabled in IPv6 mode. FTP under IPv6 adds two (more?) new commands I haven't yet mastered, so I didn't mess with that.

2 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!