Professional Documents
Culture Documents
TCP IP Complete
TCP IP Complete
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
UNIX Network
Programming with TCP/IP
Short Course Notes
Alan Dix 1996
http://www.hiraeth.com/alan/tutorials
UNIX
Network Programming
with TCP/IP
Course
Outline
Alan Dix
http://www.hcibook.com/alan
Session 1 Internet Basics
Session 2 First Code
Session 3 Standard Applications
Session 4 Building Clients
Session 5 Servers I
Session 6 Servers II
Session 7 Security
Three interrelated aspects:
TCP/ IP protocol suite
standard Internet applications
coding using UNIX sockets API
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 1
UNIX
Network Programming
with TCP/IP
Reading
Books:
1. W. Richard Stevens, "TCP/ IP Illustrated. Vol. 1: The protocols", Addison
Wesley, 1994, (ISBN 0-201-63346-9).
Explains the protocols using network monitoring tools without programming.
2. Douglas E. Comer and David L. Stevens, "Internetworking with TCP/ IP.
Vol.3: Client-server programming and applications BSD socket version",
Prentice Hall, 1993, (ISBN 0-13-020272-X).
Good book about principles of client/ server design. Assumes you have some
knowledge or at least some other reference for actual programming.
3. Michael Santifaller , translated by Stephen S. Wilson, "TCP/ IP and ONC/ NFS
internetworking in a UNIX environment", 2nd Edition, Addison Wesley, 1994,
(ISBN 0-201-42275-1).
Covers more ground less deeply. Translation from German seems good.
4. W. Richard Stevens, "UNIX Network Programming", Prentice Hall, 1990,
(ISBN 0-13-949876-1).
A programming book. I'm waiting for a copy, but Stevens is a good writer and
this book is recommended by other authors.
See also:
your local manual pages (ma n 2)
RFCs
Requests for comments (RFCs)
these are the definition of the Internet protocols
obtain via anonymous ftp from s un. doc . i c . a c . uk (193. 63. 255. 1)
login as a nonymous
give your email address as password
cd to r f c
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 2
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
Session 1
Internet Basics
UNIX
Network Programming
with TCP/IP
Session 1
Alan Dix
http://www.hcibook.com/alan
origins
internets and the Internet
protocol layers
addressing
common applications
using them
TCP and UDP
port numbers
APIs
information calls
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 1
Origins
Development of Internet & TCP/IP
1968 First proposal for ARPANET military & govt research
Contracted to Bolt, Beranek & Newman
1971 ARPANET enters regular use
1973/ 4 redesign of lower level protocols
leads to TCP/ IP
1983 Berkeley TCP/ IP implementation for 4.2BSD
public domain code
1980s rapid growth of NSFNET broad academic use
1990s WWW and public access to the Internet
The Internet Now
growing commercialisation of the Internet
50,000 networks
6 million hosts
30 million users
WWW dominating Internet growth
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 2
internets and the Internet
an internet is
a collection of
interconnected networks
(possibly different)
e.g. X25, AppleTalk
the Internet is
a particular internet which
uses the TCP/ IP protocols
is global
is hardware and network independent
is non-proprietary
in addition
supports commonly used applications
publicly available standards (RFCs)
the Internet is not (just) the web !
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3
Characteristics of the Internet
To communicate you need:
continuous connection
common language
means of addressing
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 4
Global Connectivity
ethernet
token ring
PPP
routers
router
sub-network
star
network
lots of networks:
ethernet, FDDI, token ring
AppleTalk (itself an internet!)
etc. etc. etc.
connected (possibly indirectly)
to each other
to the central ARPAnet backbone in the US
protocols can be used in isolation
? but is it the Internet
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 5
Protocols the Language of the
Internet
electrical signals
low-level networks
(e.g. ethernet)
IP layer (end-to-end)
TCP/ UDP layer
application protocols
(e.g. FTP, telnet, http)
application user interfaces
(e.g. Fetch, mosaic)
OSI
ICMP (control and routing)
Physical
Link
Transport
Network
Session,
Presentation,
Application
routers
end-points
TCP/IP
Standardisation:
RFC (request for comments) and DoD MIL
RFCs also include (defined but not required):
PPP, ethernet packaging, etc.
FTP and other protocols
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6
Addressing
J. C. T. Jennings,
Linbury Court School,
Dunhambury,
Sussex,
England,
Europe,
Eastern Hemisphere,
Earth,
near Moon,
Solar System,
Space,
near More Space
I
^
'
Internet
client
server
shell
basic pattern:
' user types characters
Z the client sends them to the server
the server passes them on to the shell
J shell generates output
server passes output to client
client puts output on users screen
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 3
Remote Terminals Issues
initialisation and authentication
' how does the server know who you are?
Z how do you know the server is official?
answer to Z:
the server is on a reserved port (<1024)
N.B. only works for UNIX servers!
how to deal with special characters
... including end-of-line !
which end performs different things:
user flow control (crtl-S, ctrl-Q)
line editing
echoing
how do the client and server communicate:
user interrupts
window size changes
who does what
if embedded control characters are used
what happens if the user types them?
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 4
rlogin
simple stable protocol
designed for UNIXUNIX logins
can make more assumptions
( terminal handling, interrupts, etc. )
authentication by trusted hosts
no password required if:
client uses port <1024
and
client host is in . r hos t s file
means that client must be s e t ui d to r oot
responsibility
echoing server
flow-control client on server request
clientserver communication
clientserver initialisation string
clientserver window size change:
ctrl chars 2 bytes of 255
followed by window size in 2 bytes
no protection against user typing it!
serverclient requests:
special characters (bytes x02, x10, x20, x80)
marked by URG (urgent) pointer
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 5
Urgent Data
sometimes called out-of-band data
. . . but its not!
data sent in normal TCP stream
special URG pointer set
officially to the last byte of urgent data
BSD set it one beyond!
o m e t e x t 0x80 m o r
URG pointer
Berkeley URG pointer!
client should:
' read until urgent data reached
Z if necessary discard intervening data
(e.g. if insufficient buffer space to store it)
problem with '
URG pointer says where it ends . . .
. . . but how do you know where it starts?
have to have special codes again
with UNIX sockets
send urgent data with s e nd system call
recipient gets a SI GURG signal
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 6
telnet
cross platform more complex
many downward-compatible options
can be used to connect to non-login services
client authentication
not in protocol application specific
e.g. ge t t y
responsibility
client may handle echoing, line editing etc.
subject to option negotiation
NVT character set
needed because cross-platform
7 bit US ASCII
end-of-line sent as \ r \ n (carriage return, line feed)
carriage return sent as \ r \ 0
also used by SMTP, ftp, finger etc.
v high bit free for control characters!
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 7
telnet 2
control codes
introduced by byte 255
called: IAC interpret as command
following byte is actual control code
examples:
255 the actual byte 255 (needed for binary mode)
236 end of file
241 no op
243 break
option negotiation control codes:
251 WILL
252 WONT
253 DO
254 DONT
250 sub-option begin
240 sub-option end
option negotiation
many different options:
echoing line editing,
flow control window size information
client and server play will you/ wont you
to determine common protocol
just like fax machines and modems
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 8
http
the World Wide Web protocol
protocol:
ASCII control messages
standard data formats for pages/ images
uses single step transactions
' establish TCP connection
Z client sends request
server sends reply + page
J connection closed
why transaction based?
client end many different servers
(hypertext links to different sites)
server end many clients
load time < interaction time (ideally!)
why use TCP?
high cost of establishing connection
wide area, large messages & simple clients
v reliable communication needed
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 9
Hands on
peeking
use the program pr oxy in t c p/ s e s s i on3
it sits between client and server
use it to see how http works:
' run: pr oxy www. hud. a c . uk 80 - por t 8800
Z start up Netscape using background menu
go to the url:
ht t p:/ / www.hud.ac.uk/ schools/ comp+mat hs/ privat e/ alan/ alandix.ht ml
J now edit the host name in the url field
if your machine is i o
change / / www.hud.ac.uk to / / io.hud.ac.uk:8800
the 8800 is to set the port number used by pr oxy
hit return and watch the pr oxy window
you can do the same with telnet:
' run: pr oxy z e us . hud. a c . uk 23 - por t 2300
' then: t e l ne t i o 2300
N.B. cannot be used for protected ports (ftp, mail etc.)
try using the - v option of f t p
type:
f t p - v pr ome t he us . hud. a c . uk
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 10
File Transfer Protocol
FTP
used to transfer files and list directory contents
uses two types of connection:
control for commands and responses
data for files and listings
protocol for control is ascii turn-taking
client command, server response, ...
client commands nearly user level, including:
USER
user name for connection
often a nonymous is accepted
PASS
password, email address for a nonymous
GET
receive a file from remote machine
PUT
send file to remote machine
CWD
change remote directory
LI ST
change remote directory
PORT
tell server what data port to use
HELP
info about commands supported
QUI T
finish session
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 11
FTP - 2
control and data
control connection
server waits (passive open) on port 21
client establishes connection (active open)
client sends ascii commands one per line
server responds: single or multi-line response
when required a data connection is established
data connection
client performs a passive open on some port
(may leave OS to determine port number)
client tells server using control connection
PORT 161. 112. 192. 5. 9. 93
port 2397 (=9*256+93) on host 161. 112. 192. 5
when data transfer is required
client sends appropriate command
e.g. GET s i mpl e - c l i e nt . c
then waits listening for connection
server performs an active open on port
then sends data
server tells client when transfer is complete
e.g. 226 Tr a ns f e r c ompl e t e .
then both sides (usually) close the data port
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 12
standard response codes
ftp server replies with lines such as:
200 PORT c omma nd s uc c e s s f ul
SMTP and some other protocols use similar codes
three digit codes type given by first digit:
1yz expect further reply from server
2yz all OK
3yz more required from client
4yz temporary failure (try again)
5yz error or permanent failure
single-line response general format
999 a t e xt me s s a ge
space here
multi-line response
either:
hyphen means more to come
999- f i r s t l i ne
999- one or mor e f ur t he r l i ne s
999 t he l a s t l i ne
space here on last line
or
999- f i r s t l i ne
l ot s of l i ne s a l l s t a r t i ng wi t h
a t l e a s t one s pa c e
999 t he l a s t l i ne
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 13
Simple Mail Transfer Protocol
SMTP
allows:
mail client (user interface) to send via server
servers to talk to one another
(one server takes client role)
note:
not used by user interface for receipt
s e ndma i l is common SMTP server under UNIX
client commands:
HELO
client tells server who it is
MAI L
initiates message and sets sender
RCPT
sets one of the recipients
DATA
says actual message content follows
VRFY
check that recipient exists (no mail sent)
EXPN
expand mail alias (no mail sent)
RSET
start from scratch
EHLO
see if server handles advanced features
QUI T
finish session
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 14
SMTP 2
authentication, servers typically:
do not trust HELO
use reverse name mapping instead
do trust sender name (Fr om: )
how could they verify it?
SMTP specifies delivery not content
other standards used for content:
non-ASCII characters in headers
=? I SO- 8859- 1? Q? Al a n=20Di x? =
MIME for multi-part mixed content messages
simple mail message is just:
header
Fr om: a l a n@z e us . hud. uk
To: R. Be a l e @c s . bha m. uk. a c
Subj e c t : HCI book 2E
blank line
body
Rus s e l l ,
ha ve you he a r d f r om Pr e nt i c e Ha l l
ye t c onc e r ni ng t he we b pa ge s ?
Al a n
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 15
Hands on
see what it does
we want to send a mail message using raw SMTP!
first of all see how ma i l does it
cannot use pr oxy as SMTP is at port 25 (protected)
instead try the - v option of ma i l
type:
ma i l - v c 3 or whoever you want to send mail to!
see the messages from the server and the client
N.B. not all messages are shown
when does mail establish the connection?
why?
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 16
Hands on
drive it by hand
use telnet to send a message
type:
t e l ne t z e us . hud. a c . uk 25
you are connected to the SMTP server on z e us
say hello! which machine you are on
HELO wa l t . di s ne y. c om
did it believe you?
how does it know?
now say who the message is from and who it is to
MAI L Fr om: <Dona l d_Duc k>
RCPT To: <c 3@z e us . hud. a c . uk>
next send the message
DATA
f i r s t l i ne of me s s a ge
. . dot t y
s he a r qua c ke r y
.
finally say goodbye
QUI T
run ma i l to see if any celebrity has sent you any
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 17
argc & argv
recall: i nt ma i n( i nt a r gc , c ha r **a r gv ) ...
or: i nt ma i n( i nt a r gc , c ha r *a r gv[ ] ) ...
one of the ways to get information into a C program
in UNIX you type:
mypr og a " b c " d
the program gets:
a r gc = 4 length of a r gv
a r gv[ 0] = " mypr og" program name
a r gv[ 1] = " a "
a r gv[ 2] = " b c " single second argument
a r gv[ 3] = " d"
a r gv[ 4] = NULL terminator
N.B. DOS is identical (except a r gv[ 0] is NULL early versions)
a r gc is one less than the number of arguments!
other ways to get information in (UNIX & DOS):
configuration file (known name)
standard input
environment variables using ge t e nv( )
or (UNIX only) third arg to main:
ma i n( i nt a r gc , c ha r **a r gv, c ha r **e nvp)
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 18
Make
ma ke is a UNIX
command which:
automates program construction and linking
tracks dependencies
keeps things up-to-date after changes
to use it:
construct a file with rules in it
you can call it anything, but ma ke f i l e is the default
run make itself
ma ke t a r ge t
(uses the default ma ke f i l e )
ma ke - f myf i l e t a r ge t
(uses the rule file myf i l e )
either rebuilds the program t a r ge t if necessary
each makefile consists of:
definitions
rules
rules say how one thing depends on another
they are either:
specific e.g. to make ma i l - c l i e nt do this ...
generic e.g. to make any . o from its .c ...
ma ke is also available in many other programming environments
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 19
Makefile format
Definitions
general form:
variable = value
example:
SDI R = t c p
MYLI BS = $( SDI R) / l i b
N.B. one variable used in another's definition
make variables are referred to later using $
e.g. $( SDI R) , $( MYLI BS)
expanded like #de f i ne s or shell variables
(some versions of make will expand shell variables also)
Rules (just specific rules)
general form:
target : dependent1 dependent2 ...
command-line
N.B. this must be a tab
example:
mypr og: mypr og. o a not he r . o
c c - o mypr og mypr og. o a not he r . o $( MYLI BS)
this says:
to make mypr og you need mypr og. o and a not he r . o
if either of them is newer than mypr og rebuild it using the
then rebuild it using the command: c c - o mypr og ...
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 20
Helper Functions
standard response lines
to make life easier!
my own helper functions
to read standard response lines
#i nc l ude " pr ot oc ol . h"
to interact with SMTP server
#i nc l ude " ma i l - he l pe r . h"
i nt ge t _r e s pons e _f d( i nt s e r ve r _f d, i nt e c ho_f d,
c ha r *buf f , i nt l e n ) ;
reads from s e r ve r _f d
parses a single or multi-line response
returns the response code (of last line)
echoes full response to e c ho_f d
also copies it into buf f if non-NULL
i nt ge t _r e s pons e _f p( FI LE *s e r ve r _f p, FI LE *e c ho_f p,
c ha r *buf f , i nt l e n ) ;
similar with s t di o files
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 21
Helper Functions 2
for sending mail
i nt do_ma i l _i ni t ( i nt s e r v_f d) ;
awaits first response and does HELO
checks response and returns 0 if OK
i nt do_ma i l _f r om( i nt s e r v_f d, c ha r *f r om) ;
i nt do_ma i l _t o( i nt s e r v_f d, c ha r *t o) ;
sends MAI L and RCPT commands respectively
sender (f r om) and recipient (t o) are C strings
i nt do_ma i l _da t a _f p( i nt s e r v_f d, FI LE *us e r _f p) ;
i nt do_ma i l _da t a _buf f ( i nt s e r v_f d, c ha r *buf f , i nt l e n) ;
send DATA command and send message
copied from us e r _f p or buf f respectively
i nt do_ma i l _qui t ( i nt s e r v_f d) ;
does QUI T command
All optionally echo all exchanges to a file (or terminal) set by:
FI LE *do_ma i l _s e t _e c ho_f p( FI LE *ne w_e c ho_f p)
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 22
Hands on
build your own mail client
copy s i mpl e - c l i e nt . c and call it ma i l - c l i e nt . c
copy the following from t c p/ s e s s i on3:
ma i l - he l pe r . c
ma ke 3
the makefile is ready to compile your mail client
you can type (when ready!):
ma ke - f ma ke 3 ma i l - c l i e nt
N.B. ' SMTP obeys strict turn-taking:
serverclientserverclientserver
Z server starts with a return code
but client in control
modify the client code
' set default host (z e us ) and port (25)
Z to and from addresses:
either read in or use argv
message: initially read a single line
J unwrap loop to give fixed turns
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 23
Hands on
mail client 2
resulting program structure:
(a) r e a d ( pa r s e ) t o/ f r om a ddr e s s e s f r om us e r
(b) r e a d me s s a ge f r om us e r ( ge t s or s c a nf )
(c) ope n t c p c onne c t i on t o ma i l s e r ve r on c or r e c t por t
(d) wa i t f or s e r ve r r e s pons e l i ne ( s )
(e) s a y he l l o t o s e r ve r
(f) wa i t f or s e r ve r r e s pons e l i ne ( s )
(g) s a y who t he ma i l i s f r om
(h) wa i t f or s e r ve r r e s pons e l i ne ( s )
(i) s a y who t he ma i l i s t o
(j) wa i t f or s e r ve r r e s pons e l i ne ( s )
(k) s a y t ha t da t a i s c omi ng
(l) wa i t f or s e r ve r r e s pons e l i ne ( s )
(m) s e nd one l i ne me s s a ge
(n) s e nd l i ne wi t h j us t f ul l s t op
(o) wa i t f or s e r ve r r e s pons e l i ne ( s )
(p) s a y goodbye
(q) wa i t f or s e r ve r r e s pons e l i ne ( s )
(r) c l os e c onne c t i on
compile and run your code!
if you have time modify it to send longer messages
either: change step (b) and (m) to accept long messages
or: remove step (b) and
make (m) read from user before sending each line
or: whatever you like ...
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 3/ 24
Session 4
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
Concurrent
Clients
UNIX
Network Programming
with TCP/IP
Session 4
Alan Dix
http://www.hcibook.com/alan
sequential and concurrent clients
techniques for concurrency
call-backs
knowing what youre doing
callbackbased client
using it
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 4/ 1
Sequential Clients
e.g. FTP
1. client waits for user input
2. user types DI R
3. client performs passive open on data port (2397)
4. client sends PORT 161. 112. 192. 5. 9. 93 to server
5. client waits for standard 200 reply line
6. if not OK then fail
7. client sends LI ST to server
8. client waits for standard 150 reply line
9. if not OK then fail
10. client reads from data port
11. client waits for standard 226 reply line
12. if not OK then fail
13. report success to user
client is in control
next client action depends on:
what happened last
e.g. what commend the user types
NOT on when it happens
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 4/ 2
Naturally Concurrent Clients
e.g. telnet
at any moment either
user may type something
or
output may come from server end
client must respond whichever happens
program a bit like:
when user types
then send to the server
when server sends message
then print on terminal
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 4/ 3
Concurrency for Usability
e.g. Netscape WWW client
basic protocol transaction based
. but response can be slow
7 interaction allowed during transaction
~ scrolling
~ STOP button
client has to listen to
server more data
user mouse and keyboard
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 4/ 4
Programming Concurrency
Problem
doing more than one thing at once
listening user terminal & TCP server port
Solutions
polling
use non-blocking I/ O
keeps processor busy
threads
needs built-in support (language or OS)
program written as several sequential parts
all executed at the same time
communicate using shared data
(also semaphores etc.)
event driven programming
low-level e.g. UNIX select
event-loop e.g., raw X and Mac
program paradigm e.g. Visual Basic, HyperCard
call-backs e.g., Windows, X Motif
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 4/ 5
Event Loop
Typical program structure
f or ( ; ; ) { / * l oop f or e ve r */
s t r uc t e ve nt _s t e ve nt ;
r e a d_e ve nt ( &e ve nt ) ;
i f ( e ve nt . t ype == BUTTON
&& e ve nt . t a r ge t = qui t _but t on)
r e t ur n OK;
e l s e i f ( e ve nt . t ype == KEYPRESS )
i ns e r t _c ha r ( e ve nt . c ha r ) ;
e l s e i f ( e ve nt . t ype == I NPUT_READY )
do_ne t wor k_t a s k( e ve nt . buf f ) ;
. . .
}
7 programmer in control
related code gets spread out in if/ case statements
often written with sub-loops e.g. for dialogue boxes
unforeseen events (e.g. network I/ O)
may be delayed or even ignored!
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 4/ 6
EventBased Languages
program = collection of event handlers
e.g. HyperCard
on mous e Up
s e t c ur s or t o wa t c h
put ge t Se r ve r Addr e s s ( ) i nt o s e r ve r Addr
put ge t Us e r Na me ( ) i nt o us e r Na me
put c d f l d " ToOr Fr om" i nt o t oNa me
put c d f l d " Me s s a ge " i nt o t he Me s s
s e nd " t oSe r ve r Se ndMa i l "
&& quot e & t oNa me & quot e & c omma
&& quot e & us e r Na me & quot e & c omma
&& quot e & t he Me s s & quot e
t o pr ogr a m s e r ve r Addr
e nd mous e Up
on Appl e Eve nt c l a s s , i d, s e nde r
a ns we r " Appl e Eve nt " && c l a s s && f r om && s e nde r
- - di a l ogue box f or us e r
e nd Appl e Eve nt
7 concurrency naturally part of language
network I/ O not always treated uniformly
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 4/ 7
Call-backs
used in many toolkits and window mgrs:
e.g.:
WinSock (TCP/ IP under Windows)
X Motif
General pattern
Program
' define a function
Z tell toolkit to attach it to event
give control to the toolkit
Toolkit
when event happens
call user defined function
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 4/ 8
Example X Motif Call-backs
Xt AddCa l l ba c k( widget, callback-type, func, my-data )
widget a widget such as a button
type a callback resource name:
which type of event to respond to
e.g., XmNactivateCallback
func pointer to C function defined by you
e.g., quit_func
my-data an integer or pointer to your data
passed on to your callback
The callback function definition:
voi d qui t _f unc ( widget, my-data, event-data )
widget where the event occurred
my-data the integer or pointer passed in
the call to XtAddCallback
event-data the X event structure which caused
the callback
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 4/ 9
Whats going on?
Sequential Programs
f or ( ; ; ) { / * N. B. ps e udo- C ! ! ! */
ge t s ( c omma nd) ;
i f ( . . . )
i f ( c omma nd i s " qui t " ) {
c ha r r e s pons e [ MAX_LI NE_SI ZE+1] ; Z
wr i t e ( s e r v_s d, " QUI T\ n" , 5) ;
' r e a d( s e r v_f d, r e s pons e , MAX_LI NE_SI ZE) ;
i f ( r e s pons e [ 0] ! = ' 2' ) . . .
pr i nt f ( " s e s s i on c ompl e t e \ n" ) ;
e xi t ( 0) ;
}
i f ( . . . )
}
features for free
' program counter ()
what you are doing
Z local variables
what you are doing it to
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 4/ 10
Whats going on? - 2
sequential concurrent
implicit explicit
local variables
global variables
or dynamic data structures
e.g. partial line of user input
program counter
mode variable
or finite state machines!
e.g. TELNET command sequences
server output modes:
' normal echoing
Z waiting for command
waiting for option
not byte 255
byte 255
3 2 1
253 DO
254 DONT
any
option
other bytes
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 4/ 11
Callback based client 1
' Initialisation
ma i n( . . . ) {
/ * request connection to server */
s d = t c p_a c t i ve _ope n( hos t , por t )
/ * set-up callback for server */
i nf or m_i nput ( s d, r e a d_s oc ke t , NULL) ;
/ * set-up call-backs for interface */
. . .
/ * give control to toolkit */
i nf or m_l oop( ) ;
}
^ When server sends a message ...
... read_socket is called
r e a d_s oc ke t ( i nt s d, . . . ) {
/ * read servers message */
l e n = r e a d( s d, buf f , buf _l e n) ;
/ * process message */
/ * probably update interface */
}
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 4/ 12
Callback based client 2
When user does something ...
... appropriate function is called
t e r m_l i ne ( i nt f d, voi d *i d, c ha r *buf f ) {
/ * process interface event */
me s s ( " s e ndi ng {%s }\ n" , buf f ) ;
/ * possibly send message to server */
wr i t e ( s d, buf f , s t r l e n( buf f ) ) ;
}
step ' once at initialisation
steps ^ & any number of times in any order
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 4/ 13
Hands on
an electronic conference
copy the following from t c p/ s e s s i on4:
c l i e nt . c
s e r ve r . c
ma ke 4
the makefile is ready to compile, type :
ma ke - f ma ke 4 c onf
one person run the server:
i o: s e r ve r
two or more others run the client:
ot he r : c l i e nt - hos t i o
N.B. you cannot participate from the server
to join in launch a client in another
window of the servers machine
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 4/ 14
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
Session 5
Server Design
UNIX
Network Programming
with TCP/IP
Session 5
Alan Dix
http://www.hcibook.com/alan
types of server
handling server concurrency
server state
stateless servers
when things go wrong!
survival the 3 Rs
callbackbased server
modify server
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 5/ 1
Servers
Kinds of server
' transaction based
e.g. database: 1 query 1 result
Z strict turn-taking
e.g. ftp
inherent concurrency
e.g. electronic conferences, MUDs
for lots of clients either:
serve one at a time in turn
' may be slow
Z may take forever!
serve several at the same time
both require concurrency
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 5/ 2
Server Concurrency
similar solutions to client
polling
7 acceptable if machine dedicated to server
threads
UNIX select
event driven
less likely to run in event-based system
7 some web based servers do
in addition:
when no intrinsic concurrency
can use UNIX fork
7 launch separate process to serve each client
so each is simpler
7 uses standard UNIX process concurrency
can be expensive (process creation)
especially with lots of small transactions
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 5/ 3
Server State
concurrent server needs to remember
how many clients
state of their connection
state of each transaction/ protocol
etc. etc. etc.
. many clients large state
. disaster scenarios
client establishes connection
client crashes
client restarts
client establishes a new connection
it crashes again ...
7 solution no state
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 5/ 4
Stateless Servers
stateless = no per client state
for transaction based services
client makes request
server performs action
server returns result
really only possible with UDP
e.g. http transaction based, but uses TCP
may need several reads for request
need to store partially filled buffer ...
N.B. in general, buffers part of the per client state
not all plain sailing ...
clients have to maintain more state
requests more complex (no context)
unreliable protocol
transactions must be idempotent
time-outs for lots transactions ...
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 5/ 5
When things go wrong
PC crash one sad user
server crash lots of angry users
take special care with servers!
probability of failure:
clients prob. of failure = p
server prob. of failure = q
n clients and only 1 server, so:
probability of some failure np+q
good news!
server failure less likely (or is it?)
bad news!
servers are more complex (q > p)
what if client brings server down?
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 5/ 6
Causes of failure
' hardware failures
^ programming errors
unforeseen sequences of events
system does not scale
Large number of components
' more frequent
Complexity of algorithms
^ more likely
Interleaving and delays
difficult to debug
Limited testing conditions
unexercised
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 5/ 7
Survival
Network or server failure
standard solutions
Client fails three Rs for server
robust
server should survive
never wait for response from client
non-blocking network I/ O
reconfigure
detect and respond to failure
time-out or failure of I/ O operations
reset internal data structures
inform other clients
resynchronise
catch up when client restarts
similar to new client
N.B. client may not know (network)
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 5/ 8
Software faults
Defensive programming
inconsistent client/ server data structures
Use simple algorithms
fixed sized structures but check bounds!
may conflict with scaleability document
Verify
close hand checks
for production code formal methods
Unforeseen sequences of events
deadlock never use blocking I/ O
never assume particular orders of events
back-to-back messages
network packet logical message
Debugging and testing
logging to reproduce failure
random data at interface or network
ask your friends
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 5/ 9
Callback based server 1
' Initialisation
ma i n( . . . ) {
/ * establish port */
pd = t c p_pa s s i ve _ope n( por t )
/ * set-up callback for port */
i nf or m_i nput ( pd, a c c e pt _c l i e nt , NULL) ;
/ * give control to notifier */
i nf or m_l oop( ) ;
}
^ When client requests connection ...
... notifier calls accept_client
a c c e pt _c l i e nt ( . . . ) {
/ * accept clients connection */
f d = t c p_a c c e pt ( por t _f d) ;
/ * record connection details */
c l i e nt _f d[ c ount ] = f d;
/ * set-up callback for client */
i nf or m_i nput ( f d, r e a d_c l i e nt , c ount ) ;
/ * keep track of number of clients */
c ount = c ount +1;
/ * probably tell other clients also */
}
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 5/ 10
Callback based server 2
When client sends message ...
... notifier calls read_client
r e a d_c l i e nt ( c _f d, i d ) {
/ * read clients message */
l e n = r e a d( c _f d, buf f , buf _l e n) ;
/ * broadcast to other clients */
f or ( c =0; c <c l i e nt _c ount ; c ++) {
i f ( c l i e nt _f d == c _f d ) {
/ * special reply for sender */
}
e l s e {
/ * relay message to other clients */
}
}
N.B. step ' performed once at initialisation
steps ^ & happen any number of times ...
... in any order
similar to client code, but with extra accept stage.
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 5/ 11
My window-less callbacks 1
so you can experience the pain of
callbacks without the added pain of
windows ...
# i n c l u d e " i n f o r m. h "
i nt i nf or m_i nput ( i nt f d, i nf or m_f un f ,
i nf or m_i d i d ) ;
function f is your callback
f is called when a buffer can be read from f d
... without blocking
the identifier i d is also passed to f
i nt i nf or m_out put ( i nt f d, i nf or m_f un f ,
i nf or m_i d i d ) ;
similar to i nf or m_i nput but for output
f is called when a buffer can be written to f d
i nt i nf or m_l oop( ) ;
gives control to the 'notifier' which performs
callbacks for you
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 5/ 12
My window-less callbacks 2
# i n c l u d e " l i n e _ b y _ l i n e . h "
i nt i nf or m_l i ne _by_l i ne ( i nt f d, l i ne _f un l i ne _f ,
e of _f un e of _f , i d_t ype i d ) ;
the file f d is monitored by notifier
two callbacks: l i ne _f and e of _f
l i ne _f is called when a complete line is read
e of _f is called when the end of file is reached
# i n c l u d e " mo n i t o r . h "
s t r uc t mon_t a b_s t r uc t moni t or _t a b[ ] = {
{ 0, " command" , callback, " description" },
{ 0, 0, 0, 0 }
};
i nt pe r f or m_l i ne ( c ha r *buf f ) ;
helper for simple command interface
you make moni t or _t a b with suitable functions
the first word in buf f is regarded as a command
it is looked up in moni t or _t a b
. . . and the relevant callback is run
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 5/ 13
Hands on
< the conference server is not very friendly
it refers to everyone by number
you are going to make this better!
copy s e r ve r . c call it ne w- s e r ve r . c
edit the makefile ma ke 4 so that you can
compile ne w- s e r ve r . c by using:
ma ke - f ma ke 4 ne w- c onf
locate the place where the server first establishes
contact with the client.
make the server wait for a line (or buffer) of input
from the client (the clients name)
modify the notification message it sends to all the
clients to make it name the user
compile and run (use the same client)
run several clients, do you notice delays?
< Harder bits
add the user name to the per-client data structure
alter the server so that all messages use the name
rather than client number
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 5/ 14
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
Session 6
Forking Servers
& more TCP/IP
UNIX
Network Programming
with TCP/IP
Session 6
Alan Dix
http://www.hcibook.com/alan
Forking Servers
& TCP/IP behaviour
UNIX processes and fork
forking servers
fork system call
example code
dup, exec and wait
remote shell
inet demon and remote login
another echo server
IP fragmentation
TCP flow control
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 1
Loosely coupled services
closely coupled:
strong client interaction
e.g. electronic conference
loosely coupled:
little or no client interaction
e.g. WWW
no interaction at all
separate process to serve each client
weak interaction
need locking, database server etc.
i.e. some central point of control
server
process
client
server
process
client
server
process
client
server
process
client
database server file locking demon
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 2
A UNIX process
UNIX process:
identified by process id (pid)
process includes:
program code
application data
system data
including file descriptors
code
data
system data
e.g. file descriptors
pid = 597
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 3
Forking
UNIX 'fork' duplicates process:
copies complete process state:
program data + system data
including file descriptors
code immutable shared
$ e c ho $$
597
$ ( e c ho $$)
632
$
code
data
system data
597
code
data
system data
632
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 4
Forking 2
old process called the parent
new process called the child
process ids
allocated sequentially
so effectively unique
(but do wrap after a very long time)
finding process ids
at the shell prompt:
use 'p s '
in a C program:
use 'i n t p = g e t p i d ( ) ; '
in a shell script:
use '$ $'
N.B. useful for naming temporary files:
t mp f i l e = " / t mp / my f i l e $ $ "
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 5
Use in servers
' the server passive opens a port
and waits for a client
client
server
Z the client performs an active open
a connection is established
client
server
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 6
Use in servers 2
the server forks a child
client
child server
fork
child is a copy of the server
both socket connections are duplicated
server waiting on port . . .
. . . and child waiting on port
child connected to client . . .
. . . and server connected to client
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 7
Use in servers 3
J server closes the connection
child closes the passive port
client
child server
server waits for further connections
child talks to client
client
child server
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 8
Fork system call
pi d_t p = f or k( ) ;
( pi d_t i nt )
if successful
process
successful fork returns:
0 to child process
child pid to parent process
parent and child are different!
negative result on failure
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 9
Execution 1
parent forks
597
~
i nt i = 3, c _pi d = - 1;
c _pi d = f or k( ) ;
i f ( c _pi d == 0 )
pr i nt f ( " c hi l d\ n" ) ;
e l s e i f ( c _pi d > 0 )
pr i nt f ( " pa r e nt \ n" ) ;
e l s e
pr i nt f ( " f a i l e d\ n" ) ;
DATA
i = 3
c _pi d = - 1
after fork parent and child identical
597 632
~
i nt i = 3, c _pi d = - 1;
c _pi d = f or k( ) ;
i f ( c _pi d == 0 )
pr i nt f ( " c hi l d\ n" ) ;
e l s e i f ( c _pi d > 0 )
pr i nt f ( " pa r e nt \ n" ) ;
e l s e
pr i nt f ( " f a i l e d\ n" ) ;
~
i nt i = 3, c _pi d = - 1;
c _pi d = f or k( ) ;
i f ( c _pi d == 0 )
pr i nt f ( " c hi l d\ n" ) ;
e l s e i f ( c _pi d > 0 )
pr i nt f ( " pa r e nt \ n" ) ;
e l s e
pr i nt f ( " f a i l e d\ n" ) ;
DATA
i = 3
DATA
i = 3
c _ p i d = 6 3 2 c _ p i d = 0
except for the return value of fork
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 10
Execution 2
because data are different
597 632
~
i nt i = 3, c _pi d = - 1;
c _pi d = f or k( ) ;
i f ( c _pi d == 0 )
pr i nt f ( " c hi l d\ n" ) ;
e l s e i f ( c _pi d > 0 )
pr i nt f ( " pa r e nt \ n" ) ;
e l s e
pr i nt f ( " f a i l e d\ n" ) ;
~
i nt i = 3, c _pi d = - 1;
c _pi d = f or k( ) ;
i f ( c _pi d == 0 )
pr i nt f ( " c hi l d\ n" ) ;
e l s e i f ( c _pi d > 0 )
pr i nt f ( " pa r e nt \ n" ) ;
e l s e
pr i nt f ( " f a i l e d\ n" ) ;
DATA
i = 3
DATA
i = 3
c _ p i d = 6 3 2 c _ p i d = 0
program execution differs
597 632
~
i nt i = 3, c _pi d = - 1;
c _pi d = f or k( ) ;
i f ( c _pi d == 0 )
pr i nt f ( " c hi l d\ n" ) ;
e l s e i f ( c _pi d > 0 )
pr i nt f ( " pa r e nt \ n" ) ;
e l s e
pr i nt f ( " f a i l e d\ n" ) ;
~
i nt i = 3, c _pi d = - 1;
c _pi d = f or k( ) ;
i f ( c _pi d == 0 )
pr i nt f ( " c hi l d\ n" ) ;
e l s e i f ( c _pi d > 0 )
pr i nt f ( " pa r e nt \ n" ) ;
e l s e
pr i nt f ( " f a i l e d\ n" ) ;
DATA
i = 3
DATA
i = 3
c _ p i d = 6 3 2 c _ p i d = 0
so parent and child behaviour diverge
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 11
fork based shell server 1
Basic structure:
establish port
loop forever
on each loop:
accept a single client connection
fork a child to manage client
child execs a copy of the shell
N.B. no login very insecure !
' Main loop
ma i n( . . . ) {
/ * ope n por t */
por t _s k = t c p_pa s s i ve _ope n( por t )
/ * l oop f or e ve r a c c e pt i ng c l i e nt s */
whi l e ( a c c e pt _one ( por t _s k) > 0 ) ;
/ * on e r r or c l os e a nd e xi t */
c l os e ( por t _s k) ;
e xi t ( 0) ;
}
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 12
fork based shell server 2
^ Process each client in turn
a c c e pt _one ( i nt por t _s k ) {
/ * accept a single connection */
c l i e nt _s k = t c p_a c c e pt ( por t _s k) ;
/ * perform fork */
c hi l d_pi d = f or k( ) ;
child gets zero return from fork
i f ( c hi l d_pi d == 0 ) {
/ * child closes passive port */
c l os e ( por t _s k) ;
/ * then starts its own behaviour */
e xe c _a _s he l l ( c l i e nt _s k) ;
}
parent gets child process id returned from fork
e l s e i f ( c hi l d_pi d > 0 ) {
/ * parent closes client socket */
c l os e ( c l i e nt _s k) ;
/ * N.B. child has open descriptor */
/ * so client is not cut off */
/ * returns child pid to main loop */
r e t ur n c hi l d_pi d;
}
negative result on failure
e l s e r e t ur n 0;
}
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 13
fork based shell server 3
Child e xe c s a copy of the shell
N.B. only the child process calls this function
i nt e xe c _a _s he l l ( i nt f d) / * doe s n' t r e t ur n */
{
i nt t t y_f d; ;
shell will expect I/ O from standard file descriptors
use 'dup2' system call to link them to f d
dup2( f d, 0) ; / * standard input from fd */
dup2( f d, 1) ; / * standard output to fd */
dup2( f d, 2) ; / * standard error to fd */
c l os e ( f d) ;
e xe c v( " / bi n/ s h" , a r gv) ;
exec only returns if it fails
standard error has been closed
so need to open / de v/ t t y explicitly
t t y_f d = ope n( " / de v/ t t y" , 1) ;
wr i t e ( t t y_f d, e xe c _f a i l _me s s ) ;
_e xi t ( 1) ;
}
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 14
dup2 system call
i nt r e s = dup2( ol d_f d, ne w_f d) ;
makes ne w_f d point to same file/ stream as ol d_f d
ne w_f d is closed if already open
most often used with standard I/ O descriptors:
dup2( f d, 0) ;
standard input reads from f d
can close the old descriptor
. . . but new descriptor still works
dup2( f d, 0) ;
c l os e ( f d) :
n = r e a d( 0, buf f , buf f _l e n) ;
negative return on failure
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 15
exec system call
e xe c v( c ha r *pr og, c ha r **a r gv) ;
replaces the current process with pr og
never returns except on failure
a r gv is passed to the 'ma i n' of pr og
N.B. needs at least a r gv[ 0] set to program name
new process:
code replaced by pr og
data reinitialised
system data partly retained
+ file descriptors still open
several variants (e xe c l , e xe c vp, . . . )
often used after f or k to spawn a fresh program
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 16
exec vs. fork
fork duplicates process
exec replaces process
code
data
system
597
code
data
system
632
code
data
system
597
code
data
system
493
code
data
system
493
fork exec
fork child shares open file descriptors
exec-ed process retains open fds
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 17
death of a forked process
when parent dies
children become orphans !
system init process 'adopts' them
when child dies
parent (or init) informed by signal
( SI GCHLD )
child process partly destroyed
rump retained until parent 'reaps'
using wa i t or wa i t 3 system call
until then child is 'zombie'
ps says <e xi t i ng> or <de f unc t >
N.B. zombie state necessary so parent
can discover which child died
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 18
SIGCHLD & wait3
if parent does not reap children
. . . they stay zombies forever
. . . system resources may run out
' first catch your signal
s i gna l ( my_r e a pe r , SI GCHLD) ;
function 'my_r e a pe r ' called when signal arrives
Z then reap a child
i nt my_r e a pe r ( )
{
uni on wa i t s t a t us ;
whi l e ( wa i t 3( &s t a t us , WNOHANG, NULL) >= 0 ) ;
}
use WNOHANG so that wa i t 3 doesn't block
loop to reap multiple children
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 19
fork and I/O
low-level I/ O
C stdio is buffered:
duplicated at fork
may get flushed after fork
duplicate writes
7 s t de r r OK unbuffered
careful with stdio
use s t de r r or s e t buf f ( f d, NULL)
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 20
Hands on
copy the following from t c p/ s e s s i on6:
kni f e . c
ma ke 6
compile kni f e . c :
ma ke - f ma ke 6 kni f e
launch the knife server: kni f e . c :
i o 3% kni f e - por t 2345
connect to it from a different machine or window
kl a h 7% t e l ne t i o 2345
do you get a shell prompt?
try something simple like
e c ho he l l o
then try ps
what happens?
try typing a # at the end of each line
e c ho he l l o#
ps #
what is happening?
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 21
inet demon
there are many Internet services:
ftp, telnet, rlogin, echo, etc.
a server for each is expensive
i ne t d is a multi-service server
it does a passive open on lots of ports:
21 ftp, 25 SMTP, etc.
when a client connects
it forks the appropriate service
remote logins somewhat complicated
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 22
remote login
First solution . . .
. . . simply fork a shell or getty
no translation of codes
e.g. end of line sequence
no terminal driver at server end
no tty control by application
e.g. editors need tty raw mode
Actual solution . . .
. . . intermediate process
server-end process
between client and shell/ getty
7 can perform translation
7 pseudo-tty between it and shell
server-end tty control
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 23
remote login 2
' remote login client connects to server
client
server
Z server forks child to handle login
client
child server
fork
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 24
remote login 3
child then forks another process
/ de v
client
child
server
fork and
exec
shell
J the new process connects to the child
using a pseudo-terminal
and finally execs a shell (or getty etc.)
+ user is now connected to shell
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 25
remote login 4
client and server-side child similar
both connected to network
both connected to (pseudo)terminal
general algorithm:
echo terminal input to network
echo network input to terminal
N.B. both concurrent
difference in use of terminal:
where
client application end of tty
child 'user' end of pseudo-tty
how
client tty always in raw mode
child pseudo-tty mode set by shell
only one layer of tty processing
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 26
Hands on
echo server
modify kni f e . c to make a forking echo server
your previous echo server (session 2) only dealt
with one client this one will deal with any number
copy kni f e . c into e c ho- a l l
locate the sub-routine where the shell is exec-ed
replace the code duplicating file descriptors and
exec-ing the shell simply have a loop which reads
from the socket and writes back to it
compile and run e c ho- a l l
i o 15% ma ke - f ma ke 6 e c ho- a l l
i o 16% e c ho- a l l - por t 2345
an connect to it:
kl a h 23% t e l ne t i o 2345
there is an alternative solution which only involves
replacing 2 characters of kni f e . c
hint: the answer doesn't involve any dogs
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 27
MTUs
the Internet is heterogeneous
heterogeneous transport layers
different packet sizes
dynamic routing
hops on different layers
unpredictable packet size
transport layer limit called MTU:
maximum transmission unit
transport layer MTU in bytes
Hyperchannel 65535
16Mbps IBM token ring 17914
4Mbps IEEE 802.5 token ring 4464
FDDI 4352
Ethernet 1500
IEEE 802.3/ 802.2 1492
X.25 576
PPP (performance limit) 296
(from RFC 1191)
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 28
IP fragmentation
what happens when size is too small?
fragmentation
any intermediate router detects problem
IP datagram broken into pieces
each sent separately (possibly different routes)
reconstructed at further router or destination
real limit is recipient's buffer size
576 bytes IP datagram guaranteed
... but this includes headers
UDP limit = 512 bytes user data
TCP divides data up for you
limit is UNIX read/ write buffers
only end points matter
in a controlled environment . . .
. . . larger datagrams possible
e.g. NFS = 8192 bytes
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 29
fragmentation considered harmful
fragmentation
IP transparent to underlying link layer MTU
. . . well almost . . .
IP is not reliable
some packets (fragments) may be lost
no re-transmission
IP handles reconstruction . . .
. . . but not fragment retransmission
fragment lost
whole IP datagram lost
probability one fragment lost = p
n fragments
probability IP datagram lost n p
avoiding fragmentation
UDP most protocols 512 bytes
TCP uses local (end-point) MTU
+ path MTU discovery algorithm
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 30
TCP reliability
underlying IP unreliable
TCP must handshake
stream protocol
sender: this is bytes nm of the data
recipient: ack m last byte received
retransmission
recipient: out of order receipt repeat ack
timeout or several repeat acks retransmit
too many acks
avoid lots of little acknowledgement packets
ack of last packet previous packets arrived
piggyback AB ack on BA message
delay acks to allow piggyback
turn off delay for some protocols (e.g. X)
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 31
TCP flow control
Cannot send without limits:
B network capacity packet loss
exponential backoff
rapid resend nightmare scenario
long delay before failure (2-9 mins)
slow-start algorithm
B link-layer buffer
MSS announcement
B TCP buffer
window size announcement
only send to last ack + window size
known to
be received
sent but not
acknowleged
may be sent
before next ack
must be held
at sender end
window size
last ack last byte sent
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 6/ 32
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
UNIX
Network Programming
with TCP/IP
Session 7
Select and
Security
UNIX
Network Programming
with TCP/IP
Session 7
Alan Dix
http://www.hcibook.com/alan
Select and
Security
UNIX events
select system call
proxy server
raw client
security, secrecy and privacy
under attack: viruses & worm
the Internet worm
levels of security
encryption and authentication
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 7/ 1
UNIX Events
Computational programs:
busy most of the time
read/ write when they are ready
Interactive programs:
servers & clients
idle most of the time
respond to events
UNIX processes 4 types of event
' signal (interrupt)
Z time (alarm)
input ready
read will not block
J output can accept (more) data
write will not block
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 7/ 2
Responding to events
Events:
' signal (interrupt)
Z time (alarm)
input (read) ready
J output (write) ready
Responding
interrupt handler '
&
Z
use s i gna l system call
use s e t i t i me r to send SI GALRM
turntaking Z
,
&
J
call r e a d/ wr i t e when ready
use s l e e p for delays
polling Z
,
&
J
use non-blocking r e a d/ wr i t e
use t i me to do things at specific times
wait for several events
use s e l e c t system call
timeout or SI GALRM
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 7/ 3
polling in UNIX
#i nc l ude <s ys / f i l i o. h>
i oc t l ( f d, FI ONBI O, 1) ;
call to i oc t l tells system:
dont block on r e a d/ wr i t e
polling therefore possible
structure of polling telnet-like client:
i oc t l ( t t y_f d, FNBI O, 1) ;
i oc t l ( ne t _f d, FNBI O, 1) ;
f or ( ; ; ) {
/ * a ny t e r mi na l i nput ? */
n = r e a d( t t y_f d, buf f , buf f _l e n) ;
i f ( n > 0 ) { / * ye s ! do s ome t hi ng */ }
/ * a ny ne t wor k i nput ? */
n = r e a d( ne t _f d, buf f , buf f _l e n) ;
i f ( n > 0 ) { / * ye s ! do s ome t hi ng */ }
}
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 7/ 4
read & write
r e a d:
waits on one file descriptor
returns when input data is ready
and reads the data into a buffer
r e a d( 0, buf f , l e n)
wr i t e :
waits on one file descriptor
returns when output is possible
and writes the data from the buffer
wr i t e ( 1, buf f , l e n)
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 7/ 5
select
s e l e c t :
waits on many file descriptor
returns when input or output ready
but does no actual I/ O
+ also allows timeout
s e l e c t ( wi dt h, &i n_f ds , &out _f ds , &e r r _f ds , &t i me out )
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 7/ 6
select system call 2
i nt r e t =
s e l e c t ( s i z e , &i n_f ds , &out _f ds , &e r r _f ds , &t i me out ) ;
i n_f ds , out _f ds :
bitmaps of file descriptors
setting:
FD_ZERO( &i n_f ds ) ;
FD_SET( f d, &i n_f ds ) ;
FD_CLR( f d, &i n_f ds ) ;
testing:
i f ( FD_I SSET( f d, &i n_f ds ) ) . . .
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 7/ 8
select and I/O 2
input
terminal/ socket
r e a d will not block
passive socket
a c c e pt will not block
output
terminal/ socket
wr i t e ready
wr i t e relies on system resources
change between s e l e c t and wr i t e ?
wr i t e may block
+ use non-blocking wr i t e
can get away without s e l e c t on wr i t e
. . . but dangerous!
UNIX
TCP/IP
Short Course Notes Alan Dix 1996 7/ 9
select and timeouts
#i nc l ude <s ys / t i me . h>
s t r uc t t i me va l t i me out ;
t i me out . t v_s e c s
t i me out . t v_ms
maximum time to wait in seconds and ms
modified by call?
doesnt now . . .
. . . but may do one day