Beruflich Dokumente
Kultur Dokumente
Fall 2005
ROAD MAP: OVERVIEW
Build systems:
1. with a single system image
2. with higher performance
3. with higher reliability
4. for less money than uniprocessor systems
BROADCAST MEDIUM
BLOCKING
send send
NO
COMPUTATION
ACK
sender receiver
send
NON-BLOCKING
ACK (?)
REMOTE PROCEDURE CALL
Client calls the server using a call server (in parameters;
out parameters). The call can appear anywhere that a
normal procedure call can.
call
return
RENDEZVOUS FACILITY
– One process sends a message to another process and blocks at
least until that process accepts the message.
– The receiving process blocks when it is waiting to accept a
request.
Thus, the name: Only when both processes are ready for the data
transfer, do they proceed.
We will see examples of rendezvous interactions in CSP and Ada.
sender receiver
send
accept
accepted
Beyond send-receive: Conversations
Needed when a continuous connection is
more efficient and/or only some data at a
time.
Bob and Alice: Bob initiates, Alice responds,
then Bob, then Alice, …
But what if Bob wants Alice to send messages
as they arrive without Bob’s doing more than
an ack?
Sendonly or receiveonly mode.
Others?
SEPARATION OF CONCERNS
client…client
client
Service broker
server
server…server
ALTERNATIVE: NAME SERVER
A service is a piece of work to do. Will be done by a
server. Name Server knows where services are done
Example: Client requests address of server from the
Name Server and then communicates directly with that
server..
Difference: Client-server communication is direct, so may
be more efficient.
client…client
client
Service broker
server
Client … client
HOW TO ASK FOR IT:
OBJECT-BASED
• Encapsulation of data behind functional
interface.
• Inheritance is optional but interface is the
contract.
• So need a technique for both synchronous
and asynchronous procedure calls.
REFERENCE EXAMPLE:
CORBA OBJECT REQUEST
BROKER
• Send operation to ORB with its
parameters.
• ORB routes operation to proper site for
execution.
• Arranges for response to be sent to you
directly or indirectly.
• Operations can be “events” so can allow
interrupts from servers to clients.
SUCCESSORS TO CORBA
Microsoft Products
• COM: allow objects to call one another in
a centralized setting: classes + objects of
those classes. Can create objects and
then invoke them.
• DCOM: COM + Object Request Broker.
• ActiveX: DCOM for the Web.
SUCCESSORS TO CORBA
Java RMI
• Remote Method invocation (RMI): Define
a service interface in Java.
• Register the server in RMI repository, i.e.,
an object request broker.
• Client may access Server through
repository.
• Notion of distributed garbage collection
SUCCESSORS TO CORBA
Enterprise Java Beans
• Beans are again objects but can be
customized at runtime.
• Support distributed transaction notion
(later) as well as backups.
• So transaction notion for persistent
storage is another concern it is nice to
separate.
REDUCING BUREAUCRACY:
automatic registration
• SUN also developed an abstraction
known as JINI.
• New device finds a lookup service (like an
ORB), uploads its interface, and then
everyone can access.
• No need to register.
• Requires a trusted environment.
COOPERATING DISTRIBUTED SYSTEMS:
LINDA
• Linda supports a shared data structure called a tuple
space.
• Linda tuples, like database system records, consists of
strings and integers. We will see that in the matrix
example below.
TUPLE
SPACE
PROCESSES
LINDA OPERATIONS
The operations are out (add a tuple to the space); in
(read and remove a tuple from the space); and
read (read but don’t remove a tuple from the tuple
space).
A pattern-matching mechanism is used so that
tuples can be extracted selectively by specifying
values or data types of some fields.
out
BROADCAST IMPLEMENTATION 2
Implement out by writing locally.
Implement in and read by a global query.
(This may have to be repeated if the data
is not present.)
Summary: better for out. Worse for read.
Same for in.
in, read
COMMUNICATION REVIEW
Basic distributed communication when no
shared memory: send/receive.
Location transparency: broker or name server
or tuple space.
Synchrony and asynchrony are both useful
(e.g. real-time vs. informational sensors).
Other mechanisms are possible
COMMUNICATION BY SHARED
MEMORY: beyond locks
Framework: Herlihy, Maurice. “Impossibility and Universality Results
for
Wait-Free Synchronization,” ACM SIGACT-SIGOPS Symposium
on Principles of Distributed Computed (PODC), 1988.
In a system that uses mutual exclusion, it is possible that one
process may stop while holding a critical resources and
hang the entire system.
It is of interest to find “wait-free” primitives, in which no
process ever waits for another one.
The primitive operations include test-and-set, fetch-and-add,
and fetch-and-cons.
Herlihy shows that certain operations are strictly more
powerfully wait-free than others.
CAN MAKE ANYTHING WAIT-FREE
(at a time price)
Don’t maintain the data structure at all. Instead, just keep
a history of the operations.
enq(x)
put enq(x) on end of history list (fetch-and-cons)
end enq(x)
deq
put deq on end of history list (fetch-and-cons)
“replay the array” and figure out what to return
end deq
Not extremely practical: the deq takes
O(number of deq’s + number of enq’s) time.
Suggestion is to have certain operations reconstruct the
state in an efficient manner.
GENERAL METHOD: COMPARE-AND-SWAP
Compare-and-swap takes two values: v and v’. If the
register’s current value is v, it is replaced by v’,
otherwise it is left unchanged. The register’s old
value is returned.
temp := compare-and-swap (register, 0, i)
if register = 0 then register := i
else register is unchanged
Use this primitive to perform atomic updates to a
data structure.
In the following figure, what should the compare-
and-swap do?
PERSISTENT DATA STRUCTURES AND WAIT-
current
FREEDOM
current
One node added, one node removed. To establish change, change the current pointer.
Old tree would still be available.
Important point: If process doing change should abort, then no other process is affected.
LAMPORT Times, Clocks paper
• What is the proper notion of time for Distributed
Systems?
• Time Is a Partial Order
• The Arrow Relation
• Logical Clocks
• Ordering All Events using a tie-breaking Clock
• Achieving Mutual Exclusion Using This Clock
• Correctness
• Criticisms
• Need for Physical Clocks
• Conditions for Physical Clocks
• Assumptions About Clocks and Messages
• How Do We Achieve Physical Clock Goal?
ROAD MAP: TIME ACCORDING TO
LAMPORT
Languages &
Constructs for How to model time
Synchronization in distributed systems
TIME
Assuming there are no failures, the most
important difference between distributed
systems and centralized ones is that
distributed systems have no natural notion of
global time.
– Lamport was the first who built a theory
around accepting this fact.
– That theory has proven to be surprisingly
useful, since the partial order that Lamport
proposed is enough for many applications.
WHAT LAMPORT DOES
1. Paper (reference on next slide) describes a
message-based criterion for obtaining a time
partial order.
2. It converts this time partial order to a total order.
3. It uses the total order to solve the mutual
exclusion problem.
4. It describes a stronger notion of physical time
and gives an algorithm that sometimes achieves
it (depending on quality of local clocks and
message delivery).
NOTIONS OF TIME IN DISTRIBUTED SYSTEMS
Lamport, L. “Times, Clocks, and the Ordering of
Events in a Distributed System,”
Communications of the ACM, vol. 21, no. 7 (July
1978).
– Distributed system consists of a collection of distinct
processes, which are spatially separated. (Each process
has a unique identifier.)
– Communicate by exchanging messages.
– Messages arrive in the order they are sent. (Could be
achieved by hand-shaking protocol.)
– Consequence: Time is partial order in distributed
systems. Some events may not be ordered.
THE ARROW (partial order) RELATION
We say A happens before B or A B, if:
1. A and B are in the same process and A
happens before B in that process> (Assume
processes are sequential.)
8 14
13
18 19
None needed
Ack Pi
executes
RELEASE
RELEASE
USING THE RESOURCE
X Y
starts A
calls y
receives call
from x
starts B
Would like starts A starts B
But this may not be true with
as so far defined.
CONDITIONS FOR PHYSICAL CLOCKS
• Suppose u is the smallest time through internal or
external means that one process can be informed
of an event occurring at another process. That is, u
is the smallest transmission time.
(Distance/speed of light?)
• Suppose we have a global time t (all processes are
in same frame of reference) that is unknown to any
process.
Goal for physical clocks: Ci(t + u) > Cj(t) for any i, j.
This ensures that if A happens before B, then the
clock time for B will be after the clock time for A.
ASSUMPTIONS ABOUT CLOCKS AND
MESSAGES
1. Clock drift. In one unit of global time, Ci
will advance between 1-k and 1+k time
units. (k << 1)
2. A message can be sent in some minimum
time v with a possible additional delay of
at most e.
HOW DO WE ACHIEVE PHYSICAL
CLOCK GOAL?
• Can’t always do so, e.g., can’t synchronize
quartz watches using the U.S. post office.
• Basic algorithm: Periodically (to be
determined), each process sends out
timestamped messages.
• Upon receiving a message from Pi
timestamped Ti, process Pj sets its own
timestamp to max(Ti + v, Tj).
WHAT ALGORITHM ACCOMPLISHES
Simplifying to the essence of the idea, suppose
there are two processes i and j and i sends a
message that arrives at global time t.
After possibly resetting its timestamp, process j
ensures that
Cj(t) ≥ Ci(t) + v – (e+v)x(1+k)
That is, since i sent its message at local time Ti, i’s
clock may have advanced (e+v)x(1+k) time units
to Ti+(e+v)x(1+k) time. At the least Cj(t) ≥ Ti+v.
How good can synchronization be, given e, v, k?
ROAD MAP: SOME FUNDAMENTAL
PROTOCOLS
Each node except the root has one parent, and every node is
in the tree. A leaf is a node that only received ACKs from
neighbors to which it sent requests.
TERMINATING THE SPANNING TREE
4 4
4
3
1
DISTRIBUTED SNAPSHOTS
Intuitively, a snapshot is a freezing of a
distributed computation at the “same time.”
Given a snapshot, it is easy to detect stable
conditions such as deadlock.
(A deadlock condition doesn’t go away. If a
deadlock held in the past and nothing has
been done about it, then it still holds. That
makes it stable.)
FORMAL NOTION OF SNAPSHOT
Assume that each processor has a local clock, which is
incremented after the receipt of and processing of each
incoming message, e.g., a Lamport clock. (Processing may
include transmitting other messages.)
A collection of local times {tk|kεN}, where N denotes the set of
nodes, constitutes a snapshot, if each message received
by node j from node i prior to tj has been sent by i prior to ti.
A message sent by i before ti but not received by j before tj is
said to be in transit.
The correctness criterion is that no message be received
before the snapshot, which was sent after the snapshot.
(Such a thing could never happen if the snapshot time at
every site were a single global time.)
DISTRIBUTED SNAPSHOTS
A MESSAGE
i j FROM i TO J
i j
SITUATION I
Time ti
OK
tj
i j
SITUATION II ti
Time
BAD
tj
SITUATION III i j
Time tj
ti
IN TRANSIT -- OK
received
flagged
token
SNAPSHOT PROTOCOL IS CORRECT
Remember that we must prevent a node i
from receiving a message before its
snapshot time, ti, that was sent by a node j
after its snapshot time, tj.
But any message sent after the snapshot will
follow the flagged token at the receiving site
because of the FIFO discipline on links. So,
bad case cannot happen.
SYNCHRONIZER
It is often much easier to design a distributed
protocol when the underlying system is
synchronous.
In synchronous systems, computation
proceeds in “rounds”. Messages are sent at
the beginning of the round and arrive before
the end of the round. The beginning of each
round is determined by a global clock.
A synchronizer enables a protocol designed
for a synchronous system to run an
asynchronous one.
PROTOCOL FOR SYNCHRONIZER
1. Round manager broadcasts “round n begin”
Each node transmits the messages of the
round.
2. Each node then sends is flagged token and
records that time as the snapshot time.
(Snapshot tokens are numbered to
distinguish the different rounds.)
3. Each node receives messages along each
link until it receives the flagged token.
4. Nodes perform non-interfering termination
back to manager after they have received a
token from all neighbors.
MINIMUM-HOP PATHS
Task is to obtain the paths with the smallest number of links
from a given node s to each other node in the network.
Suppose the network is synchronous. In the first round s
sends to its neighbors. In the second round, the neighbors
send to their neighbors. And so it continues.
When node I receives id s, for the first time, it designates the
link on which s has arrived as the first link on the shortest
path to s.
Use the synchronization protocol to simulate rounds.
S S
D D
C E F C E F
MINIMUM-HOP PATHS
The round by round approach takes a long
time. Can you think of an asynchronous
approach that takes less time?
How do you know when you’re done?
S S
D D
C E F C E F
CLUSTERING
K-means clustering:
Choose k centroids from the set of points at random.
Then assign each point to the cluster of the nearest centroid.
Then recompute the centroid of each cluster and start over.
Initiator
Fault-Tolerant Broadcasts
m m’
A B
U1 m’ U2
A m B
Total Order (Atomic Broadcast)
Send
message m
Proposed timestamp (e.g., 17),
based on local Lamport time
Take max.
(e.g., 29)
Final timestamp
Accept m.
Broadcast
token token
site
REVISIT ASSUMPTIONS
Sites do not lie about their state (i.e., no
malicious sites; could use authentication).
Sites tell you when they fail (e.g. through
redundant circuitry) or by not responding.
If there is a network partition, then no negative
ack would occur, so must keep message m
around until everyone has acquired the token
after m was sent.
ROAD MAP: COMMIT PROTOCOLS
All-or-nothing
Recovery of data commitment of
following fail-stop transactions.
failures Avoid partial updates.
Fail-stop failures.
THE NEED
Servers
TM
Done
Commit
INVENTORY INCREMENTED
Commit
No!
Prepare
Yes
Prepare
Prepare
Servers
TWO-PHASE COMMIT: PHASE 2
– If all servers say yes, then transaction manager writes a commit
record to stable storage and tells them all to commit, but if some say
no or don’t respond, transaction manager tells them all to abort.
– Upon receipt, the server writes the commit record and then sends an
acknowledgement. The transaction manager is done when it
receives all acknowledgements.
Commit Commit
Ack Commit
ALL OF TWO-PHASE COMMIT
Transaction
Server
Manager
Prepare
Yes
Commit
Done
States of server
Prepare Commit
Active Ready to
Committed
Commit
Cannot
prepare
Aborted
QUESTIONS AND ANSWERS
Q: What happens if the transaction manager fails?
A: A database server who said yes to the first phase but has
received neither a commit nor abort instruction must wait
until the transaction manager recovers. It is said to be
blocked.
Q: How does a recovering transaction manager know whether
it committed a given transaction before failing?
A: The transaction manager must write a commit T record to
stable storage after it receives yes’s from all data base
servers on behalf of T and before it sends any commit
messages to them.
Q: Is there any way to avoid having a data base server block
when the transaction manager fails?
A: A database server may consult other database servers who
have participated in the transaction, if it knows who they are.
OPTIMIZATION FOR READ-ONLY
TRANSACTIONS
Read-only transactions.
Suppose a given server has done only reads
(no updates) for a transaction.
• Instead of responding to the transaction manager
that it can commit, it responds READ-only
• The transaction manager can thereby avoid sending
that server a commit message
THREE-PHASE COMMIT
Willing?
Willing-Yes
Prepare
OK
Committed
Done
STATES OF SERVER ASSUMING FIRST
TM DOES NOT FAIL
Send Receive
Willing-Yes Prepare
No
Receive
Committed
Abort
Committed
INVARIANTS while first TM active
• No server can be in the willing state while any other
server (live or failed) is in the committed state
• No server can be in the aborted state while any other
server (live or failed) is in the ready-to-commit state
Some may have aborted
Active
No one has committed.
Willing
Ready to Commit
Committed
CONTRAST WITH TWO-PHASE
COMMIT
Active
Ready to Commit
Committed
RECOVERY IN THREE-PHASE COMMIT
after first TM fails or slows down too much
What the newly elected TM does:
Any
Ready-to-Commit
Any or
Aborted? Committed
Send Send
ABORT Committed
All Willing
Send Send
ABORT; PREPARE; COMMITTED
ROAD MAP: KNOWLEDGE LOGIC
AND CONSENSUS
Attack Agreed
A B A B
WILL IT EVER END?
A B A B
IT NEVER ENDS
Theorem: Assume that communication is unreliable. Any
protocol that guarantees that if one of the generals
attacks, then the other does so at the same time, is a
protocol in which necessarily neither general attacks.
10 AM? OK
A B A B
But will he
show up?
BACK TO COMPUTERS
While ostensibly about military matters, the Two Generals
problem and the Byzantine Agreement problem should
remind you of the commit problem.
• In all three problems, there are two possibilities: commit
(attack) and abort (don’t attack).
• In all three problems, all sites (generals) must agree.
• In all three problems, always aborting (not attacking) is not an
interesting solution.
Knowledge Logic:
consensus Failures of all types
….1 0 1 1 0 0 0 0 1
S R
MODEL
• Messages are kept in order
• Sender and receiver are synchronous. This
implies that sending a blank conveys information.
Ks Kr y
Ack2
Ack3 Kr Ks Kr y
Ks Kr Ks Kr y
EXERCISE
Suppose that the symbol after y is y’ and y’ y.
Then can S send y’ as soon as it receives ack to y?
(Assume R has a way of knowing that it received
y and y’ correctly.)
S sends y S R
R sends ack Kr y
Ack
S sends y’
Ks Kr y
y’
R sends ack …
Kr y’; Kr Ks Kr y
ENCODING PROTOCOL IN 0’s and 1’s
Protocol Symbol Encoding
Blank 11
0 00
ack 0
1 01
ack3 1
ack2 10
ack2 ack
S 10 R 0
0 ack3
00 1
1
01
WHAT IS SENT
WHAT DO WE WANT FROM AN
ENCODING?
1. Unique decidability. If e(x) is received
uncorrupted, then recipient knows that it is
uncorrupted and is an encoding of x.
2. Corruption detectability. If e(x) is
corrupted, the recipient knows that it is.
Thus, receiver knows when it receives good
data and when it receives a garbled
message.
ENCODING FOR DELETIONS AND MUTATIONS
Recall that mutation means that a 0 can become a 1 or vice versa.
Encoding (b is blank) Protocol Symbol Encoding
Blank bbb1
0 1bb b
ack 1b
1 b1b b
ack3 b1
ack2 bb1 b
ack
Note: S R
The same extended alphabet
ack2 protocol will work.
S R
Any insertion will result in two
ack3
non-blank characters. A mutation
S R can only change a 1 to a 0.
Self-Stabilizing Systems
• A distributed system is self-stabilizing if,
when started from an arbitrary initial
configuration, it is guaranteed to reach a
legitimate configuration as execution
progresses, and once a legitimate
configuration is achieved, all subsequent
configurations remain legitimate.
Self-Stabilizing Systems
(using invariants)
• There is an invariant I which implies a
safety condition S.
• When failures occur, S is maintained
though I may not be.
• However when the failures go away, I
returns.
• http://theory.lcs.mit.edu/classes/6.895/fall02/papers/Arora/masking.pdf
Self-Stabilizing Systems
components
• A corrector returns a program from state S
to I: e.g. error correction codes, exception
handlers, database recovery.
• A detector sees whether there is a
problem: e.g. acceptance tests, watchdog
programs, parity ...
Self-Stabilizing Systems
example
• Error model: messages may be dropped.
Clock
Fault Tolerance
Synchronization
Operating System
Scheduling
Real-Time
SYSTMES THAT CANNOT OR SHOULD NOT WAIT
Time-sharing operating environments: concern for
throughput.
Want to satisfy as many users as possible.
Soft real-time systems (e.g., telemarketing): concern for
statistics of response time.
Want a few disgruntled customers.
Firm real-time systems (e.g., obtain ticker information on
Wall Street): concern to meet as many deadlines as
possible.
If you miss, you lose the deal.
Hard real-time systems (e.g., airplane controllers):
requirements to meet all deadlines.
If you miss, then airplane may crash.
DISTINCTIVE CHARACTERISTICS OR REAL-TIME SYSTEMS
1. Predictability is essential – For hard, real-time systems the time to
run a routine must be known in advance.
Implication: Much programming is done in assembly language.
Changes are done by “patching” machine code.
2. Fairness is considered harmful – We do not want an ambulance
to wait for a taxi.
3. Implication: messages must be prioritized, FIFO queues are bad.
4. Preemptibility is essential – An emergency condition must be able
to override a low-priority task immediately.
5. Implication: Task switching must be fast, so processes must
reside in memory.
6. Scheduling is of major concern – The time budget of an
application is as important as its monetary budget. Meeting time
constraints is more than just a matter of fast hardware.
7. Implication: We must look at the approaches to scheduling.
SCHEDULING APPROACHES
1. Cyclic executive – Divide processor time into
endlessly repeating cycles where each cycle is
some fixed length, say 1 second. During a
cycle some periodic tasks may occur several
times, others only once. Gaps allow sporadic
tasks to enter.
2. Rate-monotonic – Give tasks priority based on
the frequency with which they are requested.
3. Earliest-deadline first – Give the highest
priority to the task with the earliest deadline.
CYCLIC EXECUTIVE STRATEGY
Gap T1
T3
T4
Gap
T1
T1
T2
Gap
T2 150 40
T3 350 100
T3
T2
T1
T1 preempts
T2
T3
T3 acquires lock
SPECIAL CONSIDERATIONS FOR
DISTRIBUTED SYSTEMS
Since communication is unpredictable, most distributed non-shared
memory real-time systems do no dynamic task allocation. Tasks
are pre-allocated to specific processors.
Example: oil refineries where each chemical process is controlled by a
separate computer.
Paper cups.
Pieces of paper.
Pencils.
Remember: We just need to know if the
same person is being complained about.
PUBLIC-KEY ENCRYPTION
Motivation: Eliminate need for shared keys when
keeping secrets.
The new idea is to put some information in a public
place.
Here are the details:
• Associated with each user u is an encryption function E_u
and a decryption function D_u.
• For all messages m, E_u(m) is unintelligible even knowing
E_u. However, D_u(E_u(m)) = E_u(D_u(m)) = m.
• E_u is public.
• Given E_u and E_u(m), it is impossible to figure out D_u.
USING PUBLIC-KEY ENCRYPTION
• To send a message m to u that only u can read:
Send E_u(m)
• For user t to sign and send a message m to u, t
can”
Send D_t(E_u(m)).
The receiver u can prove that t sent this
message, because only t knows D_t.
Further, only u (and t) can read the message.
SSL (Secure Socket Layer)
• Effect: client knows it is talking to a certain
server; client remains anonymous to
server; communication is secure.
• Useful for purchases, even anonymous
ones.
SSL Method -- simplified
• Client uses the well known public
encryption method of the server to
communicate desire to communicate.
Nobody can eavesdrop. Client also
generates a session private key.
• Server responds with the private key and
then communication proceeds.
One Way Functions
• Given a function like triple, if I tell you that 15
has been produced by triple(x), you can infer
that x is 5.
• By contrast, given certain hash functions, if I tell
you h(x) it is very hard to infer x. Such (hard to
find the inverse) functions are called one-way.
• Ex: Given x, compute x2 then take the middle 20
digits. Given those digits, hard to find x.
• There is a standard one-way hash function
called SHA-1.
One Way Functions for Spies
• You have a bunch of spies. They are good
people, very trustworthy.
• They go into enemy territory. When they return
they must say something to the guards so they
don’t get shot. Passwords can’t get reused for
security.
• Also guards might go into a bar and be tempted
to reveal secrets.
• Could we use one way functions in some way?
Should I get a file from this site?
• Suppose you want to download some file (say a
special kind of player) from a web site.
• You want to be sure that web site is to be
trusted.
• Otherwise, you might be getting a “Trojan horse”
(something that looks good but can do you
harm).
• You believe that trusted entities will keep their
private keys secret.
Secure File System Protocol
(David Mazieres)
• Basically, the downloader uses an SSL
interaction with the server that downloader
trusts.
• That is, downloader encrypts a session
private key using that server’s public key.
• So, nobody else can know what
downloader requested.
• Not yet solved: how does downloader
know this server is validated by author?
Secure File System Protocol
key insight
• Each file name is of the form:
/sfs/nyu/cs5349874628/dennis/foobar
The funny number is the SHA-1 hash of the
public key of the proper server.
So, this is the proper server for the file iff the
public key of the server Pk when hashed
gives cs5349874628.
Downloader checks this before sending the
SSL message which will use Pk.
Secure File System Protocol
questions
• What if you lie about your public key?
• How do I discover these strange names?
Secure File System Protocol
answers
• What if you lie about your public key?
– You can but then you won’t have the
associated private key so won’t be able to
respond properly to my SSL request.
• How do I discover these strange names?
– There does have to be one site you trust
which has names you believe.
Secure File System Protocol
summary
• Downloader goes to trusted name server site.
• Gets name (including funny encrypted part) and
maybe other information, e.g. hash of the
contents.
• Goes to a server that allegedly holds that file. If
server’s public key when hashed equals the
funny part of the name, then that server is
legitimate.
• So, downloader engages that server in SSL and
downloads the file confidentially.
Spy Border puzzle (McCarthy/Rabin)
• Spies go across border.
• When they return, they don’t want to be
shot so they want to give a password.
• Spies are clever and professional but
border guards have been known to have
loose tongues, so conventional password
might get leaked.
• What to do? (Hint: one-way functions)
Courier Problem
• Capture a courier and you may change history
(e.g., Hannibal and his brother Mago).
• So want to send n couriers with parts of a
message. If majority of couriers arrive, then can
reconstruct message. Any minority reveal
nothing.
• How to do this?
(Hint: start with three couriers.
Hint 2: polynomial of degree 2 can be
determined by three points.)
Assuring honesty in SETI-at-home
• I want a site to execute a function f on x1,
x2, …, xn.
• How do I know it’s doing so?
• Possibility: Compute some of the values
e.g. f(xi) and f(xj), and send those too.
Ask to be told i and j.
• Still some possibility of cheating, e.g. once
those two indices are found, could give
guesses for other f(xk)s.
Better Solution
• Also send some value y such that for NO j
is it the case that y = f(xj). (Don’t tell of
course)
• Now the function producer must state that
y is not the result of f on any input.
• Function producer could guess this, but
then risks getting caught.
• Ref: Radu Sion