network programming intro to distributed systems fall 2013

57
NETWORK PROGRAMMING INTRO TO DISTRIBUTED SYSTEMS FALL 2013 L3-socket Dongsu Han Some material taken from publicly available lecture slides including Srini Seshan’s and David Anderson’s

Upload: kueng

Post on 24-Feb-2016

45 views

Category:

Documents


0 download

DESCRIPTION

Network Programming Intro to Distributed systems Fall 2013. Some material taken from publicly available lecture slides including Srini Seshan’s and David Anderson’s. L3-socket. Dongsu Han. Today’s Lecture. Lecture Transport protocols: UDP and TCP Version control using SVN - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Network Programming Intro to Distributed systems Fall 2013

NETWORK PROGRAMMINGINTRO TO DISTRIBUTED SYSTEMSFALL 2013

L3-socketDongsu Han

Some material taken from publicly available lec-ture slides including Srini Seshan’s and David Anderson’s

Page 2: Network Programming Intro to Distributed systems Fall 2013

Today’s Lecture Lecture

Transport protocols: UDP and TCP Version control using SVN

TA-led programming session Editor, socket programming Debugging with gdb

Announcement Programming Assignment 1 is out. (Due in two weeks-- 추석 )

Page 3: Network Programming Intro to Distributed systems Fall 2013

Review of Previous Lectures What is a distributed system? (L1)

Definition Example

What are some of the important decisions made in the Inter-net architecture? (L2) Narrow waist: Network provides minimal functionality (best-effort)

Why?: to connect existing networks that are heterogeneous Stateless architecture: no per-flow state inside network

Why? For survivability

Page 4: Network Programming Intro to Distributed systems Fall 2013

4

Transport Protocols

Lowest level end-to-end proto-col. Header generated by sender is in-

terpreted only by the destination Routers view transport header as

part of the payload; they are not supposed to see the transport header.

7

6

5

7

6

5

Transport

IP

Datalink

Physical

Transport

IP

Datalink

Physical

IP

router

2 2

1 1

Page 5: Network Programming Intro to Distributed systems Fall 2013

What does the transport layer do? No per-flow (connection) state in the network

Transport layer maintains the connection state. Transport layer identifies an end-to-end connection.

How does the transport layer identify an end-point (ap-plication)?

Page 6: Network Programming Intro to Distributed systems Fall 2013

De-multiplexing: Port numbers Network layer gets you to the host. A port identifies the sending or receiving socket (appli-

cation). A socket is one endpoint of a two-way communication

between two programs running on the network. A socket is bound to a port number so that the transport layer can identify the application that data is destined to be sent.

Identifying two end-points: An endpoint = <IP address, Port #> Source endpoint = <SrcIPAddr, SrcPort> destination endponit = <DestIPAddr, DestPort>

Page 7: Network Programming Intro to Distributed systems Fall 2013

7

Protocol and Port Demultiplexing Multiple choices at each layer Applications open a socket (identified by the port

number)

Port 80 Port 22 Port 22Port 80

TCP UDP

IP

NET1 NET2 NETn…

TCP/UDPIP

Port Number= 80

Network

Protocol Field= TCP

Type Field=IP

Page 8: Network Programming Intro to Distributed systems Fall 2013

8

Server and Client

TCP/UDP

IP

Ethernet Adapter

Server

TCP/UDP

IP

Ethernet Adapter

Clients

Server and Client exchange messages over the net-work through a common Socket API

Socket API

hardware

kernel space

user spaceports

Page 9: Network Programming Intro to Distributed systems Fall 2013

Transport protocols UDP

Provides only integrity and de-multiplexing TCP adds…

Page 10: Network Programming Intro to Distributed systems Fall 2013

10

UDP: User Datagram Protocol [RFC 768]

“No frills,” “bare bones” Internet transport protocol, “Best effort” service

UDP segments may be: Lost, duplicated (bug, spurious retrans-

mission at L2) Delivered out of order to app

Connectionless: No handshaking between UDP sender,

