SNTP (Google Summer Of Code, 2008)
is over and SNTP is on its way. We are currently working on cleaning up the code and to test and fix bugs. If you can think of a nice test case for SNTP please share your ideas at TWiki topic SntpTests
(see link in related topics below).
We need a new SNTP program.
This program will be a "reference" implementation of SNTP, based on the latest NTPv4 document.
SNTP is first and foremost a lightweight NTP client.
It will use GNU AutoGen (like the rest of the NTP programs) for its options processing.
While an SNTP implementation may
talk directly to a reference clock, the core requirement for this effort is to be a simple client implementation.
We have an existing implementation based on an older specification.
It contains functionality that is obsolete.
You could write a ground-up implementation or take the existing one and hack it in to shape, or some combination of the two. UPDATE - the existing code can be used for ideas, but it cannot be directly used because it is GPL code.
Good C skills
Related Topics: http://www.ietf.org/internet-drafts/draft-ietf-ntp-ntpv4-proto-09.txt
ISC or NTP (or equivalent)
Sponsoring Organization: http://www.freebsd.org/projects/ideas/#p-sntp
About the project
This project's goal is to write a reference implementation of the SNTP client using the latest NTPv4 document. As this shall become a reference implementation there's a focus on portability and light weight.
Project related questions
We thought not to implement a demon option but that might cause various problems. For example KoD
packets might be an issue as SNTP runs and forgets after it's done. How could this be avoided?
Another tricky issue is DNS resolving. gethostbyname() for example poses a risk to get stuck. Asynchronous resolvers like from libisc or libdns are pretty heavy and therefor go against our goal to make it a lightweight client.
My blog on which I'm writing about the project's progress
Biweekly Status Reports
Biweekly status report, 6th June 2008
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.
Biweekly status report, 20th June 2008
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. After implementing a resolverfunction in a manner as needed by this client during the time that is covered by the first biweekly report I began writing filters for the lists of hosts returned by the resolver function. These lists again are 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. After KOD and reachability check it'll be checked for sane NTP data. If one of these checks fail it'll check the other entries until it found a valid entry or it exists with an error.
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.
Biweekly status report, 4th July 2008
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 definitely was way more stress 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 :).
Debugging and testing.
There is a decent chance we will not need
to do async DNS resolution for SNTP (which means we would not need
), and we may not need to use
for the loop processing.
If SNTP can properly handle its logging, then the only thing we might need
for would be some network handling code.
Is this correct? If so, what are the costs/befits to using
v. doing it ourself?
- 17 May 2008
is a double edged sword. While in terms of portability it would be our first choice it goes against the lightweight policy I'd like to follow as far as reasonable. As for example DNS resolution there are three possibilities: gethostbyname() (which we surely want to avoid), async resolver with =libisc/='s taskmgr or writing one myself (which might be more time consuming than I can imagine at the moment, will check that).
As for logging I think we decided to use =libisc/='s logging facilities. If people want to use something different (for example when using it on an embedded device), no problem.
- 28 May 2008