Wednesday, July 1, 2009

How to implement network protocol

network stack
network stack


Common questions regarding the network protocols include:
What is network protocol?
Why network protocol?
How to implement network protocol?

The best way to answer the question of "What" and "Why" is looking into a helloworld-style example of network protocols -- Time Protocol. Then the question "How" will follow naturally.

Here it is: the Time Protocol, defined in RFC 868.
Network Working Group J. Postel - ISI
Request for Comments: 868 K. Harrenstien - SRI
May 1983

Time Protocol
This RFC specifies a standard for the ARPA Internet community. Hosts on
the ARPA Internet that choose to implement a Time Protocol are expected
to adopt and implement this standard.
This protocol provides a site-independent, machine readable date and
time. The Time service sends back to the originating source the time in
seconds since midnight on January first 1900.
One motivation arises from the fact that not all systems have a
date/time clock, and all are subject to occasional human or machine
error. The use of time-servers makes it possible to quickly confirm or
correct a system's idea of the time, by making a brief poll of several
independent sites on the network.
This protocol may be used either above the Transmission Control Protocol
(TCP) or above the User Datagram Protocol (UDP).

When used via TCP the time service works as follows:
S: Listen on port 37 (45 octal).
U: Connect to port 37.
S: Send the time as a 32 bit binary number.
U: Receive the time.
U: Close the connection.
S: Close the connection.

The server listens for a connection on port 37. When the connection
is established, the server returns a 32-bit time value and closes the
connection. If the server is unable to determine the time at its
site, it should either refuse the connection or close it without
sending anything.
Postel [Page 1]
RFC 868 May 1983
Time Protocol
When used via UDP the time service works as follows:
S: Listen on port 37 (45 octal).
U: Send an empty datagram to port 37.
S: Receive the empty datagram.
S: Send a datagram containing the time as a 32 bit binary number.
U: Receive the time datagram.

The server listens for a datagram on port 37. When a datagram
arrives, the server returns a datagram containing the 32-bit time
value. If the server is unable to determine the time at its site, it
should discard the arriving datagram and make no reply.
The Time
The time is the number of seconds since 00:00 (midnight) 1 January 1900
GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this
base will serve until the year 2036.
For example:
the time 2,208,988,800 corresponds to 00:00 1 Jan 1970 GMT,
2,398,291,200 corresponds to 00:00 1 Jan 1976 GMT,
2,524,521,600 corresponds to 00:00 1 Jan 1980 GMT,
2,629,584,000 corresponds to 00:00 1 May 1983 GMT,
and -1,297,728,000 corresponds to 00:00 17 Nov 1858 GMT.

After reading through the 2 page definition document, which is self-explaining, we can see
A protocol is a set of rules used by computers to communicate with each other across a network. In the case of Time Protocol, it defines the way Server and User communicate about the time and the syntax of the time.

At this point, we are eager to materialize the protocol with the Time server and the Time client. But wait, questions:

Question #1: What is the time format to use?
Let's check RFC 868 -- Aha, "The time is the number of seconds since 00:00 (midnight) 1 January 1900GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; thisbase will serve until the year 2036." Clear enough.

Question #2: Where to start?
Let's check the RFC 868 again:
"This protocol may be used either above the Transmission Control Protocol(TCP) or above the User Datagram Protocol (UDP)."

Ok, now we know, we can build our server-client on top of TCP or UDP service (usually provided by code libraries). Sure enough, Java/C/Python/Perl... all have socket library which allow an application to connect to ports on remote host, listen to local port, send data, receive data, close connection, etc. So, very doable!

Question #3: How to synchronize the server and client?
Let's check the RFC 868 again (and again):
When used via TCP the time service works as follows:
S: Listen on port 37 (45 octal).
U: Connect to port 37.
S: Send the time as a 32 bit binary number.
U: Receive the time.
U: Close the connection.
S: Close the connection.
The server listens for a connection on port 37. When the connection
is established, the server returns a 32-bit time value and closes the
connection. If the server is unable to determine the time at its
site, it should either refuse the connection or close it without
sending anything.
That's almost the pseudo code!

Before we jump right into the code, notice protocols may be implemented by hardware, software, or a combination of the two. When implemented in software, the programming language doesn't matter. As long as the implementation follow the protocol defined in RFC xxx, it shall work, that's why we need network protocols!

Implementaion in Python

time_client.py
# File:time_client.py
import socket
import struct, time
# server
HOST = "www.python.org"
PORT = 37
# reference time (in seconds since 1900-01-01 00:00:00)
TIME1970 = 2208988800L # 1970-01-01 00:00:00
# connect to server
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))
# read 4 bytes, and convert to time value
t = s.recv(4)
t = struct.unpack("!I", t)[0]
t = int(t - TIME1970)
s.close()
# print results
print "server time is", time.ctime(t)
print "local clock is", int(time.time()) - t, "seconds off"
time_server.py
# File:time_server.py
import socket
import struct, time
# user-accessible port
PORT = 8037
# reference time
TIME1970 = 2208988800L
# establish server
service = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
service.bind(("", PORT))
service.listen(1)
print "listening on port", PORT
while 1:
# serve forever
channel, info = service.accept()
print "connection from", info
t = int(time.time()) + TIME1970
t = struct.pack("!I", t)
channel.send(t) # send timestamp
channel.close() # disconnect

No comments:

Post a Comment

Why I stopped publishing blog posts as information provider

Now the AI can generate content. Does that mean the web publishing industry reaches the end? ChatGPT said: ChatGPT Not at all. While AI can ...