1. Lecture 17 Overview

2. I/O Multiplexing
We often need to be able to monitor multiple descriptors:
a generic TCP client (like telnet)
a server that handles both TCP and UDP
Client that can make multiple concurrent requests
browser
STDIN
STDOUT
TCP SOCKET
CPE 401/601 Lecture 17 : I/O Multiplexing

3. Options Use multiple processes/threads Use nonblocking I/O
use fcntl() to set O_NONBLOCK
Use alarm and signal handler to interrupt slow system calls
Use functions that support checking of multiple input sources at the same time
CPE 401/601 Lecture 17 : I/O Multiplexing

4. Non blocking I/O
Tell kernel not to block a process if I/O requests can not be completed
use fcntl() to set O_NONBLOCK:
int flags;
flags = fcntl(sock,F_GETFL,0);
fcntl(sock,F_SETFL,flags | O_NONBLOCK);
Now calls to read() (and other system calls) will return an error and set errno to EWOULDBLOCK
CPE 401/601 Lecture 17 : I/O Multiplexing

5. Non blocking I/O
while (! done) { if ( (n=read(STDIN_FILENO,…)<0)) if (errno != EWOULDBLOCK) /* ERROR */ else write(tcpsock,…) if ( (n=read(tcpsock,…)<0)) else write(STDOUT_FILENO,…) }
CPE 401/601 Lecture 17 : I/O Multiplexing

6. The problem with nonblocking I/O
Using blocking I/O allows the OS to put your process to sleep when nothing is happening
Once input arrives, the OS will wake up your process and read() (or whatever) will return
With nonblocking I/O, the process will chew up all available processor time!!!
CPE 401/601 Lecture 17 : I/O Multiplexing

7. Using alarms
signal(SIGALRM, sig_alrm); alarm(MAX_TIME); read(STDIN_FILENO,…); ... read(tcpsock,…);
A function you write
CPE 401/601 Lecture 17 : I/O Multiplexing

8. Select()
The select() system call allows us to use blocking I/O on a set of descriptors
file, socket, …
We can ask select to notify us when data is available for reading on either STDIN or a socket
CPE 401/601 Lecture 17 : I/O Multiplexing

9. select() maxfd: highest number assigned to a descriptor
int select( int maxfd,
fd_set *readset,
fd_set *writeset,
fd_set *excepset,
const struct timeval *timeout);
maxfd: highest number assigned to a descriptor
readset: set of descriptors we want to read from
writeset: set of descriptors we want to write to
excepset: set of descriptors to watch for exceptions
timeout: maximum time select should wait
CPE 401/601 Lecture 17 : I/O Multiplexing

10. Using select() Create fd_set Clear the whole thing with FD_ZERO
Add each descriptor you want to watch using FD_SET
Call select
when select returns, use FD_ISSET to see if I/O is possible on each descriptor
CPE 401/601 Lecture 17 : I/O Multiplexing

11. System Calls and Errors
In general, systems calls return a negative number to indicate an error.
We often want to find out what error.
Servers generally add this information to a log.
Clients generally provide some information to the user.
CPE 401/601 Lecture 17 : Error Handling

12. extern int errno;
Whenever an error occurs, system calls set the value of the global variable errno
You can check errno for specific errors
errno is valid only after a system call has returned an error.
System calls don't clear errno on success.
If you make another system call you may lose the previous value of errno.
printf makes a call to write!
CPE 401/601 Lecture 17 : Error Handling

13. Error codes Error codes are defined in errno.h Support routines
EAGAIN EBADF EACCESS
EBUSY EINTR EINVAL
EIO ENODEV EPIPE …
Support routines
void perror(const char *string);
stdio.h
char *strerror(int errnum);
string.h
CPE 401/601 Lecture 17 : Error Handling

14. General Strategies
Include code to check for errors after every system call.
Develop "wrapper functions" that do the checking for you.
Develop layers of functions, each hides some of the error-handling details.
CPE 401/601 Lecture 17 : Error Handling

15. Example wrapper
int Socket( int f, int t, int p) { int n; if ( (n=socket(f,t,p)) < 0 ) ) { perror("Fatal Error"); exit(1); } return(n);
CPE 401/601 Lecture 17 : Error Handling

16. Wrappers are great!
Wrappers like those used in the text can make code much more readable.
There are always situations in which you cannot use the wrappers
Sometimes system calls are "interrupted" (EINTR)
this is not always a fatal error !
CPE 401/601 Lecture 17 : Error Handling

