Computer Science 686
SPECIAL TOPIC:
Programming Gigabit Ethernet
Spring 2008
Professor Allan Cruse
Some important prerequisites
•
•
•
•
•
•
You are a computer science grad student
You are acquainted with x86 architecture
You can execute Linux/UNIX commands
You know how to use a text-editing tool
You can write programs in the C language
You can print out a program’s source-file
Instructor Contact Information
• Office: Harney Science Center – 212
• Hours: Mon-Wed-Fri 1:30pm-2:20pm
Tues-Thurs 6:15pm-7:15pm
• Phone: (415) 422-6562
• Email: cruse@usfca.edu
• Webpage: http://cs.usfca.edu/~cruse/
The class website
• URL: http://cs.usfca.edu/~cruse/cs686/
– General description of the course
– Links to some useful online resources
– Lecture-slides and demo-programs
– System software for use with this course
– Class announcements (e.g., exam dates)
– A link to our CS686 discussion-list
– Our schedule of textbook readings
Recommended texts
Mark Norris,
Gigabit Ethernet Technology and Applications
Artech House (2002), ISBN 1-580-53504-4
Corbet, Rubini, and Kroah-Hartman,
Linux Device Drivers (3rd Ed),
O’Reilly (2005), ISBN 0-596-00590-3
Course’s continuing theme is…
“Using the computer to study the computer”
Normal C/C++ programming
application
We would write most of this source-code
“app.cpp”
call
ret
standard
“runtime”
libraries
but we would call some library-functions
e.g., open(), read(), write(), malloc(), …
then our code would get ‘linked’ with
standard runtime libraries
written usually by other programmers
and ‘shared’ among many applications
(So this is an example of “code reuse”)
Normal C/C++ programming
Many standard library functions
perform services that require
executing privileged instructions
(which only the kernel can do)
application
call
ret
syscall
Operating System
kernel
standard
“runtime”
libraries
sysret
user space
kernel space
Linux Kernel Modules
Linux allows us to write our own
installable kernel modules
and add them to a running system
application
module
call
ret
call
ret
syscall
Operating System
kernel
standard
“runtime”
libraries
sysret
user space
kernel space
Requirements/Benefits
• An LKM has to be written using “C” -- but
can include “inline” assembly language
• An LKM runs in kernel-space – so it can
do anything that the CPU supports
• Therefore, an LKM can –
– directly control any peripheral devices
– modify the kernel’s scheduling algorithms
– examine the kernel’s hidden data-structures
Network Interface Controllers
• One of the most interesting peripherals in
every modern PC is its Network Interface
Controller (NIC), allowing communication
among computers (and other equipment)
Thanks, Intel!☻
• Intel Corporation has kindly posted details
online for programming its family of gigabit
Ethernet controllers – our course’s focus
Thanks, Linus! ☻
• Linus Torvalds initiated the collaboration among
programmers that has resulted in our free “open
source” operating system
• The Linux OS continues to evolve – new version
is posted almost every week, at:
http://www.kernel.org
• For example, late last August we started our
semester with version 2.6.22.1 – then, by midDecember version 2.6.22.15 had been released
Thanks, Richard! ☻
• Richard Stallman (who spoke at USF last
semester) established the Free Software
Foundation, which produces the systems
software (e.g., editors, compilers, linkers,
libraries, debuggers) that will allow us to
write Linux application-programs – and
Loadable Kernel Modules – that explore
the capabilities of Intel’s 82573L NIC
• Website: http://www.fsf.org
Thanks, Alex! ☻
• Alex Fedosov (USF ’01) is SysAdmin for
our department’s ‘anchor’ server-cluster
• We can connect to those servers from our
classroom’s workstations or the CS Labs
• They have Intel’s gigabit Ethernet NICs
• Alex has connected them via a switched
hub, thereby creating a private Local Area
Network for doing course-experiments
Thanks, Alfred! ☻
• Alfred Chuang (USF, ’82) is a founder of
BEA Systems, Inc. (located in San Jose)
• As a computer science undergraduate at
USF, he was inspired by his teacher and
Faculty Advisor, Dr. Michael D. Kudlick
• To express his gratitude in a way that
would benefit future USF students, Alfred
made the generous gift of this classroom
Course acknowledgements
Paul Otellini
Intel NIC
documents
Linus Torvalds Richard Stallman
Linux
operating
system
GNU
software
tools
Alex Fedosov
‘anchor’
cluster
servers
Alfred Chuang
Interactive
learning
classroom
This ‘special topics’ course would not be possible without these contributions
Why use a private LAN?
• For our class exercises and experiments
we’ll be able to use the CS department’s
‘anchor’ cluster (which currently consists
of 8 server stations, but soon will be 16)
• These stations have Intel’s 82573L NIC
and they all connect to a ‘switched hub’
• We can control the network-traffic volume
and not worry about causing others trouble
Our ‘anchor’ servers
D-Link Gigabit Switched Hub
anchor00
anchor07
anchor01
anchor02
anchor03
anchor06
anchor05
anchor04
computer science department’s student network (138.202.171.0)
Demo program: ‘netsniff.cpp’
• This privileged application can monitor a
Linux station’s network-traffic, showing all
the data-packets that are being processed
by between the station’s network interface
• We can demonstrate this tool on stations
in our classroom or on the ‘anchor’ cluster
• It will give you a chance to see how those
‘anchor’ machines can be accessed
Berkeley ‘sockets’ API
• The BSD sockets application programming
interface provides a standardized library of
functions for writing network programs in C
• These functions make it straightforward to
create programs following a ‘client/server’
programming paradigm
request
‘server’
program
reply
‘client’
program
Simple ‘echo’ server
• A former USF grad student presented a
very simple example in his M.S. Thesis,
based on the User Datagram Protocol
• We’ve adapted his UNIX code for Linux:
– ‘udpserver.cpp’
– ‘udpclient.cpp’
• We can run this demo in our classroom,
but it’s also instructive to run it on ‘anchor’
A few socket-API functions
// create a new socket (i.e., an endpoint for network communication)
int socket( int domain, int type, int protocol );
// bind an ‘address’ to a socket
int bind( int sockfd, struct sockaddr *addr, socklen_t alen );
// receive a datagram from a client-process
int recvfrom( int sock, char *buf, int len, int flags,
struct sockaddr *from, socklen_t *fromlen );
// transmit a datagram to another process
int sendto( int sock, const char *msg, size_t msglen, int flags,
struct sockaddr *to, socklen_t tolen );
Our course’s context
• This course is NOT about writing network
application programs – but instead about
programming ethernet interface hardware
• Nevertheless, we believe it is helpful for
understanding why we consider various
system programming issues if we know
what uses will be made by applicationprograms of our hardware’s capabilities
For some exercises…
• We will need to use a few standard UNIX
tools for performing our experiments:
– The ‘ping’ command is useful for testing if a
pair of network-stations can communicate
– The ‘ifconfig’ program will allow us to assign
an internet-address to a specific interface, so
that standard network programs can be used
– The ‘sudo’ command will allow classmembers
to execute certain ‘privileged’ system tools
Classroom’s stations
# Kudlick classroom hosts
138.202.171.61
hrn23501.usfca.edu
138.202.171.62
hrn23502.usfca.edu
…
138.202.171.90
hrn23530.usfca.edu
# Fifth-Floor CS-Lab hosts
138.202.171.21
hrn53501.usfca.edu
…
138.202.171.32
hrn53512.usfca,edu
# ‘anchor’ server-cluster hosts
138.202.171.200
anchor00.usfca.edu
…
138.202.171.207
anchor07.usfca.edu
hrn23501
hrn23502
hrn23530
hrn53501
hrn53512
anchor00
anchor07
Kudlick Classroom
08
09
10
15
04
05
06
07
01
02
03
16
17
18
19
11
12
13
14
lectern
20
28
29
30
24
25
26
27
21
22
23
In-class exercises
• Use ‘ping’ to check that you can reach at
least three other stations:
– Another station in our Kudlick classroom
– One of the stations in the 5th-Floor CS Lab
– One of the stations on our ‘anchor’ cluster
• Try using our ‘netsniff.cpp’ application to
capture some network-packets (by using
I/O-redirection): $ netsniff > netsniff.out