receiver Each UDP segment handled indepen-

dently

Why is there a UDP?• No connection establishment

(which can add delay)• Simple: no connection state

at sender, receiver• Small header• No congestion control: UDP

can blast away as fast as desired

Page 11: Network Programming Intro to Distributed systems Fall 2013

11

UDP, cont. Often used for stream-

ing multimedia apps (e.g., Skype) Loss tolerant Rate sensitive

Other UDP uses (why?): DNS

Reliable transfer over UDP Must be at application

layer Application-specific er-

ror recovery

Source port # Dest port #

32 bits

Applicationdata

(message)

UDP segment format

Length ChecksumLength, in

bytes of UDPsegment,includingheader

Page 12: Network Programming Intro to Distributed systems Fall 2013

Transport protocols UDP

Provides only integrity and de-multiplexing TCP adds…

Connection-oriented Reliable (error control) Ordered byte stream (in-order delivery) Bi-directional byte-stream Flow and congestion controlled

Page 13: Network Programming Intro to Distributed systems Fall 2013

TCP Protocol implemented entirely at the ends

Fate sharing Abstraction provided

Connection oriented protocol (hand-shake or connection establish-ment)

In-order byte-stream Implemented functionality (next lecture)

Flow control Reliability (error control) Reassembly (in-order delivery) Congestion control

Page 14: Network Programming Intro to Distributed systems Fall 2013

Difference in abstraction UDP

Recv(len) call gives you a packet (the payload part)

TCP Connection establishment (hand-shake) Will see in the TA

led session. Recv(len) call give you a sequence of bytes

UDP segment (packet)

Byte stream

UDP segment (packet)

len len

Incoming stream

ApplicationRecv()

len len

Byte stream

Applicationsend()

Page 15: Network Programming Intro to Distributed systems Fall 2013

TCP– What goes on underneath

Byte stream Packet (1~7) Packet (8~10)

Receive buffer

Packet (9~11)

Packet (8~10)

I need seq# 8.

Page 16: Network Programming Intro to Distributed systems Fall 2013

16

User Datagram Protocol(UDP): An Analogy

Example UDP applicationsMultimedia, voice over IP

UDP Single socket to receive mes-

sages No guarantee of delivery Not necessarily in-order delivery Datagram – independent packets Must address each packet

Postal Mail Single mailbox to receive letters Unreliable Not necessarily in-order delivery Letters sent independently Must address each reply

Page 17: Network Programming Intro to Distributed systems Fall 2013

Transmission Control Pro-tocol (TCP): An Analogy

TCP Reliable – guarantee delivery Byte stream – in-order delivery Connection-oriented – single

socket per connection Setup connection followed by

data transfer

Telephone Call Guaranteed delivery In-order delivery Connection-oriented Setup connection followed by

conversation

Example TCP applicationsWeb, Email, Telnet

Page 18: Network Programming Intro to Distributed systems Fall 2013

REVISION CONTROL & MAKE

Page 19: Network Programming Intro to Distributed systems Fall 2013

Overview Revision control systems

Motivation Features Subversion primer

Make Simple gcc Make basics and variables Testing

Useful Unix commands

Page 20: Network Programming Intro to Distributed systems Fall 2013

Dealing with large codebases Complications

Code synchronization Backups Concurrent modifications

Solution: Revision Control System (RCS) Store all of your code in a repository on a server Metadata to track changes, revisions, etc… Also useful for writing books, papers, etc…

Page 21: Network Programming Intro to Distributed systems Fall 2013

Basic RCS features (1/2) Infinite undo

go back to previous revisions Automatic backups

all your code ever, forever saved Changes tracking

see differences between revisions

Page 22: Network Programming Intro to Distributed systems Fall 2013

Basic RCS features (2/2) Concurrency

Multiple people working at the same time Snapshots

Save stable versions on the side (i.e. handin) Branching

Create diverging code paths for experimentation

Page 23: Network Programming Intro to Distributed systems Fall 2013

