A1 RPC - Wintersemester MW Mitschriften und Aufgaben PDF

Preview

Summary

Wintersemester MW Mitschriften und Aufgaben...

Description

! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !

TUM I 13 Chair of Application and Middleware Systems Prof. Dr. H.- A. Jacobsen Author(s): Dr. Ruben Mayer, M.Sc. Alexander Isenko

Tutorial

Middleware

Issued on: 01.11.2021

WS 2021/22

1. R EMOTE P ROCEDURE C ALLS E XERCISE 1 RPC execution When a client executes a procedure on a remote machine, it is called a Remote Procedure Call (RPC). Distributed databases use RPCs in order to establish the communication between client and server. Now imagine a server that aggregates key-value pairs. The client sends a key-value pair (k, v) as request to the server. The server stores a map of aggregated key-value pairs. On a client request, the server looks up the key k in its map. If the key does not exist, the server inserts (k, v) into the map. If the key exists, the value v is added to the stored value. Finally, the server sends back the key k and the aggregated value. Different servers do not share the key-value store. Example: The successful message transfer is denoted as c ! s. The succeesful message processing of the key-value pair (k, v) on the server s is denoted as s (k, v). A full transaction with a client message, server processing and server acknowledgement looks like this: • c ! s(k1 , 5), s

(k1 , 5), s ! c(k1 , 5)

Now, consider two servers s1 and s2 , as well as four clients c1 -c4 . Complete the following sequence of events for every RPC: 1. c2 ! s2 (k1 , 5) 2. c1 ! s1 (k2 , 1) 3. c2 ! s2 (k1 , 4) 4. c4 ! s1 (k3 , 9) 5. c4 ! s1 (k3 , 2)

1

! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !

TUM I 13 Chair of Application and Middleware Systems Prof. Dr. H.- A. Jacobsen Author(s): Dr. Ruben Mayer, M.Sc. Alexander Isenko

E XERCISE 2 RPC failure semantics There are four levels of failure semantics which we discussed in the lecture: maybe, at least once, at most once and exactly once. A RPC system always implements one of those semantical levels. Again, consider four clients and c1  c4 and two servers s1 , s2 . They use the following semantics: • c1 $ s1 and c2 $ s1 implement the maybe semantics • c3 $ s1 and c4 $ s1 implement the at least once semantics • c1 $ s2 and c2 $ s2 implement the at most once semantics • c3 $ s2 and c4 $ s2 implement the exactly once semantics Please use the following notation to complete the sequence of events for every RPC: • A server crash with a following restart is denoted as 6 s, s⇤ • A client crash with a following restart is denoted as 6 c, c⇤ • A successful message processing by the server is denoted as s • A server crash while processing a message is denoted as s 6

(k, v)

(k, v), 6 s, s⇤

• A successful message transfer is denoted as c ! s(k, v) or s ! c(k, v) • A message loss is denoted as c 6 ! s(k, v) or s 6 ! c(k, v) • „ client-timeout, c ! s(k, v)” means that the client did not hear from the server and had to resend the request • s ! c(fail) means that the server sends a failure message to the client Complete the following sequences of events for every RPC: 1. c3 ! s1 (k2 , 4) 2. c2 ! s2 (k3 , 2) 3. c1 ! s1 (k1 , 3) 4. c2 6! s1 (k1 , 3) 5. c4 6! s2 (k1 , 2) 6. c3 6! s2 (k3 , 8), client-timeout, c3 ! s2 (k3 , 8) 7. c4 ! s2 (k1 , 3), s2

(k1 , 5), s2 6! c4 (k1 , 5)

8. c4 6! s1 (k2 , 8) 9. c3 ! s1 (k3 , 14), s1

(k3 , 14), s1 6! c3 (k3 , 14)

10. c4 ! s1 (k2 , 4), s1

(k2 , 16), 6 c4 , s1 6! c4 (k2 , 16), c4 ⇤

11. c2 ! s1 (k1 , 3), s1 6

(k1 , 6), 6 s1 , s1 ⇤

12. c1 ! s2 (k1 , 10), s2 6

(k1 , 15), 6 s2 , s2 ⇤

13. c1 6! s2 (k2 , 5), client-timeout, c1 ! s2 (k2 , 5) 14. c2 ! s2 (k1 , 1), s2

(k1 , 6), s2 6! c2 (k1 , 6)

15. c1 ! s1 (k1 , 5) 16. c3 ! s2 (k1 , 1), s2 6

(k1 , 7), 6 s2 , s2 ⇤ 2

TUM I 13 Chair of Application and Middleware Systems Prof. Dr. H.- A. Jacobsen Author(s): Dr. Ruben Mayer, M.Sc. Alexander Isenko

E XERCISE 3 REST Representational state transfer is a style to design a request/reply web-based API. It is based on CRUD (create, read, update, delete) operations, which proved useful to model resource access. The resource access is based on URLs (www.myshop.com/items) and the HTTP protocol, which specifies the kind of action that should be taken (GET, POST, ...). The HTTP payload has properties like Content-type: application/json which may specify arguments how to process the request. Status codes are the return arguments of HTTP requests which provide information on how the server reacted to the request. Take a look at the official REST spec and PATCH spec for further information. Please supply the missing information for the following requests based on an online-shop example. Example: Return all items as JSON GET https://myshop.com/items Content-type: application/json Payload: {} Create new item ______ https://myshop.com/________ Content-type: application/json Payload: {id: 2, name: "cactus", price_in_euro:

4.50}

Table 3.1: a) Return items with price_in_euro > 100 as plain text ______ https://myshop.com/items?_____________[gt]=100 Content-type: ____________ Payload: {} Table 3.2: b) Update the price for item (id: 2) to 20 euro ______ https://myshop.com/items/____ Content-type: application/json Payload: ________________________________________________ Table 3.3: c) Delete all items with price...