1 of 8

Section 8

Protocol Design Decisions

2 of 8

Project 4: DDNS

  • We implemented a protocol

​

  • But you had lots of questions

​

  • So why did we do it that way?

3 of 8

Reliability

  • TCP
    • When do we use it?
    • What does it provide?
    • What doesn't it provide?
  • Idempotence
    • You can apply the same operation more than once
    • Why do we want this?
  • Statelessness
    • Each transaction is independent
    • Why do we want this?

4 of 8

Failures we don't fix?

  • Middle zone goes down
    • Child zone is unreachable
    • Impact is timing-dependent - depends on caches
  • Cache inconsistency
    • We don't mandate cache behavior
    • Are register/unregister push or pull operations?
  • How would we fix these?
    • State replication
    • Push updates to all other resolvers
    • Complexity, performance, usability tradeoffs

5 of 8

Assumptions about ordering

register()

​

unregister()

​

resolve()

6 of 8

How can you ensure ordering?

  • Problem: multiple entities
  • One solution: serialization
    • One component is in charge
    • Ex. a thread
    • Determines the order in which requests are served
  • Problem: performance hit
  • Solution: distributed systems

7 of 8

An Amazon-style shopping cart

8 of 8

Questions

  • Where is the definitive cart?
  • What is our model of what parties are involved?
  • What could go wrong?
    • You go down, war between customers, shared acc.
  • How do we increase reliability?
  • Can we fix the "click buy only once" problem?
  • Is RPC a feasible environment?
  • What level of consistency do we need?
  • Should we focus on throughput or response time?