Typical RCS workflow

1. Create repository on RCS server2. Checkout the repository to your local machine3. Work locally: create, delete and modify files4. Update the repository to check for changes other

people might have made5. Resolve any existing conflicts6. Commit your changes to the repository

Page 24: Network Programming Intro to Distributed systems Fall 2013

RCS implementations Revision Control System (RCS)

Early system, no concurrency or conflict resolution Concurrent Versions System (CVS)

Concurrency, versioning of single files Subversion (SVN)

File and directory moving and renaming, atomic commits

Page 25: Network Programming Intro to Distributed systems Fall 2013

Concurrent edits (1/2)

Carnegie MellonFile v1

Both check out file

Edits (lines 1-20)

File v2

Edits (lines 30-40)

commit

Update

Merged automatically!

Page 26: Network Programming Intro to Distributed systems Fall 2013

Concurrent edits (2/2)

Carnegie MellonFile v1

Both check out file

Edits (lines 1-20)

File v2

Edits (lines 10-20)

commit

Update

Conflict needing manual in-tervention!

Page 27: Network Programming Intro to Distributed systems Fall 2013

Resolving conflicts When changes can’t be merged automatically

SVN gives you 3 files: file.mine : your file file.rx : the remote file file : original file with marked conflicts

You can Discard your changes Discard others’ changes Go over each conflict and arbitrate as appropriate

Page 28: Network Programming Intro to Distributed systems Fall 2013

Interacting with SVN Command line

Readily available in andrew machines Graphical tools

Easier to use Subclipse for Eclipse gives IDE/SVN integration tortoiseSVN

Page 29: Network Programming Intro to Distributed systems Fall 2013

실습 server IP: 143.248.141.52 ~ 143.248.141.59 (8 대 ) ID: your student id (e.g., 20110111) Password: ee324EE#@$

Page 30: Network Programming Intro to Distributed systems Fall 2013

Svn password 20060584 28482 20071122 6534 20081275 51085 20090058 50346 20090276 54586 20100120 23860 20100137 29297 20100441 17889 20100827 30690 20100967 7532 20110343 4967 20110456 9139 20110773 8574 20111047 36671

Page 31: Network Programming Intro to Distributed systems Fall 2013

Command line SVN example (1/2)

$ svn co –-username=“<<student id>>” https://ina.kaist.ac.kr/svn/test

$ cd test/trunk

$ vim <<student id>>.txt$ vim <<student id>>.$ svn add <<student id>>.txt

$ svn commit -m 'adding a text file with my student id‘$ svn update

$ cd ../$ svn cp trunk tags/<<student id>>_submission$ svn commit -m 'making a tag of the trunk for submission!‘

$ echo -e ”<<student id>>" >> student.txt$ svn commit –m “added my student id”

Page 32: Network Programming Intro to Distributed systems Fall 2013

Command line SVN example (2/2)

Revision control lets you note (and then see) what you changed:

> svn log student.txtr986 | ntolia | 2006-08-01 17:13:38 -0400 (Tue, 01 Aug 2006) | 6 lines

This allows the sp to get rid of chunks early before a transfer is complete.Useful when a file is requested in-order and the file size > mem cache size

> svn diff -r 1:2 student.txtIndex: file===================================================================--- file (revision 1)+++ file (revision 2)@@-1,2+1,3@@ This isatestfile -It startedwithtwolines +It nolongerhastwolines +it hasthree

Page 33: Network Programming Intro to Distributed systems Fall 2013

General SVN tips Update, make, test, only then commit Merge often (svn up) Comment commits Avoid commit races Modular design avoids conflicts

Page 34: Network Programming Intro to Distributed systems Fall 2013

Know more

subversion.tigris.org for SVN software & info svnbook.red-bean.com for SVN book

Page 35: Network Programming Intro to Distributed systems Fall 2013

Makefile You are on your own.

Page 36: Network Programming Intro to Distributed systems Fall 2013

