September 12, 2008 at 12:10 am · Filed under Main
Today I finally added two more status updates. Way too much delay but hey, at least they made it on this site.
Currently we’re working towards releasing SNTP in the next ntp-dev release, I hope that works out. First there’s some more work on the code and a test-suite necessary. My main issue at the moment is to find the time to do everything I to get done. I guess that’s all up to a good schedule.
Besides some more code work I also want to do a major update on the project site on support.ntp.org to get everything up to date there.
This weekend I’ll use for recreation. Gonna go for some mountaineering in Switzerland. Hope this will refresh my mind.
September 12, 2008 at 12:02 am · Filed under GSoC08 Biweekly reports, Main
After the hard-pencils-down date I focused on three tasks: broadcast/multicast mode, authentication and getting the code into a good shape for submitting it to google.
First I got stuck a bit with broadcast/multicast mode with IPv4 but this is now resolved.
Authentication should work with MD5 and all that is left is a function to read a ntp.keys file and structures to store that information.
Getting the code into shape will be a lot fiddling because I forgot to checkin a few files my mentor and I worked on.
September 12, 2008 at 12:01 am · Filed under GSoC08 Biweekly reports
The SNTP project’s code should still be called at a developing stage, basic SNTP client functions are realized but a few planned features are still to be implemented. The on wire protocol is working properly and independent of the network protocols involved in packet transport. The places to implement further functions and features are finished so they’ll merge seemlessly with the current code. Of course a lot fine tuning and a few fixes are still necessary but we’re not far away from the program we wanted it to be.
The last few weeks revolved around putting all parts together and checking that they’re working together properly. A part of this time was used to check that the client is working properly with IPv4 and IPv6.
There are still some parts left to be implemented, namely authentication, broadcast mode client functionality and implementing ISC tasks for event loops.
Authentication will be the main goal until the finish of GSoC besides cleaning up and the fixes I mentioned above.
Broadcast mode client functionality is on the way, it’s not a real issue.
ISC tasks for event loops are a long term tasks but are absolutely necessary. Right now the chance that the SNTP client will block is rather high so ISC event loos will offer the desired asynchronity.
It was a really nice second phase of GSoC and I’m looking forward to continue to work on this SNTP client.
August 4, 2008 at 10:31 pm · Filed under GSoC08 Biweekly reports
Finally classes and exams are over and my real summer of code can start. The build problems we were tackling are solved and we also got autoopts working in the sntp client the way it should.
Some of the build problems were caused by entangled includes which we’ll have to solve sooner or later when we’re detaching sntp from ntp’s codebase.
Currently I’m working on writing tests which will make up actual code in the sntp client. The test I’m writing will prove the core functionality of the sntp client, it should deliver the timestamps necessary to compute the values necessary for adjusting the system clock. Once the test returns the desired results the basic functions for the sntp client should be done. This process is slowed down by some bug hunting in the framework but this too shouldn’t take too long as most functions are working by now.
Summed up having a lot more time for GSoC gives it a completely new feeling and is a lot more fun, too. After this last part of the basic client I hope to start with work on more features such as authentication and converting possibly blocking functions to asynchronous functions.
July 5, 2008 at 9:52 pm · Filed under GSoC08 Biweekly reports
Midterm evaluations are approaching fast and with that in mind I’m focusing on reaching the milestones I wanted to achieve until then.
My milestones until the midterm evaluation in short was finishing the framework and starting work on the actual client and I’m very close to complete these milestones. Protocol independent networking functions are done, a somewhat minimal logging system is done, commandline options processing is done, a temporary dns resolver and filters to filter a list of servers is also done (both will be changed to function asynchronous later). One hopefully not too big part is left until Monday: fixing errors caused by the incomplete list of variables set by the configure script so I’ll have to adapt it according to sntp’s needs. It causes the compiler to fail due to double declarations etc. of system functions that apparantly weren’t detected. That’s not a bug but my limited experience with configure and friends.
Besides fixing the build errors mentioned above I want to finish functions for KOD management, too. It’ll consist of a file that saves all KOD packets received and of functions for adding, deleting or searching for entries. Some of these points like the checks for received ntp packets are already part of the on-wire protocol.
At the moment the server selection is implemented as follows:
List of servers is resolved
=> check if the client can connect to them and filters those to which it cannot establish a connection
=> take the first connectable server and send a NTP packet to the server
=> check if packet is sane
=> check if it’s a KOD packet
=> if not sync time using the on-wire protocol
The remaining questions regarding KOD packets have been sent to the NTP workgroup mailing list and consists of roughly these three points:
1. The way a NTP server deals with a received NTP packet when sending a KOD packet
2. KOD packets’ expiration time
and finally probably a strange question
3. how clients without the possibility to save KOD data to a harddrive or the like should behave.
After midterm evaluations are over I’ll be working on university matters only until after July 18th. After that I can finally commit myself full time to GSoC. My last exam is on July 26th though but I wont need much time to prepare for that one. Looking back I sometimes wished days were longer than 24 hours. Still I think if I reach my milestones as planned it’s alright but it definitly was way more stressy than I imagined it would be. I think it’ll be twice as much fun when there’s only one thing I should concentrate on :).
June 21, 2008 at 2:21 am · Filed under GSoC08 Biweekly reports
The past two weeks I spent on working on the framework for the SNTP client. One major notable event was that I changed my approach of this project from transplanting code to including code directly. That way I was able to focus more on solving real issues instead of coping with the uncountable issues arising from the code transplantation. Again stopping to reinvent the wheel.
After that I began working at the starting point of sntp again. I implemented hostresolving for a list of servers that is again filtered for whether they’re reachable or not. Before they should be checked for existing KOD packages. Here we need to find a format in which we’ll save the KOD packages’ data as a KOD database. The KOD packages also rise a few questions regarding the way they should be dealt with which should be asked in an Email to the ntpwg group (rose that question before but as it wasn’t a concrete issue then I kept digging into other at that time more relevant topics) and on the project’s wiki page. The current stage now is about exchanging packets with ntp servers.
The second week of the last two weeks was heavily consumed by work for university due to a non-scheduled oral exam and a lecture I’m going to give.
June 13, 2008 at 11:57 am · Filed under GSoC08 Biweekly reports
Two weeks have passed now since the official coding time began. During the first week I searched for good starting points for coding. Even though (or because?) the gross structure was more or less fix before coding started, I sat there trying to come up with pro and contra arguments which approach might be the best. Nevertheless finding no answer I decided to start with the asynchronous DNS resolver until I found a good starting point for SNTP coding (asynchronous DNS resolving was never meant to be a part in line with the other SNTP relevant parts in my milestones/schedule so I’ll work on it parallel to SNTP once the SNTP client code has progressed far enough).
I started with searching and examining the relevant RFCs what appeared more difficult than assumed. Still the right docs were soon found and with the specification of the communication between DNS server and client I began to code. It was really nice to implement parts of this protocol but I should have taken more care of my bad habit of “reinventing the wheel” or doing everything myself. Thanks to a little Email exchange with a former Bind developer I became aware of that soon enough to not waste too much time on that and also to understand many things about DNS resolving better. Yet I think it wasn’t very much wasted time as I understand the spec very well thanks to that so it’ll make my work on it later easier. Even though I knew that we want to use as much as possible existing code it was also a good lesson to see better when and how I should do that.
So after that I began coding on the main program. I figured it might be the best to start here and to code the other parts as they are needed with the knowledge exactly how and when they’re needed. Implemented command-line options parsing with ntp_getopts and everything that follows up to DNS resolving (not async resolving yet) and testing the addresses returned by the resolver whether they’re reachable or not. Currently I’m working on the functions to receive and send data through the network.
For DNS resolving functions I decided to use the following interface (I’m currently using getaddrinfo, I’ll implement libdns for that probably later today, too but since we planned to write an asynchronous resolver we’ll have at least 2 different functions for DNS resolving so a common interface will give greater flexibility):
int resolver_function (char *host[], int hostc, struct addrinfo **res);
resolver_function consumes a list of hostnames, the number of hostnames and a pointer of a array of addrinfo structures. addrinfo structures themselves are linked lists (structures with a next pointer to another addrinfo structure until this pointer is NULL) with information on every IP address returned by the resolver.
I used getaddrinfo in order to study the functionality and information we need about the hosts passed to the SNTP client. I knew of getaddrinfo but as gethostbyname always did the job for me I never digged deep enough to figure out getaddrinfo’s benefits. There’s no way around protocol independent programming for a modern networking application like SNTP today.
To sum the last two weeks up, I see now a clear path how to code this SNTP client. Even though I think I’m a bit slow I guess that’s normal at the beginning as I already saw that things speed up a lot after I knew how to approach the coding for the SNTP client. Also time management is still a bit of an issue for me. I haven’t figured out the best schedule for myself yet. Right now I’m working mostly from Thursday to Sunday on it while I usually spend the whole Friday and Saturday on this project. I’m currently trying to balance the workload a bit more on all days. But I think the major working time wont change as Monday to Wednesday is just way too busy at university.
June 1, 2008 at 1:00 am · Filed under GSoC everyday life
After some more thinking and discussing we came to the conclusion that writing an own asynchronous resolver is the best way but also obviously more time consuming. Still it gives us the flexibility we need to make it function as desired while keeping it low on weight.
The protocol responsible for communication between DNS servers and clients is really beautiful, but finding understandable docs and specification on it is a hell! Despite the very core spec being dated from November 1987 and therefor only 2 months younger than me (!!!) it’s pretty evil to wrap your head around it, especially when you’re coding only a tool for your project and don’t really want to spend time on reading other specs than those directly related to your project.
That’s something that apparently cannot be avoided though. My experience today showed clearly that you’re better off in terms of time when you take the time and read the sections in question word by word.
June 1, 2008 at 12:56 am · Filed under GSoC everyday life
This post could be called outdated as of yesterday, but as I wrote it on Wednesday/Thursday on the train and forgot to put it online I’ll post in anyways. No real informational content, just notes to myself thinking things through.
Obviously the “S” in SNTP stands for simple. While that might describe it’s effect in terms of reduced functionality and therefor reduced size, making it lightweight and well implemented makes it all the less simple to implement.
There are various things that need to be solved in order to make up for the S as explained above, some of them are already solved.
For questions like asynchronous DNS resolving in order to prevent gethostbyname() from blocking the program we still search for a definite answer but I’m quite positive the solution will be found when I put my thoughts into code. Using a existing asynchronous DNS resolver is no option for obvious reasons. In theory there are three possible solutions:
- finding a way to get along with gethostbyname (pretty unlikely)
- using libisc or libdns for asynchronous DNS resolving (also pretty unlikely
- Writing an own asynchronous resolver (likely but probably time consuming. Still I somehow like the idea)
The S also poses the question if there should be a commandline option to enable the use of configuration files. Most likely it’ll become a configuration option.
All the useful things in libisc are pretty tempting, too. What and how should we include features, macros and the like into SNTP without gaining much “weight”.
Besides all these S questions I still have to send a mail to the ntpwg mailing list to clarify some protocol issues like dealing with KoD (Kiss of Death, packets that give the ability to complain to a client to the server in order to prevent abuse or missuse like too short polling intervals) packets.
June 1, 2008 at 12:52 am · Filed under GSoC everyday life
Is it relevant to save a few bytes per DNS query nowadays by using a method which simply replaces a domain name representation with a 16 bit pointer to the actual domain name representation? Guess that’s a question I should ask myself after a good night’s sleep.
For today I’m satisfied with having implemented all communication relevant DNS datastructures, their representation in my asynchronous resolver and functions that generate their respective bit formats.
Tomorrow I’ll do that the other way round, that’ll be a lot faster as I spent most of my “coding time” on researching phrases and terms used in the DNS specs I used to code.
Next entries »
