Lecture 17 Overview

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SMI: Object, module examples OBJECT-TYPE: ipMIB ipMIB MODULE-IDENTITY LAST-UPDATED “941101000Z” 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 “019331000Z” ……… ::= {mib-2 48} CPE 401/601 Lecture 18 : Network Management

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

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 1.3.6.1.2.1.7.1 ISO ISO-ident. Org. US DoD Internet udpInDatagrams UDP MIB2 management CPE 401/601 Lecture 18 : Network Management

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

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

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

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

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

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 00000001 00000011 test.code test.x a 00000011 00000001 host 1 format host 2 format problem: different data format, storage conventions CPE 401/601 Lecture 18 : Network Management

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

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

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

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

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

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

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