Make Utility for executable building automation Saves you time and frustration Helps you test more and better

Page 37: Network Programming Intro to Distributed systems Fall 2013

Simple gcc

If we have files:• prog.c: The main program file• lib.c: Library .c file• lib.h: Library header file

% gcc -c prog.c -o prog.o% gcc -c lib.c -o lib.o% gcc lib.o prog.o -o binary

Page 38: Network Programming Intro to Distributed systems Fall 2013

gcc flags

• Useful flags1. -g: debugging hook2. -Wall: show all warnings3. -Werror: treat warning as errors4. -O0, -O1, -O2, -O3: optimization level5. -DDEBUG: macro for DEBUG (#define DEBUG)

• Avoid using dangerous optimizations that could af-fect correctness

Page 39: Network Programming Intro to Distributed systems Fall 2013

More gcc% gcc -g -Wall -Werror -c prog.c -o prog.o% gcc -g -Wall -Werror -c lib.c -o lib.o% gcc -g -Wall -Werror lib.o prog.o -o binary

This gets boring, fast!

Page 40: Network Programming Intro to Distributed systems Fall 2013

Makefile basics • Build targetstarget: dependency1 dependency2 ...

unix command (start line with TAB)unix command

Page 41: Network Programming Intro to Distributed systems Fall 2013

binary: lib.o prog.ogcc -g -Wall lib.o prog.o -o binary

lib.o: lib.cgcc -g -Wall -c lib.c -o lib.o

prog.o: prog.cgcc -g -Wall -c prog.c -o prog.o

clean:rm *.o binary

Makefile example

Page 42: Network Programming Intro to Distributed systems Fall 2013

Makefile variables (1/7)

• VariablesCC = gcc

CFLAGS = -g -Wall -WerrorOUTPUT = binary

Page 43: Network Programming Intro to Distributed systems Fall 2013

binary: lib.o prog.ogcc -g -Wall lib.o prog.o -o binary

lib.o: lib.cgcc -g -Wall -c lib.c -o lib.o

prog.o: prog.cgcc -g -Wall -c prog.c -o prog.o

clean:rm *.o binary

Makefile variables (2/7)

Page 44: Network Programming Intro to Distributed systems Fall 2013

CC = gccCFLAGS = -g -WallOUTPUT = binary

$(OUTPUT): lib.o prog.o$(CC) $(CFLAGS) lib.o prog.o -o binary

lib.o: lib.c$(CC) $(CFLAGS) -c lib.c -o lib.o

prog.o: prog.c$(CC) $(CFLAGS) -c prog.c -o prog.o

clean:rm *.o $(OUTPUT)

Makefile variables (3/7)

Page 45: Network Programming Intro to Distributed systems Fall 2013

CC = gccCFLAGS = -g -WallOUTPUT = binary

$(OUTPUT): lib.o prog.o$(CC) $(CFLAGS) lib.o prog.o -o binary

lib.o: lib.c$(CC) $(CFLAGS) -c lib.c -o lib.o

prog.o: prog.c$(CC) $(CFLAGS) -c prog.c -o prog.o

clean:rm *.o $(OUTPUT)

Makefile variables (4/7)

Page 46: Network Programming Intro to Distributed systems Fall 2013

CC = gccCFLAGS = -g -WallOUTPUT = binaryOBJFILES = lib.o prog.o

$(OUTPUT): $(OBJFILES)$(CC) $(CFLAGS) $(OBJFILES) -o binary

lib.o: lib.c$(CC) $(CFLAGS) -c lib.c -o lib.o

prog.o: prog.c$(CC) $(CFLAGS) -c prog.c -o prog.o

clean:rm *.o $(OUTPUT)

Makefile variables (5/7)

Page 47: Network Programming Intro to Distributed systems Fall 2013

CC = gccCFLAGS = -g -WallOUTPUT = binaryOBJFILES = lib.o prog.o

$(OUTPUT): $(OBJFILES)$(CC) $(CFLAGS) $(OBJFILES) -o binary

lib.o: lib.c$(CC) $(CFLAGS) -c lib.c -o lib.o

prog.o: prog.c$(CC) $(CFLAGS) -c prog.c -o prog.o

clean:rm *.o $(OUTPUT)

Makefile variables (6/7)

Page 48: Network Programming Intro to Distributed systems Fall 2013

CC = gccCFLAGS = -g -WallOUTPUT = binaryOBJFILES = lib.o prog.o

$(OUTPUT): $(OBJFILES)$(CC) $(CFLAGS) $(OBJFILES) -o binary

%.o: %.c# $<: dependency (%.c)# $@: target (%.o)$(CC) $(CFLAGS) -c $< -o $@

clean:rm *.o $(OUTPUT)

Makefile variables (7/7)

Page 49: Network Programming Intro to Distributed systems Fall 2013

Simple Test Script (1/2)% ./server 6667 &% cat testfile.01 | ./testscript.py% cat testfile.02 | ./testscript.py% killall -9 server

Page 50: Network Programming Intro to Distributed systems Fall 2013

Simple Test Script (2/2)#/bin/sh

echo “Starting server on port 6667.”./server 6667 &SERVERPID = $!

echo “Running test files.”cat testfile.01 | ./testscript.pycat testfile.02 | ./testscript.py

echo “Killing server process.”kill $(SERVERPID)

Page 51: Network Programming Intro to Distributed systems Fall 2013

CC = gccCFLAGS = -g -WallOUTPUT = binaryOBJFILES = lib.o prog.o

all: $(OUTPUT)

$(OUTPUT): $(OBJFILES)$(CC) $(CFLAGS) $(OBJFILES) -o binary

%.o: %.c# $<: dependencies (%.c)# $@: target (%.o)$(CC) $(CFLAGS) -c $< -o $@

clean:rm *.o $(OUTPUT)

Augmenting the Makefile for testing (1/2)

Page 52: Network Programming Intro to Distributed systems Fall 2013

CC = gccCFLAGS = -g -WallOUTPUT = binaryOBJFILES = lib.o prog.o

all: $(OUTPUT) test

$(OUTPUT): $(OBJFILES)$(CC) $(CFLAGS) $(OBJFILES) -o binary

%.o: %.c# $<: dependencies (%.c)# $@: target (%.o)$(CC) $(CFLAGS) -c $< -o $@

test: $(OUTPUT)sh ./testscript.sh

clean:rm *.o $(OUTPUT)

Augmenting the Makefile for testing (2/2)

Page 53: Network Programming Intro to Distributed systems Fall 2013

Using the Makefile% make% make test% make clean

• Know moreGoogle– “makefile example”– “makefile template”– “make tutorial”– Chapter 3 of Dave Andersen’s notes

Page 54: Network Programming Intro to Distributed systems Fall 2013

Extra: useful Unix commands (1/2)

• find “func_name” in files% grep -r func_name .

• replace “bad_func_name” to “good_func_name”% sed -e “s/bad_func_name/good_func_name/g”\prog.c > prog.c.new

Page 55: Network Programming Intro to Distributed systems Fall 2013

Extra: useful Unix commands (2/2)

• find a file named “prog.c”% find -name prog.c

• download files from the Internet% wget http://address/to/file.tar.gz

• untar and unzip a file% tar xzvf file.tar.gz

Page 56: Network Programming Intro to Distributed systems Fall 2013

Assignment You have access to svn repository at

https://ina.kaist.ac.kr/svn/<student id> However, we will change your password (to some un-

known integer). Luckily, we made a server that gives you a hint. When your client asks whether the username and the

password match, the server can tell you whether the password provided is less than, equal to, or greater than your real password.

Page 57: Network Programming Intro to Distributed systems Fall 2013

Assignment I Protocol is defined in the document. (See course web

page).Query

Response

Server (provided by the in-structor)Client

Part I: Assume the network is reliable. (due 9/23) Part II: The server may drop a packet. (due 9/27)