Other
Summary Telematics systems and applications
- Course
- Institution
Summary Telematics systems and applications
[Show more]
Seller
Follow
sjorsvdiepen
Reviews received
Content preview
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
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller sjorsvdiepen. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $5.88. You're not tied to anything after your purchase.
Can Stuvia be trusted?
4.6 stars on Google & Trustpilot (+1000 reviews)
67447 documents were sold in the last 30 days
Founded in 2010, the go-to place to buy study notes for 14 years now