Roadmap Applicat ion Layer (User level) 16: Applicat ion, Transport - PDF document

Roadmap � Applicat ion Layer (User level) 16: Applicat ion, Transport , � Transport Layer (OS) Net work and Link Layers � Net work Layer (OS) � Link Layer (Device Driver, Adapt er Card) Last Modif ied: 7/ 3/ 2004 1:46:53 PM -1 -2 Applicat ion Layer Applicat ions and applicat ion-layer prot ocols Applicat ion: communicat ing, applicat ion � Net work Applicat ions Drive Net work t ransport dist ribut ed processes net work dat a link Design � running in net work host s in physical “user space” � I mport ant t o remember t hat net work � exchange messages t o applicat ions are t he reason we care about implement app building a net work inf rast ruct ure � e.g., email, f ile t ransf er, � Applicat ions range f rom t ext based t he Web command line ones popular in t he 1980s Applicat ion- layer prot ocols applicat ion (like t elnet , f t p, news, chat , et c) t o � one “piece” of an app applicat ion t ransport t ransport net work net work � def ine messages dat a link mult imedia applicat ions (Web browsers, dat a link physical physical exchanged by apps and audio and video st reaming, realt ime act ions t aken videoconf erencing, et c.) � user services provided by lower layer prot ocols -3 -4 How do client s and servers Client-ser ver par adigm communicat e? Typical net work app has t wo applicat ion pieces: client and server t ransport API : applicat ion Q: how does a pr ocess net work dat a link pr ogr amming int er f ace “ident if y” t he ot her Client : physical request pr ocess wit h which it � init iat es cont act wit h server � def ines int er f ace (“speaks f irst ”) want s t o communicat e? bet ween applicat ion � t ypically request s service f rom � I P address of host and t r anspor t layer running ot her process server, � socket : I nt er net API reply � f or Web, client is implement ed � “port number ” - allows � t wo processes in browser; f or e- mail, in mail receiving host t o communicat e by sending applicat ion reader det ermine t o which t ransport dat a int o socket , net work local process t he Ser ver : dat a link physical reading dat a out of message should be � Running f ir st (always?) socket delivered � provides request ed service t o client e.g., Web server sends … more on t his lat er. request ed Web page, mail server delivers e- mail -5 -6 1

Socket programming Socket s Goal: lear n how t o build client / ser ver applicat ion t hat Socket : a door bet ween applicat ion process communicat e using socket s and end-end-t ransport prot ocol (UCP or Socket API TCP) socket � int roduced in BSD4.1 UNI X, a host - local , applicat ion- 1981 creat ed/ owned , � Socket s are explicit ly OS- cont rolled int erf ace cont r olled by creat ed, used, released by cont r olled by (a “door”) int o which process applicat ion applicat ions process applicat ion developer applicat ion process can developer socket � client / server paradigm socket bot h send and ker nel cont r olled by � t wo t ypes of t ransport cont r olled by ker nel receive messages t o/ f rom buf f er s, operat ing service via socket AP I : operat ing buf f er s, int ernet syst em anot her (remot e or var iables syst em var iables � unreliable dat agram local) applicat ion process � reliable, byt e st ream- host or host or orient ed server server -7 -8 Languages and P lat f orms Transport services and prot ocols � pr ovide logical communicat ion applicat ion � Socket API is available f or many languages t ransport bet ween app’ processes net work dat a link on many plat f orms: running on dif f erent host s net work physical l dat a link o g net work physical i � t ransport prot ocols run in c dat a link a l � C, J ava,Per l, Pyt hon,… e physical n end syst ems d net work - dat a link � * nix, Windows,… e � t ransport vs net work layer n physical net work d t r dat a link services: a n physical � Socket Programs writ t en in any language s p o r t net work � net work layer: dat a t ransf er dat a link and running on any plat f orm can physical bet ween end systems communicat e wit h each ot her! � t ransport layer: dat a applicat ion t ransport t ransf er bet ween processes net work � Client and server must agree on t he t ype dat a link � r elies on, enhances, net wor k physical of socket , t he server port number and t he layer services prot ocol -9 -10 Services provided by I nt ernet UDP t ransport prot ocols � UDP adds very lit t le TCP ser vice: UDP ser vice: 32 bit s f unct ionalit y (or � connect ion- orient ed: set up � unreliable dat a t ransf er over head) t o bar e I P sour ce por t # dest port # required bet ween client , bet ween sending and server � Adds mult iplexing/ lengt h checksum receiving process Lengt h, in � reliable t ransport bet ween demult iplexing byt es of UDP � does not provide: sending and receiving process segment , connect ion set up, � ot her UDP uses � f low cont rol: sender won’t including (why?): reliabilit y, f low cont rol, header overwhelm receiver congest ion cont rol, t iming, � DNS: small, ret ransmit Applicat ion � congest ion cont rol: t hr ot t le or bandwidt h guarant ee if necessary dat a sender when net work � of t en used f or st reaming (message) overloaded mult imedia apps � does not providing: t iming, Q: why bot her ? Why is • Loss t oler ant t here a UDP? minimum bandwidt h • rat e sensit ive guarant ees UDP segment f ormat -11 -12 2

