New User Special Price Expires in

Let's log you in.

Sign in with Facebook


Don't have a StudySoup account? Create one here!


Create a StudySoup account

Be part of our community, it's free to join!

Sign up with Facebook


Create your account
By creating an account you agree to StudySoup's terms and conditions and privacy policy

Already have a StudySoup account? Login here

Multicore Cncrt Programming

by: Lisette Hodkiewicz

Multicore Cncrt Programming CS 6030

Lisette Hodkiewicz
GPA 3.83

Ala Al-Fuqaha

Almost Ready


These notes were just uploaded, and will be ready to view shortly.

Purchase these notes here, or revisit this page.

Either way, we'll remind you when they're ready :)

Preview These Notes for FREE

Get a free preview of these Notes, just enter your email below.

Unlock Preview
Unlock Preview

Preview these materials now for free

Why put in your email? Get access to more of this material and other relevant free materials for your school

View Preview

About this Document

Ala Al-Fuqaha
Class Notes
25 ?




Popular in Course

Popular in ComputerScienence

This 60 page Class Notes was uploaded by Lisette Hodkiewicz on Wednesday September 30, 2015. The Class Notes belongs to CS 6030 at Western Michigan University taught by Ala Al-Fuqaha in Fall. Since its upload, it has received 36 views. For similar materials see /class/216872/cs-6030-western-michigan-university in ComputerScienence at Western Michigan University.

Similar to CS 6030 at WMU

Popular in ComputerScienence


Reviews for Multicore Cncrt Programming


Report this Material


What is Karma?


Karma is the currency of StudySoup.

You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!

