Overig
Samenvatting Telematica systemen en toepassingen
- Instelling
- Universiteit Twente (UT)
Samenvatting Telematica systemen en toepassingen
[Meer zien]Voorbeeld 1 van de 2 pagina's
Voorbeeld 1 van de 2 pagina's
In winkelwagengesponsord bericht van onze partner
Voorbeeld van de inhoud
Telematica systemen en toepassingen (261000)Transmission rate=Bandwidth | Network edge: Client/server model: Client host requests, recieves service from always-on server (webbrowser/webserver), P2P: Minimal (or no) use of dedicated servers (Kazaa),
scalable
cnction oriented: TCP: handshaking, reliable, in-order bytestream data transfer, flow control, congestion control (HTTP, SMTP) | cnctionless: UDP: Unreliable data transfer, no flow/congestion control (streaming
media, DNS)
Network Core: Circuit switched: dedicated circuit per call (telephone), dividing link bandwidth: FDM/TDM | packet switched: data send thru net in discrete 'chunks' (internet), congestion (packets queue), store
and forward..
Datagram network: dest. addr determines next hop | virtual circuit: tag carried by packet determines next hop (routers maintain per-call state).
Delay: Nodal Delay= processing + queueing + transmission (=L/R) + propagation (=d/s).
Layering: Application: supporting network application(http/smtp), Transport: host-host data transfer(TCP/UDP), Network: routing of datagrams from src. to dest.(IP/routing prot.), Link: data transfer between
neighbouring elements.
Application layer:
Client process initiate communication, server process waits to be contacted | Process sends/receives messages to/from its socket | Identifier includes IP address and port number (HTTP:80, SMTP: 25, FTP:
21,c/20,d) | HTTP: stateless
Nonpersistent HTTP: HTTP/1.0, at most 1 object is send over a TCP-cnction | Persistent HTTP without pipelining: multiple objects can be send over a single TCP cnction, new requests only when previous
response has been received | Persistent HTTP with pipelining: HTTP/1.1, client sends requests as soon as it encounters a referenced object.
RTT time: time to send a small packet to travel from client to server and back.
Web caches (proxy servers):web access and HTTP requests via cache,if objects in cache,cache returns objects.
FTP:Seperate control/data cnctions,1data cnction per file; server maintains “state”: current directory and earlier authentication.
SMTP: TCP to reliable transfer e-mail messages from client to server; transfer: handshaking->transfer-> closure | Commands: ASCII, Responsds: status code+phrase; messages: 7-bits ASCII, cnctions are
persistent
HTTP<>SMTP: HTTP: pull, each object encapsulated in its own response msg | SMTP: push, multiple objects sent in multipart msg.
Mail access protocols: POP: authorization, download, stateless | IMAP: more features, manipulation of stored msgs on server, keeps user state across sessions | HTTP
DNS: Distributed database implemented in hierarchy of many name-servers; application-layer protocol: in hosts, routers, name-servers to communicate to resolve names. Tasks: host-name/IP-address
translation, host/mail-server aliasing, load distribution (set of IP-addresses for 1 canonical name). Resource Record format: (name, value, type, TTL); type=A: name=hostname, value IP-adres; type=NS:
name=domain, value=ip adres of authoritive name server, type=cname: name=alias for some canonical name, value=canonical name; type=MX: value=name of mailserver associated with “name”.
Hierarchy: Root->Top Level Domain->authoritative-> evtually Local Name server (acts as a proxy); Contacting: Recursive queries, iterated queries.
Caching: TLD servers cached in local name servers; entries time-out | DNS Records: Resource Record format: (name, value, type ttl).
P2P: All peers are both Web client and transient Web servers->scalable. Configurations: Centralized dir (file transfer decentralized, locating content centralized) or fully distributed (given peer will typically be
connected with <10 overlay neighbours).
Exploiting heterogeneity: each peer is either a group-leader or assigned to a group leader: leader tracks the content in all its children and each file has a hash and descriptor.
Transport services and protocols:
Provide logical communication between app. processes running on different hosts; running in end-systems | Protocols: TCP/UDP.
Demultiplexing at rcv host: delivering received segments to correct socket (with port # and IP) | Multiplexing at send host: gathering data from multiple sockets, enveloping data with header (later used for
demultiplexing). UDP socket identified by 2-tuple: dest IP-address, dest port # | TCP-socket identified bij 4-tuple: src/dest IP-address, src/dest port #.
UDP: no cnction estab/cnction state, each segment handled independently of others; UDP uses: DNS, SNMP.
UDP checksum: Sender: treat segment contents as sequence of 16 bit integers. Checksum: addition (1's complement sum) of segment contents (carryout added to the result), sender puts checksum value into
UDP checksum field. Receiver: Compute checksum of received segment, check if computed checksum equals checksum field value.
RDT: rdt_send, udt_send, rdt_rcv, deliver_data | Rdt2.0: error detection (checksum), receiver Acks/Naks | stop and wait: sender sends, then wait for receiver's Ack/Nack.
Rdt 2.1: send: handles garbled acks/nak's, seq# added, check if rcvd ack/nak is corrupted (2x zoveel states); rcv: check if rcvd pkt is duplicate, can't check if rcvd ack/nak corrupted.
Rdt 2.2: nak-free, ipv nak, rcvr acks last pkt rcvd ok, duplicate ack->same action as nack.
Rdt 3.0: handles errors and loss. Retransmit if no ack received in time-out | rcvr specify seq# of pkt in ack | performance (utilization): U(send.)=(L/R)/(RTT+L/R).
Pipelining: multiple “in flight” pkts | range of seq#'s increased and buffering at send/rcvr.
GBN: Window, N consecutive unack'ed pkts allowed | timer for each in-flight pkt | timeout: retransmit pkt n and all higher seq#'s. Ack only: always ack for correctly rcvd pkt with highest in-order seq# (may
generate duplicate acks and only remember “expectedseqnum”) | out-of-order pkt: discard (no rcvr buffering) pkt, re-ack highest-order seq#.
Selective-repeat: Rcvr individually acks all correctly rcvd pkts (can buffer) | sender only resends pkts for which ack not rcvd (sender has timer for each unack'ed pkt); Window: N consecutive seq#'s, limit for
seq#'s for sent, unack'ed pkts;
Sender: if next available seq# in window: send pkt | if timeout: resend pkt n-> restart timer | if ack(n) in [sendbase,sendbase+N]: mark pkt n as rcvd | if n smallest unack'ed pkt: advance window base to next
unack'ed seq#.
Rcvr: send ack(n) | if out-of-order: buffer | if in order: deliver and advance window to next not-yet rcvd pkt | if pkt n in [rcvbase-N, rcvbase-1]: ack(n), otherwise:ignore.
st
TCP: point-to-point, pipelined, send/rcv buffers, full duplex data (max. segm. Size) | seq#: bytestream # of 1 byte in segm data | ack: seq# of next byte expected from other side: cumulative ack.
Timeout value: set with RTT: EstimatedRTT = (1-a)*EstimatedRTT + a*SampleRTT, typical a: 0,125; safety margin: DevRTT = (1-B)*DevRTT + B*|SampleRTT-EstimatedRTT|, typical: B=0,25; TimeoutInterval =
EstimatedRTT + 4DevRTT.
TCP Rdt: uses single retransmission timer | retransmissions triggered by timeout and duplicate acks | cumulative acks.
Fast retransmit: detect lost segments via 3 duplicate acks by transmitting 3 times, resend segment before timer expires.
Flow control: speed matching service (send-rate to apps drain rate) | spaceroom in buffer rcvr | rcvr include value of rcv window in segm | sender limits unAcked data to rcv window rcvr.
TCP cnction management: handshake: 1: client send TCP SYN segm to server (specifies initial seq#, no data) 2: server replies with SYNACK (allocates buffers, specifies initial seq#) 3: client replies with Ack,
may contain data. Closing cnction: 1: Client sends TCP FIN to server 2: server Acks, closing cnction, sends FIN 3: Client replies with Ack, enters “timed wait” (will respond with Ack to rcvd FIN's) 4: server rcvs
Ack, cnction closed.
Congestion Control: costs: more work (retrans) for given 'goodput' | unneeded retransmissions | when pkt dropped: wasted upstream transmission capacity | Approaches: end-end control (end-system observes
loss/delay), network-assisted control (routers feedback).
Floris van den Brink – oktober 2004
Voordelen van het kopen van samenvattingen bij Stuvia op een rij:
Verzekerd van kwaliteit door reviews
Stuvia-klanten hebben meer dan 700.000 samenvattingen beoordeeld. Zo weet je zeker dat je de beste documenten koopt!
Snel en makkelijk kopen
Je betaalt supersnel en eenmalig met iDeal, creditcard of Stuvia-tegoed voor de samenvatting. Zonder lidmaatschap.
Focus op de essentie
Samenvattingen worden geschreven voor en door anderen. Daarom zijn de samenvattingen altijd betrouwbaar en actueel. Zo kom je snel tot de kern!
Veelgestelde vragen
Wat krijg ik als ik dit document koop?
Je krijgt een PDF, die direct beschikbaar is na je aankoop. Het gekochte document is altijd, overal en oneindig toegankelijk via je profiel.
Tevredenheidsgarantie: hoe werkt dat?
Onze tevredenheidsgarantie zorgt ervoor dat je altijd een studiedocument vindt dat goed bij je past. Je vult een formulier in en onze klantenservice regelt de rest.
Van wie koop ik deze samenvatting?
Stuvia is een marktplaats, je koop dit document dus niet van ons, maar van verkoper sjorsvdiepen. Stuvia faciliteert de betaling aan de verkoper.
Zit ik meteen vast aan een abonnement?
Nee, je koopt alleen deze samenvatting voor €5,48. Je zit daarna nergens aan vast.
Is Stuvia te vertrouwen?
4,6 sterren op Google & Trustpilot (+1000 reviews)
Afgelopen 30 dagen zijn er 70055 samenvattingen verkocht
Opgericht in 2010, al 14 jaar dé plek om samenvattingen te kopen