1. FIspace Review meeting M12 CSB

2. Cloud Service Bus Bus Coordinator Bus Node Service A Service SDI VM External Services and Data Scalable communication, based on peer2peer overlay Automatic scalability Robustness Queuing Message expiration Publish/subscribe Request/response Multi-tenancy VM Service Service B Service

3. 3 SR Overlay – The Virtual Ring SR is based on the Chord overlay Each process has a logical id of m bits, e.g., the output of hashing the process’s name or IP address and port number (e.g., using SHA-1) Each process p maintains links to its neighbors in the ring – successor (p) – the “first” process clockwise – predecessor (p) - the “first” process counter-clockwise For example, process N8 maintains links to process N21 (its successor) and to processes N1 (its predecessor) N1 N8 N21 N42 N55 N51 N32 N8’s Predecessor N8’s Successor

4. 4 SR Overlay – The Finger Table Each process p also maintains links to a process with id= – p+2^0 (or to successor of p+2^0) – p+2^1 (or to successor of p+2^1) –. – p+2^i (or to successor of p+2^i) –. – p+2^(m-1) (or to successor of p+2^(m-1) This list of links is called finger table and it contains O(log N) links p p+2^0 p+2^1 p+2^2 p+2^3 p+2^4 p+2^5

5. 5 Point-to-Point Communication Routing requires only O(log N) hops (messages) – With each forwarding the distance to the target is reduced by (at least) 50% Example, assume process N8 wants to send a message to processes N55 – At N8: send(message,N55) – N8 returns next hop = N42 – N42 returns next hop = N51 – N51 returns next hop = N55 N1 N8 N21 N32 N42 N55 N51 N1, N21, N32, N42 N1, N32, N51 N8’s finger table N42’s finger table

6. Queuing Any client can send messages to a “queue”; any client can retrieve messages from a “queue” Email for applications (with multiple readers) Highly reliable (persistent) delivery of transactional data Asynchronous (receivers can run and get data any time later) Identical message order for all receivers

7. Request/ response Synchronous Request/Response – synchronously query one another for a value of specific attributes or for any other information – requester sends a request and waits for a response, up to a specified timeout – optimal when the response information can be retrieved quickly by the responder Asynchronous Request/Response – response with unpredictable timing – multiple responses to a single request – for example, future notifications upon attribute value change. response listener callback, – send response messages at any time, without a limit of number of responses for each request Time-limited asynchronous Request/Response – time required to produce a response is long – requester is not blocked on a synchronous request – requester sends an asynchronous query, and sets a response timer – WAIT_TIMEOUT notification