17. Another approach
Instead of simple wrapper functions, you might develop a layered system
The idea is to "hide" the sockaddr and error handling details behind a few custom functions:
int tcp_client(char *server, int port);
int tcp_server(int port);
CPE 401/601 Lecture 17 : Error Handling

18. Layers and Code Re-use
Developing general functions that might be re-used in other programs is obviously "a good thing".
Layering is beneficial even if the code is not intended to be re-used:
hide error-handling from "high-level" code.
hide other details.
often makes debugging easier.
CPE 401/601 Lecture 17 : Error Handling

19. Identifying the Server
Options:
hard-coded into the client program
require that the user identify the server
read from a configuration file
use a separate protocol/network service to lookup the identity of the server
Need an IP address, protocol and port
We often use host names instead of IP addresses
usually the protocol is not specified by the user
often the port is not specified by the user
CPE 401/601 Lecture 17 : Client/Server Issues

20. Services and Ports
Many services are available via “well known” addresses (names).
There is a mapping of service names to port numbers:
struct *servent getservbyname(
char *service, char *protocol );
servent->s_port is the port number in network byte order
CPE 401/601 Lecture 17 : Client/Server Issues

21. UDP Client Design Establish server address (IP and port)
Allocate a socket
Specify that any valid local port and IP address can be used
Communicate with server (send, recv)
Close the socket
CPE 401/601 Lecture 17 : Client/Server Issues

22. Connected mode UDP
A UDP client can call connect() to establish the address of the server
The UDP client can then use read() and write() or send() and recv()
A UDP client using a connected mode socket can only talk to one server
using the connected-mode socket
CPE 401/601 Lecture 17 : Client/Server Issues

23. TCP Client Design Establish server address (IP and port)
Allocate a socket
Specify that any valid local port and IP address can be used
Call connect()
Communicate with server (read, write)
Close the connection
CPE 401/601 Lecture 17 : Client/Server Issues

24. Closing a TCP socket Many TCP based application protocols support
multiple requests and/or
variable length requests over a single TCP connection
How does the server known when the client is done ?
and it is OK to close the socket ?
CPE 401/601 Lecture 17 : Client/Server Issues

25. Partial Close
One solution is for the client to shut down only it’s writing end of the socket.
The shutdown() system call provides this function.
shutdown(int s, int direction);
direction can be 0 to close the reading end or 1 to close the writing end.
shutdown sends info to the other process!
CPE 401/601 Lecture 17 : Client/Server Issues

26. TCP sockets programming
Common problem areas:
null termination of strings.
reads don’t correspond to writes.
synchronization (including close()).
ambiguous protocol.
CPE 401/601 Lecture 17 : Client/Server Issues

27. TCP Reads
Each call to read() on a TCP socket returns any available data
up to a maximum
TCP buffers data at both ends of the connection.
You must be prepared to accept data 1 byte at a time from a TCP socket!
CPE 401/601 Lecture 17 : Client/Server Issues

28. Concurrent vs. Iterative
Large or variable size requests
Harder to program
Typically uses more system resources
Iterative
Small, fixed size requests
Easy to program
CPE 401/601 Lecture 17 : Client/Server Issues

29. Connectionless vs. Connection-Oriented
EASY TO PROGRAM
transport protocol handles the tough stuff.
requires separate socket for each connection.
Connectionless
less overhead
no limitation on number of clients
CPE 401/601 Lecture 17 : Client/Server Issues

30. Statefullness
State: Information that a server maintains about the status of ongoing client interactions.
Clients can go down at any time.
Client hosts can reboot many times.
The network can lose messages.
The network can duplicate messages.
Connectionless servers that keep state information must be designed carefully!
CPE 401/601 Lecture 17 : Client/Server Issues

31. Concurrent Server Design Alternatives
One child per client
Spawn one thread per client
Preforking multiple processes
Prethreaded Server
CPE 401/601 Lecture 17 : Client/Server Issues

32. One child per client Traditional Unix server:
TCP: after call to accept(), call fork().
UDP: after recvfrom(), call fork().
Each process needs only a few sockets.
Small requests can be serviced in a small amount of time.
Parent process needs to clean up after children!!!!
call wait()
CPE 401/601 Lecture 17 : Client/Server Issues

33. One thread per client Almost like using fork
call pthread_create instead
Using threads makes it easier to have sibling processes share information
less overhead
Sharing information must be done carefully
use pthread_mutex
CPE 401/601 Lecture 17 : Client/Server Issues

