- Grapevine was an early distributed system.
- Think of Grapevine as a distributed email system. Literally every
application is forced to fit this model.
- highly replicated distributed registration database ("DNS") which
provides name server lookups; hierarchical registries ("domain name
hierarchy"). Bootstrapping is fun.
- message servers: accept, queue, forward, & deliver (with duplicate
elimination) incoming email ("sendwhale"). Any message server will accept
& route any incoming message. "bounce message" sent when delivery
impossible. Replication of mail servers, but not of messages. Also sends
current inbox to authenticated users, who make a copy (yes, another copy!)
- inbox: a user's buffer where he receives email ("mail spool file"). Can
- Implementation experience:
- updating the registration database: a damned pain in the neck. Grapevine
trades off atomicity for simplicity. (Changing a decentralized distributed
database is nontrivial.) Updates propagate via email (!), using flooding
- naming: naming is distinct from addressing; you send email to "Dave",
and the servers figure out where "Dave" is located; you don't send email to
e.g. "email@example.com". Creating new names requires manual intervention
to screen the appropriateness of the names. (By the way, that's a clue that
somewhere folks are doing name-based authentication...)
- locating a user's inbox: cache lookups of names to inbox sites; cache
list of inaccessible message servers (but this is just a hint, since any
message server will accept any email).
- hindsight: should've allowed dynamic addition of new fields in the
Grapevine distributed database. Replication for availability worked well to
stop hardware failures, but there wasn't enough diversity in software
implementations to survive a software bug. (a cute interaction with the
reliable message transport protocol.) Testing with lots of users provided
- Key point: notice the similarities, and differences, between Grapevine and
"modern-day" distributed systems.