Re: Factor

Time is a harder-than-it-looks concept in most computing systems.

Every machine has a clock, every clock has a time, and every time has a near infinite number of representations. The challenges include mastery of such topics as timezones, calendars, encodings, localizations, offsets, precision, drift, geographic latencies, atomic clocks, even GPS synchronization.

Back in the early 1980’s, one of the tasks for building computer networks involved designing protocols by which applications could determine the current time. Over the years, these protocols have grown in features and complexity.

But back in 1983, in RFC 867, the IETF standardized a very simple human-readable time protocol called DAYTIME to solve the basic question: “what time is it?”. The specification supports both TCP and UDP implementations, but we will implement just the TCP portion in Factor.

First, we need some vocabularies:

USING: accessors calendar formatting kernel io
io.encodings.ascii io.servers.connection ;

Using the formatting vocabulary that I wrote, printing the current time is easy with strftime:

IN: scratchpad now "%c" strftime .
"Wed Apr 14 18:13:51 2010"

The threaded-server type can then be used to accept connections from clients and output the current time before closing the connection:

: <daytime-server> ( port -- server )
    ascii <threaded-server>
        swap >>insecure
        "daytime.server" >>name
        [ now "%c" strftime print flush ] >>handler ;

According to the specification, the DAYTIME server should run on port 13, but that typically requires administrative privileges, so we will run it on port 1300 for this test.

IN: scratchpad 1300 <daytime-server> start-server

And to test it, using netcat:

$ nc localhost 1300
Wed Apr 14 17:17:53 2010
$ nc localhost 1300
Wed Apr 14 17:17:53 2010
$ nc localhost 1300
Wed Apr 14 17:17:54 2010
$ nc localhost 1300
Wed Apr 14 17:17:54 2010
$ nc localhost 1300
Wed Apr 14 17:17:55 2010

Characteristic of some of the early, and quite rapid, development on the internet, the specification is a little loose as to what format the time should be represented in. Other protocols developed later will be much more specific about the form and character of the time representations they contain.