TU Wien:Verteilte Systeme VO (Dustdar)/Pruefung 2014-01-20

Aus VoWi
Zur Navigation springen Zur Suche springen

Fragenausarbeitung[Bearbeiten | Quelltext bearbeiten]

Beispiel für ein computing distributed System[Bearbeiten | Quelltext bearbeiten]

Cluster / Grid / Cloud

Bsp für ein storage DS[Bearbeiten | Quelltext bearbeiten]

RPC vs. RMI[Bearbeiten | Quelltext bearbeiten]

RPC: Remote Procedure Call, A process calls/invokes a remote procedure in another process, passing parameters and results needs an agreed message format. RMI: Remote Method Invocation/(remote object call): RPC in Java, RMI client locates objects on the servers rmi registry and invokes objects from this very server.

RPC/RMI vs. MOM[Bearbeiten | Quelltext bearbeiten]

MOM: Message-oriented-middleware, middleware which features async and sync communication. Messages can be passed directly or queued. Publish & Subscribe is supported. MOM vs RPC == Brot vs Stahlbeton? Vielleicht ist gemeint, dass bei Rpc aufrufer und aufgerufener beide aktiv sein müssen. Was bei einer MOM nicht so ist. Außerdem muss bei einer MOM der Sender den Empfänger nicht notwendigerweise kennen.

Welche Aussage trifft auf einen CODA Server mit Client-Side Cache zu[Bearbeiten | Quelltext bearbeiten]

?   single instance
YES   statfull
NO   stateless
NO   has to implement NFS

UNIX "always read last write" ist das mit CODA möglich (oder so wie)[Bearbeiten | Quelltext bearbeiten]

Security by Obscurity kurz erklären[Bearbeiten | Quelltext bearbeiten]

Security by obscurity is if the security of a system depends on hidden information rather than technical or mathematcial facts

File signieren (PKI)[Bearbeiten | Quelltext bearbeiten]

UI auf Client, Webserver auf Server - einen Client-Request Skizzieren (war mir nicht ganz klar was sie da wollen)[Bearbeiten | Quelltext bearbeiten]

Seite 90 oder 63 Folien 2013 (?)

3 Dinge die bei einem Client Request schief gehen können.[Bearbeiten | Quelltext bearbeiten]

Request can be lost during transmission, the server or client could crash or messages can arrive too late, thereby rendering them useless.

Wie hilft Replication um failures zu maskieren/transparent[Bearbeiten | Quelltext bearbeiten]

Should a replicated server go offline, then another instance of the server can begin handling client requests instead. The client is kept unaware that a replicated server in a group has gone offline and simply sends its requests to the address it always does.

LAN = reliable, WAN = unreliable JA/NEIN + eine zweite JA/NEIN[Bearbeiten | Quelltext bearbeiten]

LAN = reliable, WAN = unreliable JA

Fault -> Error -> Failure - Erklären[Bearbeiten | Quelltext bearbeiten]

Fault: Cause of an error

Error: Deviation of the actual system state from the perceived one

Failure: Delivered service deviates from correct service

Die 3 Arten der Replication[Bearbeiten | Quelltext bearbeiten]

Types of replication

  • Permanent
  • Server-initiated: Sometimes used in place of permanent replicas, meaning that replicas can be taken down and created at will. Other model is to maintain permanent replicas that can receive updates but then create server-initiated replicas that are read-only as traffic requires.
  • Client-initiated: caching

Types of content distribution:

  • State vs. operations: Invalidation protocols can be used to notify replicas that their data is no longer valid and what specific parts needs to be updated (many updates, few reads); modified data can be transferred to all replicas (many reads, few updates); the update operations themselves are propagated across the system on an active basis
  • Push/pull: Server actively pushes updates to all clients or clients can pull them when they need them; another option is a lease basis where the server promises to update the client for a pre-specified time interval after which the client must pull updates itself

Ein Grouping Operations Beispiel - ein Process liest ohne Lock - welche Garantien hat er?[Bearbeiten | Quelltext bearbeiten]

und welchen Wert liest er effektiv?[Bearbeiten | Quelltext bearbeiten]

Ring Algo - wann ist ein Node participant?[Bearbeiten | Quelltext bearbeiten]

A node is a participant in a ring when it actively takes part in forwarding messages through the ring. Should a node crash then it's predecessor passes the message to the crashed node's successor and both adjust their pointers, effectively removing the crashed node from the ring. Once the crashed node recovers it must rejoin the ring.

If P_k receives another ELECTION message with a smaller identifier after becoming participant, what should it do?[Bearbeiten | Quelltext bearbeiten]

  • Bully algo: If P_k has a higher number than the process sending an _ELECTION_ message, then it responds with _OK_ indicating that it has a higher number and will takeover. P_k then begins an election of its own. If no process responds with _OK_, then it announces that it is the new coordinator.
  • Ring algo: Elections are held immediately once it is noticed that the previous coordinator has crashed. A process sends a message to its successor and each process appends its number to the message. One the original message arrives at the initiator of the election, it checks who is the highest process and sends a message notifying all the ring members who the coordinator is.

DNS - wieso ist es sinnvoll wenn ein DNS server mehrer IPs zu einem Eintrag liefert?[Bearbeiten | Quelltext bearbeiten]

In order to keep a server accessible, multiple IP addresses for its replicas can be made available via DNS. Should one of the replicas crash, the data and/or services remain available at a different machine.

Frage 20[Bearbeiten | Quelltext bearbeiten]

Quelle[Bearbeiten | Quelltext bearbeiten]

Link zum Forum