Date Created: 09/30/15
Routing in Mobile Ad Hoc Networks MANETs E M Royer C K Toh A Review of Current Routing Protocols for Ad Hoc Mobile Wireless Networks IEEE Personal Communications vol 6 no 2 Apr 1999 Outline Introduction Characteristics of Ad Hoc Networks Applications Routing Reactive Routing Protocols Proactive Routing Protocols Introduction A Mobile Ad hoc Network MANET is an autonomous system of nodes MSs connected by wireless links A MANET does not necessarily need support from any existing network infrastructure like an Internet gateway or other fixed stations The network s wireless topology may dynamically change in an unpredictable manner since nodes are free to move Information is transmitted in a storeand forward manner using multi hop routing Introduction Cont d Each node is equipped with a wireless transmitter and a receiver with an appropriate antenna We assume that it is not possible to have all nodes within each other s radio range When the nodes are closeby ie within radio range there are no routing issues to be addressed At a given point in time wireless connectivity in the form of a random multihop graph exists between the nodes Symmetric link A Mobile Ad Hoc Network 1 x z mmetl lc Characteristics of Ad Hoc Networks Dynamic topologies Network topology may change dynamically as the nodes are free to move Bandwidthconstrained variable capacity links Realized throughput of wireless communication is less than the radio s maximum transmission rate Collision occurs frequently Energyconstrained operation Some nodes in the ad hoc network may rely on batteries or other exhaustible means for their energy Limited physical security More prone to physical security threats than fixed cable networks Applications Virtual navigation and Intelligent Transportation Systems Data from a remote database is transmitted periodically in small relevant blocks using links present in the path of the automobile This database may contain the graphical representation of streets buildings maps and the latest traffic information which may be used by the driver to decide on a route T elemedicine Conference assistance from a surgeon for an emergency 1ntervent10n T eleGeo processing Queries regarding location information of the users Crisismanagement Natural disasters where the entire communication infrastructure is in disarray Education via the Internet Internet Connectivity Battle eld Networks Routing in MANETS Goals Provide the maximum possible reliability use alternative routes if an intermediate node fails Choose a route with the least cost metric Give the nodes the best possible response time and throughput Route computation must be distributed Centralized routing in a dynamic network is usually very expensive Routing computation should not involve the maintenance of global state Every node must have quick access to routes on demand Each node must be only concerned about the routes to its destination Broadcasts should be avoided highly unreliable It is desirable to have a backup route when the primary route has become stale Routing Classi cation The existing routing protocols can be classified as Proactive when a packet needs to be forwarded the route is already known Reactive Determine a route only when there is data to send Routing protocols may also be categorized as Table Driven protocols Source Initiated on demand protocols Protocol Tradeoffs Proactive protocols Always maintain routes Little or no delay for route determination Consume bandwidth to keep routes uptodate Maintain routes which may never be used Reactive protocols Lower overhead since routes are determined on demand Signi cant delay in route determination Employ ooding global search Control traf c may be bursty Which approach achieves a better tradeoff depends on the traf c and mobility patterns Reactive Routing Protocols Dynamic Source Routing DSR When node S wants to send a packet to node D but does not know a route to D node S initiates a route discovery Source node S oods Route Request RREQ Each node appends own identi er when forwarding RREQ Route Discovery in DSR Represents a node that has received RREQ for D from S Route Discovery in DSR Broadcast transmission u Represents transmission of RREQ XY Represents list of identifiers appended to RREQ Route Discovery in DSR Node H receives packet RREQ from two neighbors potential for collision Route Discovery in DSR Node C receives RREQ from G and H but does not forward it again because node C has already forwarded RREQ once Route Discovery in DSR Nodes J and K both broadcast RREQ to node D Since nodes J and K are hidden from each other their transmissions may collide Route Discovery in DSR 3EFJJV Node D does not forward RREQ because node D is the intended target of the route discovery Route Discovery in DSR Destination D on receiving the first RREQ sends a Route Reply RREP RREP is sent on a route obtained by reversing the route appended to received RREQ RREP includes the route from S to D on which RREQ was received by node D Route Reply in DSR lt Represents RREP control message Dynamic Source Routing DSR Node S on receiving RREP caches the route included in the REF When node S sends a data packet to D the entire route is included in the packet header hence the name source routing Intermediate nodes use the source route included in a packet to determine to whom a packet should be forwarded Data Delivery in DSR DATA SEFJD Packet header size grows with route length DSR Optimization Route Caching Each node caches a new route it learns by any means When node S finds roule SEFJD to node D node S also learns route SEF to node F When node K receives Route Request SCG destined for node D node K learns route KGCS to node S When node F forwards Route Reply RREP SEFJD node F learns route FJD to node D When node E forwards Dala SEFJD it learns route EFJD to node D A node may also learn a route when it overhears Data Dynamic Source Routing Advantages Routes maintained only between nodes who need to communicate reduces overhead of route maintenance Route caching can further reduce route discovery overhead A single route discovery may yield many routes to the destination due to intermediate nodes replying from local caches Dynamic Source Routing Disadvantages Packet header size grows with route length due to source routing Flood of route requests may potentially reach all nodes in the network Potential collisions between route requests propagated by neighboring nodes insertion of random delays before forwarding RREQ Increased contention if too many route replies come back due to nodes replying using their local cache Route Reply Storm problem Ad Hoc OnDemand Distance Vector Routing AODV DSR includes source routes in packet headers Resulting large headers can sometimes degrade performance particularly when data contents of a packet are small AODV attempts to improve on DSR by maintaining routing tables at the nodes so that data packets do not have to contain routes AODV retains the desirable feature of DSR that routes are maintained only between nodes which need to communicate AODV Route Requests RREQ are forwarded in a manner similar to DSR When a node rebroadcasts a Route Request it sets up a reverse path pointing towards the source AODV assumes symmetric bidirectional links When the intended destination receives a Route Request it replies by sending a Route Reply RREP Route Reply travels along the reverse path setup when Route Request is forwarded Route Requests in AODV Represents a node that has received RREQ for D from S Route Requests in AODV Broadcast transmission gt Represents transmission of RREQ Route Requests in AODV 4 Represents links on Reverse Path Reverse Path Setup in AODV Node C receives RREQ from G and H but does not forward it again because node C has already forwarded RREQ once Reverse Path Setup in AODV Reverse Path Setup in AODV Node D does not forward RREQ because node D is the intended target of the RREQ Forward Path Setup in AODV Forward links are setup when RREP travels along the reverse path Represents a link on the forward path Route Request and Route Reply Route Request RREQ includes the last known sequence number for the destination An intermediate node may also send a Route Reply RREP provided that it knows a more recent path than the one previously known to sender Intermediate nodes that forward the RREP also record the next hop to destination A routing table entry maintaining a reverse path is purged after a timeout interval A routing table entry maintaining a forward path is purged if not used for a activeirouteitimeout interval Link Failure A neighbor of node X is considered active for a routing table entry if the neighbor sent a packet within ac veiroutei meout interval which was forwarded using that entry Neighboring nodes periodically exchange hello message When the next hop link in a routing table entry breaks all active neighbors are informed Link failures are propagated by means of Route Error RERR messages which also update destination sequence numbers Route Error When node X is unable to forward packet P from node S to node D on link XY it generates a RERR message Node X increments the destination sequence number for D cached at node X The incremented sequence numberN is included in the RERR When node S receives the RERR it initiates a new route discovery for D using destination sequence number at least as large as N When node D receives the route request with destination sequence number N node D will set its sequence number to N unless it is already larger than N AODV Summary Routes need not be included in packet headers Nodes maintain routing tables containing entries only for routes that are in active use At most one nexthop per destination maintained at each node DSR may maintain several routes for a single destination Sequence numbers are used to avoid oldbroken routes Sequence numbers prevent formation of routing loops Unused routes expire even if topology does not change Other Protocols I AssociativityBasedRouting ABR links t have been stable for some minimum duration are I Nodes increment the associativity ticks of neighbors by using periodic beacons Signal Stability Based Adaptive Routing SSA I A node X rebro casts a Route Request received from Y only if the XY link has a strong signal vfabilif I Signal stability is evaluated as a moving average of the signal strength of packets received on the link in recent past Clusterhead Gateway Switch Routing CGSR I All nodes within a cluste unicate with a clusterhead I Routing uses a hierarchical clusterheadtogateway approach Node Gateway 0 Cluster head Proactive Routing Protocols DestinationSequenced DistanceVector DSDV Each node maintains a routing table which stores next hop cost metric towards each destination a sequence number that is created by the destination itself Each node periodically forwards routing table to neighbors Each node increments and appends its sequence number when sending its local routing table Each route is tagged with a sequence number routes with greater sequence numbers are preferred Each node advertises a monotonically increasing even sequence number for itself When a node decides that a route is broken it increments the sequence number of the route and advertises it with infinite metric Destination advertises new sequence number DestinationSequenced DistanceVector DSDV I When X receives information from Y about a route to Z I Let destination sequence number for Z at X be SX SY is sent from Y If SX gt SY then X ignores the routing information received from Y If SX SY and cost of going through Y is smaller than the route known to X then X sets Y as the next hop to Z If SX lt SY then X sets Y as the next hop to Z and SX is updated to equal SY An Example of Route Update I At the start each node gets rout updates only from its n 1 neighbour I For n4 the distances to the other nodes are 2 n51 n31 H2 00 n1 00 n3 I All nodes broadcast with a sequence number 1 n n5 Copyright 2003 Dr Dharma P Agrawal and Dr QingAn Zeng All rights reserved g An Example of Route Update n1 n2 n3 n n5 I A er this nodes forward messages that they have received earlier I The message that n2 sent to H3 is now forwarded by n3 I For n4 the distances are now n5l n3l n22 ml 00 All messages have sequence number 1 Copyright 2003 Dr Dharma P Agrawal and Dr QingAn Zeng All rights reserved I An Example of Route Update n1 n2 n3 1 n5 I Finally after second round of forwarding n4 gets the following distances n5l n3l n22 nl3 Copyright 2003 Dr Dharma P Agrawal and Dr QingAn Zeng All rights reserved g An Example of Route Update n1 n5 n2 n3 n4 Suppose n5 has moved to its new location Also n5 receives a new message from n1 with a sequence number 2 This message is forwarded by n5 to n4 Two distances to n1 in n4 Copyright 2003 Dr Dharma P Agrawal and Dr QingAn Zeng All rights reserved I An Example of n1 n5 n2 n3 n4 Route Update Distance 3 with seqence number 1 and Distance 2 with sequence number 2 Since the latter message has a more recent sequence number n4 will update the distance to n1 as 2 Copyright 2003 Dr Dharma P Agrawal and Dr QingAn Zeng All rights reserved Optimized Link State Routing OLSR Nodes C and E are multipoint relays of node A Multipoint relays of A are its neighbors such that each twohop neighbor of A is a onehop neighbor of one multipoint relay of A Nodes exchange neighbor lists to know their 2hop neighbors and choose the multipoint relays O Node that has broadcast state information from A Optimized Link State Routing OLSR Nodes C and E forward information received from A Nodes E and K are multipoint relays for node H Node K forwards information received from H Node that has broadcast state information from A OLSR Only the multipaint relays nodes MPRs need to forward LS updates OLSR is particularly suited for dense networks In sparse networks every neighbor becomes a multipoint relay then OLSR reduces to pure LS protocol Wireless Sensor Networks Copyright 2003 Dr Dharma P Agrawal and Dr QingAn Zeng All rights reserved Wireless Sensor Networks I Wireless sensor networks are a collection of hundreds or thousands of tiny disposable and low power sensor nodes communicating together to achieve an assigned task A sensor node is a device that converts a sensed attribute into a data form that is comprehensible by the user Each node includes a sensing module a communication module memory and a small battery They are data centric networks ie the interest is in what is the data rather than where is the data In wireless sensors failure of one sensor does not affect the network operation as there are other nodes collecting similar data in the same area Copyright 2003 Dr DharmaP Agrawal and Dr QingAn Zeng All rights reserved WSN Architecture Internet and satellite Task manager node Usm Sensor held Sensor nudes I Figure 1 S39NIsu nmlm wmr mflm wnw lielr lLocu nn Finding Syste Mobilizer A Searing Unit Processing Unit l PrueeAJur Sumo ADC Transceiver I smmge A Power Unit Power Generator Fig l The cornpunems 0er sensor node Copyright 2003 Dr Dharma P Agrawal and Dr QingAn Zeng All rights reserved Wireless Sensor Networks Queries Query handling is another additional feature Users using hand held devices should be able to request data from the network User queries are of three types Historical queries Used for analysis ofhistorical data stored at the S e g What was the temperature 2 hours back in the northwest quadrant One time query Gives a snapshot ofthe network eg What is the current temperature in the northwest quadrant Persistent query Used to monitor the network over a time interval with respect to some parameters e g Report the temperature for the next 2 hours Copyright 2003 Dr Dharma P Agrawal and Dr QingAn Zeng All rights reserved Classi cation of Sensor Networks l Proactive Networks The nodes in the network periodically switch on their sensors and transmitters sense the environment and transmit the data of interest I Reactive Networks In this scheme the nodes react immediately to sudden and drastic changes in the value of the sensed attribute Copyright 2003 Dr Dharma P Agrawal and Dr QingAn Zeng All rights reserved Fundamentals of MAC Protocol for Wireless Sensor Networks I Static Channel Allocation I In this category of protocols if there are N nodes the bandwidth is divided into N equal portions either in frequency FDMA in time TDMA in code CDMA in space SDMA Space Division Multiple Access or OFDM Orthogonal Frequency Division Multiplexing I Dynamic Channel Allocation I In this category of protocols there is no xed assignment of bandwidth Copyright 2003 Dr Dharma P Agrawal and Dr QingAn Zeng All rights reserved Routing Issues in Sensor Networks I In traditional wired networks each node is identi ed by a unique address which is used for routing Sensor networks being data centric do not in general require routing between specific nodes Adjacent nodes may have similar data So it is desirable to aggregate this data and send it The requirements of the network change with application hence it is application specific Copyright 2003 Dr Dharma P Agrawal and Dr QingAn Zeng All rights reserved Flat Routing I Each node plays the same role amp sensor nodes collaborate together to perform the sensing task I SPIN I Directed Diffusion I Use data centric routing the sink sends request and waits for data from sensor nodes Copyright 2003 Dr Dharma P Agrawal and Dr QingAn Zeng All rights reserved Routing in Sensor Networks Flat Routing I Directed Diffusion I The query is ooded throughout the network I Events start from some specific points and move outwards to reach the requesting node I This type of data collection does not fully exploit the feature of sensor networks that adjacent nodes have similar data Sensor Protocols for Information via Negotiation SPIN I Disseminates the information at each node to every node in the network Copyright 2003 Dr Dharma P Agrawal and Dr QingAn Zeng All rights reserved Sensor Protocols for information via Negotiation SPIN l Designed to address the deficiencies of classic ooding by o o O If O 0 0 O O o o 0 Step I Step 2 Slop 3 O 0 Step 6 0 Step 4 Step 5 ADV REQ DATA 0 o oo o oo Hg 6 Thc SPIN protocol 35 Copyright 2003 Dr Dharma P Agrawal and Dr QingAn Zeng All rights reserved Pirqt thP Qink rPnantq hm mg V O O Som c39e O quot Os39k 0 7quot Smk x a quot quot gtO b T Q Suture A K Sink 3 9 a propagate 21m Copyright 2003 Dr Dharma P Agrawal and Dr QingAn Zeng All rights reserved Hierarchical Routing in Sensor Networks I Clusterbased routing I Higher energy nodes can be used to process and send info while low energy nodes can be used to perform sensing I Lower energy consumption within a cluster by data aggregation and fusion to decrease the number of transmitted messages Copyright 2003 Dr Dharma P Agrawal and Dr QingAn Zeng All rights reserved Common Object Request Broker Architecture CORBA ICORBA I CORBA is similar in high level concepts to RMI 9RM is basically a simplified form of CORBA I Adds crossplatform multiple language interfaces more bells and whistles I Widely used standard I 1 CORBA I At the top level the architecture is similar to RMI ORB and IIOP The Internet InterORB Protocol IIOP is a protocol by which ORBs communicate Similar to JRMP in RMI Helln Client Helle Seruer Hello Semant l sayHeTlo I Elbjec39t Reference sayHenna Hello world I CORBA The Object Request Broker ORB is the bus that connects objects across the network It s a virtual bus some network software that runs on each machine It locates the object on the network communicates the message and waits for results Not all ORBs are alike there are some standardization moves around but it s not generally true that a client using one ORB can talk to a remote object using a different ORB Major vendors Java 2 ORB VisiBroker WebSphere ORB lona Orbix CORBA Services I CORBA has a standard the HOP that supposedly allows you to communicate with CORBA objects running on another vendor s ORB over TCPIP I The CORBA infrastructure also provides services for naming transactions object creation etc These are CORBA services implemented in CORBA 1 Stub amp Skeleton Creation I In RMI we had an RMI compiler run on the class file we wanted to be remote It s different under CORBA I The interface is written in Interface Definition Language IDL IDL is languageneutral by being a different language than anything else though highly reminiscent of C multiple inheritance similar syntax etc I IDL has a set of primitive data types similar to most languages integer float string byte etc 1 CORBA Development Process 1 Write an IDL file which describes the interface to the distributed object 2 Run idlj on the IDL file This generates Java code that implements the stub and the skeleton Run nameserver 4 Implement the servant implement the IDL interface Implement the server register the servant with the naming service and wait for requests 6 Implement the client 7 Run the server 8 Run the client I 1 Interface Definition Language IDL I Compile the IDL code with idlj This createsjava source code files in the Tracker package Note the use of the IDL primitive type string I idlj fcient fserver odmpBase Trackeridl module Tracker interface Time string getTime 5 39 Interface Definition Language IDL Contd I A pure description language enables developers to describe an interface they wish to use remotely in a languageindependent fashion I Language specific compiler required for each participating language eg idlj for Java creates les required by each language for CORBA related tasks I Idlj IDL to Java Compile output I Idlj generates some horrorstory java code in the Tracker directory TimeStub the stub forthe client Time the interface for the distributed object TimeHeIper Kitchen sink functionality TimeHoIder Serialization amp communications out amp inout parameters 39 TimeOperations initial server implementation TimelmplBase base class for servant Start the nameserver I CORBA uses a technique similar to that of the RMI registry Servers register with the name server and clients ask the name server where to find the server I orbd ORBnitiaIPort ltmyPortgt Example orbd ORBlnitialPort 900 I This is a replacement for the older tnsnameserver I Note that myPort must match up with the properties used to find the name server in the client and server Clientside Code I Very similar to RMI l Get reference to remote object rl Cast it to what you want l lCall methods on the object via the local proxy object On the other hand there are more annoyances due to CORBAs multilanguage background 39 I Clientjava package ex1 import Trackerf II The package containing our stubs import orgomgCosNaming II Client will use the naming service import orgomgCORBA II All CORBA applications need these classes public class Client public static void main String args try II Create and initialize the ORB ORB orb ORBinitargs null II Get the root naming context orgomgCORBAObject objRef orbresolveinitialreferences quotNameServicequot NamingContext ncRef NamingContextHelpernarrow objRef II Resolve the object reference in naming NameComponent nc new NameComponent quotTimeServerquot quotquot NameComponent path nc Time timeRef TimeHelpernarrow ncRefresolve path II Call the time server object and print results String time quotTime on the Server is quot timeRefgetTime Systemoutprintln time catch Exception e eprintStackTrace 0 Serverside Code I On the serverside there is the Server code and the Servant code The servant code is the object implementation The server code holds one or more servants The servant Code package ex1 The package containing our stubs import Tracker Server Will use the naming service import orgomgCosNaming The package containing special exceptions thrown by the name service import orgomgCosNamingNamingContextPackage All CORBA applications need these classes import orgomgCORBA import javautil import javatext class TimeServer extends TimelmplBase public String getTime SimpleDateFormat formatter new SimpleDateFormat quotMMMMM dd yyyyy GGG hhmmssSSS aaaquot Date date new Date 0 return formatterformat date The Server Code I The server code does the following l lCreates a new Servant object LlRegisters the Servant with the naming service lil Listens for incoming requests Makes sure we don t exit The Server Code The package containing our stubs import Trackerf Server will use the naming service import orgomgCosNaming The package containing special exceptions thrown by the name service import orgomgCosNamingNamingContextPackage All CORBA applications need these classes import orgomgCORBA public class Server public static void main String args tryl Create and initialize the ORB ORB orb ORBinit args null Create the servant and register it with the ORB TimeServer timeRef new TimeServer orbconnect timeRef Get the root naming context orgomgCORBAObject objRef orbresolveinitialreferences quotNameServicequot 39 39 uw objRef e Bind the object reference in namin NameComponent no new NameComponent 39TimeServerquot NameComponent path no ncRefrebind path timeRef Wait forever for current thread to die ThreadcurrentThread join 0 catch Exception e eprintStackTrace 0 LT Overview of Cemeilation Process iTimeStub iTimeImplBase Time server Tlme chth quot application appllcatlon Client byte code RMI In One Slide I U Client needs Service Interface lmpleme nts Remote Written in Java erVIce 39 Extends UnicastRemoteObject Implements Service Interface rmic Generated Stub Generated Skeleton quotquotquotquot quot Sewer needs Client Lookup Service by name from rmiregistry Use remote reference to access service Server Create Service Instance Register Service with rmiregistry lookup bind CORBA In One Slide Service Interface written in IDL Generated Stub Generated Skeleton l r Helper Class CORBA Service Client Extends Skeleton Service needs needs Client Server Create ORB Create ORB Lookup Service by name from naming service 39Create SeerCe Instance I Use remote reference to access service 39ReQ39Ster Seerce With naming seerce orbd bind lookup OR tnameserv Reference I CORBA The MOVE Institute Naval Postgraduate School Network Model Why a Layered Model Reduces eemplexky Session 0 Standardizes interfaces Faclhtates modular engineering Ensures interoperable echnolngy Newark o Accelerates evo unon Swmpli es teaching and learmng Data Link All People Seem To Need Data Processing Layers with Functions Session Network Data Link Transmission Wires connectors voiiagesi data raies 7 pplicahun a n I ll Each router provides its services to support upperlayer functions I ii Headers Encapsulation DeEncapsulation Ne N rk I Netw rk HH DATA OSI Model and TCPIP Model TCPIIP Model OSI Model lilm rimwfa l ysmm TCPIP Protocol Suite Network Infrastructure L l LAN Devices 539 gRepeater I Copies bits from one network to another I Does not look at any bits I Allows the extension of a network beyond physical length limitations Lt 1W BridgeSwitch I Copies frames from one network to another I Can operate selectively does not copy all frames must look at datalink headers I Extends the network beyond physical length limitations mm 39 Router I Copies packets from one network to another I Makes decisions about what route a packet should take looks at network headers 1 Ethernet LAN Segmentation OI oo 39if 39g a a a 39 iii lull I an ill E g Q Q 119 imm in igiombs mile 0 I911 rnnln Switches break collision domains Routers break collision domains as well as broadcast domains 1 7 Ethernet I Multiaccess shared medium I Every Ethernet interface has a unique 48 bit address aka hardware address IExampIe co3344172117 I The broadcast address is all 1 s I Addresses are assigned to vendors by a central authority I CSMACD Carrier Sense Multiple Access with Collision Detection I Carrier Sense can tell when another host is transmitting I Multiple Access many hosts share one wire I Collision Detection can tell when another host transmits at the same time y 1 An Ethernet Frame Type DATA I CRC I 8 bytes 6 6 2 461500 4 Source Address Destination Address I Preamble I The preamble is a sequence of alternating 1s and Os used for synchronization I CRC is Cyclic Redundency Check WAN Devices E mm zm 1 ltWAN Technologies Include I Analog modems I Integrated Services Digital Network ISDN I Digital Subscriber Line DSL I Frame Relay I Asynchronous Transfer Mode ATM I 39IE39 US and E Europe carn39er series T1 E1 T3 I Synchronous Optical Network SONET I Cellular Networ I Satellites UUNET s Global Internet Backbone Introduction to IP Addressing DHCP ARP Anatomy of an IP Packet Version IP header length HLEN Typeofservice Total en t Identification Flags Fragment offset 39 ive Timeto Header checksum Source ad ress Destination address Options Padding Data U 1 IP Address as a 32 Bit Binary Number I11ouooool ooooowaiioion1ooo1Di Ouou1011i 7554321 22222222 Octet 8 bits 2 239 U 22 392 2 222322222 Octet i8 bits Octet 8 bits Octet 8 mg 391 Private Addresses Dynamic Host Configuration Protocol l Allows a host to obtain an IP address using a defined range of IP addresses on a DHCP server I As hosts come online contact the DHCP server and request an address quotI a DHCP at a Glance I Client Actions IT Request lease for an address for a period of time LEASE TIME Cl Re new address lease prior to LEASE TIME expiration or allow DHCP server to access the network Remark clients can bypass the Delevmmes Cunllguvellun the lease to EXPRE D ST 11 Release lease once no longer needed IT Reject offered lease if it is already K l Address Resolution Protocol ARP Physical Addresses IP Addresses Desllnalmn 1971522126 n i 9 i ARP enables a computer to find the MAC address ofthe computer that is associated with an IP address 11 ARP Operation Within a Subnet Destination 1911522126 All devices on the network receive the packet and pass to network layer only one device responds with an ARP reply 39 Default Gateway A default gateway is the IP address of the interface on the router that connects to the network segment on which the source host is located Network Address Translation