34. Prefork()’d Server
Creating a new process for each client is expensive.
We can create a bunch of processes, each of which can take care of a client.
Each child process is an iterative server.
CPE 401/601 Lecture 17 : Client/Server Issues

35. Prefork()’d TCP Server
Initial process creates socket and binds to well known address.
Process now calls fork() a bunch of times.
All children call accept().
The next incoming connection will be handed to one child.
CPE 401/601 Lecture 17 : Client/Server Issues

36. Preforking Having too many preforked children can be bad.
Using dynamic process allocation instead of a hard-coded number of children can avoid problems.
Parent process just manages the children
doesn’t worry about clients
CPE 401/601 Lecture 17 : Client/Server Issues

37. Sockets library vs. system call
A preforked TCP server won’t usually work the way we want if sockets is not part of the kernel:
calling accept() is a library call, not an atomic operation.
We can get around this by making sure only one child calls accept() at a time using some locking scheme.
CPE 401/601 Lecture 17 : Client/Server Issues

38. Prethreaded Server Same benefits as preforking.
Can also have the main thread do all the calls to accept()
and hand off each client to an existing thread
CPE 401/601 Lecture 17 : Client/Server Issues

39. Lecture 18 Network Management
CPE 401 / 601
Computer Network Systems
slides are modified from Dave Hollinger
slides are modified from Jim Kurose, Keith Ross

40. Outline What is network management?
Internet-standard management framework
Structure of Management Information: SMI
Management Information Base: MIB
SNMP Protocol Operations and Transport Mappings
Security and Administration
ASN.1
CPE 401/601 Lecture 18 : Network Management

41. What is network management?
autonomous systems (aka “network”)
100s or 1000s of interacting hardware/software components
"Network management includes the deployment, integration and coordination of the hardware, software, and human elements to monitor, test, poll, configure, analyze, evaluate, and control the network and element resources to meet the real-time, operational performance, and Quality of Service requirements at a reasonable cost.“
CPE 401/601 Lecture 18 : Network Management

42. Infrastructure for network management
managing entity
agent
data
managing
entity
data
managed devices contain
managed objects whose
data is gathered into a
Management Information
Base (MIB)
managed device
agent
data
network
management
protocol
managed device
agent
data
agent
data
managed device
managed device
CPE 401/601 Lecture 18 : Network Management

43. Network Management standards
OSI CMIP
Common Management Information Protocol
designed 1980’s:
unifying net management standard
too slowly standardized
CPE 401/601 Lecture 18 : Network Management

44. Network Management standards
SNMP: Simple Network Management Protocol
Internet roots
SGMP: Simple Gateway Monitoring Protocol
started simple
deployed, adopted rapidly
growth: size, complexity
currently: SNMP V3
de facto network management standard
CPE 401/601 Lecture 18 : Network Management

45. SNMP overview: 4 key parts
Management information base (MIB):
distributed information store of network management data
Structure of Management Information (SMI):
data definition language for MIB objects
SNMP protocol
convey manager<->managed object info, commands
security, administration capabilities
major addition in SNMPv3
CPE 401/601 Lecture 18 : Network Management

46. Structure of Management Information
Basic Data Types
Purpose: syntax, semantics of management data well-defined, unambiguous
base data types:
straightforward
OBJECT-TYPE
data type, status, semantics of managed object
MODULE-IDENTITY
groups related objects into MIB module
CPE 401/601 Lecture 18 : Network Management

47. SNMP MIB MIB module specified via SMI MODULE-IDENTITY
(100 standardized MIBs, more vendor-specific)
MODULE
OBJECT TYPE:
OBJECT TYPE:
OBJECT TYPE:
objects specified via SMI
OBJECT-TYPE construct
CPE 401/601 Lecture 18 : Network Management

48. SMI: Object, module examples
OBJECT-TYPE: ipInDelivers
ipInDelivers OBJECT TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
“The total number of input
datagrams successfully
delivered to IP user-
protocols (including ICMP)”
::= { ip 9}
CPE 401/601 Lecture 18 : Network Management

49. SMI: Object, module examples
OBJECT-TYPE: ipMIB
ipMIB MODULE-IDENTITY
LAST-UPDATED “ Z”
ORGANZATION “IETF SNPv2
Working Group”
CONTACT-INFO
“ Keith McCloghrie
……”
DESCRIPTION
“The MIB module for managing IP
and ICMP implementations, but
excluding their management of
IP routes.”
REVISION “ Z”
………
::= {mib-2 48}
CPE 401/601 Lecture 18 : Network Management

