UDP: User Datagram Protocol • RFC 768 [Postel 1980]: about three pages. Networking • provides no reliability – it sends the datagram to the IP layer, but there is no guarantee that: • it will reach its destination • it will reach unspoiled its destination UDP - checksum UDP encapsulation 32-bit source IP address pseudo 32-bit destination IP address IP datagram header* 16-bit UDP 8-bit zero protocol(17) length 16-bit UDP datagram 16-bit source port destination number port number header IP UDP UDP 16-bit UDP header header data 16-bit UDP length checksum data (*) not transmitted, only used for checksum calculations IP: Internet Protocol UDP fragmentation 4-bit 8-bit type of 4-bit header service 16-bit total length (in bytes) IP datagram version length (TOS) 3-bit IP UDP 16-bit identification 13-bit fragment offset UDP data (1473 bytes) flags header header 8-bit time to 20 bytes 20 bytes 8 bytes live 8-bit protocol 16-bit header checksum (TTL) 32-bit source IP address 32-bit destination IP address IP UDP IP 1472 bytes options (if any) header header header 20 bytes 1 byte 20 bytes 8 bytes data packet packet IP Datagram 1
format TFTP Trivial File Transfer protocol IP UDP TFTP message header header • uses UDP as its transport mechanism opcode null terminated string (2 bytes) • mainly used to bootstrap diskless systems read • RFC 1350[Sollins 1992] is the official 01 filename 0 mode 0 write spec. 02 octet: binary/raw – RFC 2347, 2348, 2349 specify newer ascii: convert nl to cr/nl extensions. 2 bytes • lock-step protocol data block 03 data 0 to 512 bytes # ack block 04 # error error 05 null terminated message # the protocol TFTP ... client server read request • is a stop and wait protocol 01 some-file 0 octet 0 data • each data-block has a block number 01 03 data ack – used in the acknowledge response 01 04 • lost packets are detected with timeout and retransmission implemented on the sender side. 03 02 data • has no checksum / data integrity check – handled by the UDP layer 03 nn < block size • has no security 04 nn why are protocols so difficult? the Fix RRQ data 1 ACK 1 data 2 time out ACK 1 data 2 •ignore duplicate ACKs ACK 2 data 3 ACK 2 data 3 time out The sorcerer's apprentice syndrome 2
DNS tftp extensions T he Domain Name System • Server UDP IP TFTP message header header – manage a distributed data base opcode – process queries/requests (2 bytes) 1=RRQ filename 0 mode 0 option1 0 value1 0 option2 0 value2 0 • Client: 2=WRQ – does queries 0 option2 0 value2 0 – uses the resolver library functions 6=OACK option1 0 value1 • ie: gethostbyname(...), gethostbyaddr(...) 4=ACK 0 DNS basics DNS Zones unnamed root . • a zone is a subtree of the DNS tree that is administered separately. • each zone needs at least one name- arpa ... com org edu il server. • each zone needs at least one in-addr ac administrator. huji cse DNS Message Format Zones ... 0 15 16 31 • Primary name server identification flags – obtains its data locally 12 bytes • Secondary name server # of questions # of answer RRs header – obtains its data from the primary # of authority RRs # of additional RRs questions variable answers length authority fields additional information 3
format ... DNS - Summary • essential when host is connected to the internet. •identification: set by the client and • hierarchical tree that forms the DNS name returned by the server. space. •flags: • all DNS queries and responses have the same message format. QR opcode AA TC RD RA MBZ rcode 4 3 4 #include <stdio.h> #include <syslog.h> #include <time.h> while(1) { #include <string.h> int len; #include <sys/types.h> time_t clock; #include <sys/socket.h> #include <netinet/in.h> /* len = sizeof(sin); | daytime server - RFC 867 if(recvfrom(sfd, buf, 1, 0, (struct sockaddr *)&sin, &len) */ < 0) { main(int cc, char **vv) { perror("recvfrom"); struct sockaddr_in sin; continue; char buf[BUFSIZ]; } int sfd; time(&clock); strcpy(buf, ctime(&clock)); if((sfd = socket(PF_INET, SOCK_DGRAM, 0)) < 0) { perror("socket"); if(sendto(sfd, buf, strlen(buf), 0, exit(1); (struct sockaddr *)&sin, sizeof(sin)) < 0) { } perror("sendto"); bzero(&sin, sizeof(struct sockaddr_in)); } sin.sin_family = AF_INET; sin.sin_port = htons(13); } } if(bind(sfd, (struct sockaddr *)&sin, sizeof(sin)) < 0) { perror("bind"); exit(1); } Clients & Servers Concurrent Vs. Iterative • Client: • concurrent-server – in general, an application that initiates a peer-to-peer – handles multiple requests at one time. communication. • iterative-server – usually invoked by the 'end user' – process one request at a time. • Server: – waits for incoming requests from a client. – performs necessary work and – probably returns a result. 4
Connection [oriented|less] types of server/client • connectionless: iterative – UDP - User Datagram Protocol iterative connection- connectionless – the burden of the data integrity is on the application. oriented • connection-oriented: concurrent concurrent – TCP - Transport Control Protocol connection- connectionless – the application is free to deal with higher things. oriented Server types server types ... • iterative, connectionless • concurrent, connectionless – the most common – very uncommon • usually stateless • a process is created for each request • trivial amount of processing • tfptd is such a server • iterative, connection-oriented • concurrent, connection-oriented – less common – the most common • trivial amount of data but • reliable transport • need relaible transport • usually used by long living activities reliable TCP - Transmission Control Protocol • connection oriented • data is broken up into best size chunks – the unit of information passed by TCP to IP is called a segment. – exactly two end points. • each segment sent has a timer • no broadcast/multicast – when the timer expires before an acknowledgment is received, the – the two applications must establish a connection with segment is retransmitted. each other before data can be exchanged. • when data is received, an acknowledgment is sent • reliable – but not immediately. • byte stream • the data and header have a checksum – a segment with bad/invalid checksum is dropped, the sender times – 8-bit bytes with no interpretation out and retransmits – there is no record boundaries. 5
reliable ... TCP encapsulation • preserves sequence – IP datagrams can arrive out of order IP datagram – segments are resequenced if necessary • drops duplicates TCP segment – since IP datagrams can get duplicated IP TCP TCP • flow control header header data – each end of the connection has a finite amount of buffer space. – the receiving side allows the other end to send as much data as it has buffer for. TCP Header TCP Header ... 16-bit source port 16-bit destination port number number • each segment contains a source and 32-bit sequence number destination port number. 20 32-bit acknowledgment number bytes • together with the source and destination 4-bit IP number from the IP header we get an 6-bit max header 16-bit window size 60 flags unique identification of each connection. length bytes • socket: IP address + port number 16-bit TCP checksum 16-bit urgent pointer • socket pair: source + destination sockets. options (if any) data (if any) TCP Header ... connection establishment flags Description 1. the client dials a # 2. the server answers, Hello? the urgent pointer is valid URG 3. who's calling? ACK the acknowledgment is valid the receiver should pass this data ASAP PSH RST Reset the connection Synchronous sequence number to init SYN connection FIN the sender has finished sending data 6
client server Connection Establishment SYN - isn the three way handshake segment 1 1. the client sends a SYN segment specifying the port # of the server it wants to connect to, and SYN - isn' segment 2 its ISN - Initial Sequence Number ack isn+1 2. the server responds with its own SYN segment •isn: initial sequence number containing its ISN. The server also ACKs the –incremented by 1 every 4 client's SYN by ACKing the client's ISN+1 microseconds - actually by ack isn'+1 64,000 every 1/2 sec. segment 3 3. the client must ACK this SYN from the server –incremented on each connection by 64,000 by ACKing the server's ISN+1. Segments, Streams and Sequence numbers TCP - Interactive data flow client server last byte successfully sent keystroke d a t a b y t e acknowledged server ack of data byte ISN + 2 current window echo echo of data byte data stream display ack of echoed byte ready to be sent sent but not acked last byte that can be sent before an ack is received 7
Recommend
More recommend