Buy Material

Are you sure you want to buy this material for

25 Karma

Buy Material

BOOM! Enjoy Your Free Notes!

We've added these Notes to your profile, click here to view them now.


You're already Subscribed!

Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'

Why people love StudySoup

Steve Martinelli UC Los Angeles

"There's no way I would have passed my Organic Chemistry class this semester without the notes and study guides I got from StudySoup."

Allison Fischer University of Alabama

"I signed up to be an Elite Notetaker with 2 of my sorority sisters this semester. We just posted our notes weekly and were each making over $600 per month. I LOVE StudySoup!"

Bentley McCaw University of Florida

"I was shooting for a perfect 4.0 GPA this semester. Having StudySoup as a study aid was critical to helping me achieve my goal...and I nailed it!"

Parker Thompson 500 Startups

"It's a great way for students to improve their educational experience and it seemed like a product that everybody wants, so all the people participating are winning."

Become an Elite Notetaker and start selling your notes online!

Refund Policy


All subscriptions to StudySoup are paid in full at the time of subscribing. To change your credit card information or to cancel your subscription, go to "Edit Settings". All credit card information will be available there. If you should decide to cancel your subscription, it will continue to be valid until the next payment period, as all payments for the current period were made in advance. For special circumstances, please email


StudySoup has more than 1 million course-specific study resources to help students study smarter. If you’re having trouble finding what you’re looking for, our customer support team can help you find what you need! Feel free to contact them here:

Recurring Subscriptions: If you have canceled your recurring subscription on the day of renewal and have not downloaded any documents, you may request a refund by submitting an email to

Satisfaction Guarantee: If you’re not satisfied with your subscription, you can contact us for further help. Contact must be made within 3 business days of your subscription purchase and your refund request will be subject for review.

Please Note: Refunds can never be provided more than 30 days after the initial purchase date regardless of your activity on the site.