50. MIB example: UDP module
Object ID Name Type Comments
UDPInDatagrams Counter32 total # datagrams delivered
at this node
UDPNoPorts Counter32 # underliverable datagrams
no app at portl
UDInErrors Counter32 # undeliverable datagrams
all other reasons
UDPOutDatagrams Counter32 # datagrams sent
udpTable SEQUENCE one entry for each port
in use by app, gives port #
and IP address
CPE 401/601 Lecture 18 : Network Management

51. SNMP Naming
question: how to name every possible standard object (protocol, data, more..) in every possible network standard??
answer: ISO Object Identifier tree:
hierarchical naming of all objects
each branchpoint has name, number
ISO
ISO-ident. Org.
US DoD
Internet
udpInDatagrams
UDP
MIB2
management
CPE 401/601 Lecture 18 : Network Management

52. Object Identifier Tree
OSI
Object Identifier Tree
CPE 401/601 Lecture 18 : Network Management

53. SNMP protocol Two ways to convey MIB info, commands: request trap msg
managing
entity
managing
entity
request
trap msg
response
agent
data
agent
data
Managed device
Managed device
request/response mode
trap mode
CPE 401/601 Lecture 18 : Network Management

54. SNMP protocol: message types
Function
GetRequest
GetNextRequest
GetBulkRequest
Mgr-to-agent: “get me data”
(instance,next in list, block)
InformRequest
Mgr-to-Mgr: here’s MIB value
SetRequest
Mgr-to-agent: set MIB value
Agent-to-mgr: value, response to
Request
Response
Trap
Agent-to-mgr: inform manager
of exceptional event
CPE 401/601 Lecture 18 : Network Management

55. SNMP protocol: message formats
CPE 401/601 Lecture 18 : Network Management

56. SNMP security and administration
encryption: DES-encrypt SNMP message
authentication: compute, send MIC(m,k):
compute hash (MIC) over message (m), secret shared key (k)
protection against playback: use nonce
view-based access control
SNMP entity maintains database of access rights, policies for various users
database itself accessible as managed object!
CPE 401/601 Lecture 18 : Network Management

57. The presentation problem
Q: does perfect memory-to-memory copy solve “the communication problem”?
A: not always!
struct {
char code;
int x;
} test;
test.x = 256;
test.code=‘a’
test.code
test.x a
test.code
test.x a
host 1 format
host 2 format
problem: different data format, storage conventions
CPE 401/601 Lecture 18 : Network Management

58. A real-life presentation problem:
grandma
teenager
aging 60’s
hippie
CPE 401/601 Lecture 18 : Network Management

59. Presentation problem: potential solutions
Sender learns receiver’s format and translates into receiver’s format. Sender sends.
Sender sends. Receiver learns sender’s format and translate into receiver-local format
Sender translates host-independent format and sends. Receiver translates to receiver-local format.
CPE 401/601 Lecture 18 : Network Management

60. Solving the presentation problem
Translate local-host format to host-independent format
Transmit data in host-independent format
Translate host-independent format to remote-host format
CPE 401/601 Lecture 18 : Network Management

61. ASN.1: Abstract Syntax Notation 1
ISO standard X.680
used extensively in Internet
defined data types, object constructors
like SMI
BER: Basic Encoding Rules
specify how ASN.1-defined data objects to be transmitted
each transmitted object has Type, Length, Value (TLV) encoding
CPE 401/601 Lecture 18 : Network Management

62. TLV Encoding Idea: transmitted data is self-identifying
T: data type, one of ASN.1-defined types
L: length of data in bytes
V: value of data, encoded according to ASN.1 standard
Tag Value Type 1 2 3 4 5 6 9
Boolean
Integer
Bitstring
Octet string
Null
Object Identifier
Real
CPE 401/601 Lecture 18 : Network Management

63. TLV encoding Value, 259 Length, 2 bytes Type=2, integer
Value, 5 octets (chars)
Length, 5 bytes
Type=4, octet string
CPE 401/601 Lecture 18 : Network Management

64. Network Management network management
extremely important: 80% of network “cost”
ASN.1 for data description
SNMP protocol as a tool for conveying information
Network management: more art than science
what to measure/monitor
how to respond to failures?
alarm correlation/filtering?
CPE 401/601 Lecture 18 : Network Management