P rocess-t o-P rocess Message Mult iplexing/ demult iplexing Delivery Mult iplexing: Demult iplexing: Goal : Deliver applicat ion dat a t o correct process (and more gat hering dat a f rom mult iple St ream of incoming dat a int o part icularly t o t he right socket ) app processes, enveloping one machine separat ed int o dat a wit h header (lat er used smaller st reams dest ined f or S egment - unit of dat a exchanged bet ween t ransport layer f or demult iplexing) individual processes ent it ies; t ransport prot ocol dat a unit (TP DU) 32 bit s r eceiver Demult iplexing based on I P P3 P4 sour ce por t # dest port # applicat ion- layer addr esses of sender and and M M dat a port numbers of bot h sender applicat ion ot her header f ields and r eceiver segment P1 P2 t ransport M � Can dist inguish t r af f ic header M net work coming t o same por t but applicat ion applicat ion par t of separ at e segment t r anspor t t ransport Ht M applicat ion conver sat ions (like net wor k Hn segment net work dat a mult iple client connect ions t o a web server) (message) TCP / UDP segment f ormat -13 -14 TCP adds f unct ionalit y Common Sense � Consider f axing a document wit h f laky machine � TCP adds lot s of f unct ionalit y over bar e I P and � Can’t t alk t o person on t he ot her side any ot her way over UDP � What would you do t o make sur e t hey got t he � St ill has mult iplexing/ demult iplexing t r ansmission? � Adds reliable, in- order delivery � Number t he pages – so receiver can put t hem in � Adds f low cont rol and congest ion cont rol order/ det ect duplicat es/ det ect losses � How can you guar ant ee t hat ot her side get s “A B C � Need f eedback f rom t he receiver!!! D E” when net wor k could: � Resend dat a t hat is missing or if don’t hear f rom receiver � Lose dat a “A B D E” � Duplicat e dat a “A B C C D E” � Put some inf o on cover sheet t hat let s per son ver if y f ax inf o (summar ize inf o like checksum) � Cor r upt dat a “A B X D E” � What if it is a r eally big document ? Receiver might � Reorder dat a “A C D E B” like t o be able t o t ell you send f ir st 10 pages t hen � Or all of t he above! 10 mor e… -15 -16 TCP Connect ion Management Three-Way Handshake Active participant Passive participant Recall: TCP Three way handshake: sender, receiver (client) (server) est ablish “connect ion” SYN, SequenceNum = x bef ore exchanging dat a St ep 1: client end syst em segment s sends TCP SYN cont rol segment t o server � init ialize TCP variables: SYN + ACK, SequenceNum = y, � specif ies init ial seq # � seq. # s Acknowledgment = x + 1 � buf f ers, f low cont rol St ep 2: server end syst em inf o (e.g. RcvWindow ) receives SYN, replies wit h � client : connect ion init iat or SYNACK cont rol segment ACK, Acknowledgment = y+ 1 Socket clientSocket = new � ACKs received SYN Socket("hostname","port � allocat es buf f ers number"); � ser ver : cont act ed by client � specif ies server - > receiver init ial seq. # Socket connectionSocket = Not e: SYNs t ake up a sequence number even t hough welcomeSocket.accept(); no dat a byt es St ep 3: client acknowledges servers init ial seq. # -17 -18 3