Please enable JavaScript.

Coggle requires JavaScript to display documents.

Interprocess Communication (IPC) (Eventual Consistency (Implementing…

- - - - 15 primitive data types, sent either in big-endian or little-endian orderings (sending most significant bit first or last) -> specified in message
      - Every field is 4 bytes long
      - Send length first, then the value multiple times
      - Represented in binary form
      - Assumes both sender and receiver have common knowledge of the order and types of data items to be sent in a message
      - CORBA interface compiler generates marshalling + unmarshalling operations
    - - Definitions
        
        Serialisation: activity of flattening an object to be suitable for storage or transmission
        
        Deserialisation: activity of restoring the state of the object
      - Serialising an object
        
        Include information about the class of the object (e.g. name of class, version)
        
        All objects referenced are serialised as handles
        
        Contents of primitive instance variables that are primitive types are written in a portable format in ObjectOutputStream class. Strings + chars writtten using writeUTF() in the same class
        
        Row 1: class name, version number
        Row 2: number, type and name of instance variables
        Row 3: values of instance variables
        
        Implement the Java Serialisable interface
      - During remote method invocation, arguements + results are serialised and deserialised by middleware
      - Reflection property supported by Java allows serialisation and deserialisation to be carried out automatically
      - Represented in binary form
    - - Markup language: Textual encoding representing data + details of structure
      - A markup language defined by Word Wide Web Consortium (W3C)
      - Tags describe the logical structure of data
      - Extensible: additional tags can be defined
      - Tags are generic
      - Self-describing unlike CORB CDR; (tags describe data)
      - Tags + namespaces = meaningful tags
      - Data is textual
        
        Readable by humans
        
        Platform independent
        
        Messages are large -> longer processing and transmission times; more space to store
      - Components
        
        Elements
        
        Consists of data surrounded by tags
        
        Elements can be enclosed within elements --> hierarchical representation
        
        Empty tag with no contents is terminated with />
        
        Attributes
        
        Start tag may optionally contain attributes (names + values)
        
        E.g. id="123456"; name, type
        
        Namespaces
        
        Name for a collection of element types + attributes; referenced by a URL
        
        Specified with an attribute xmlns = URL referring to the file containing the namespace definition
        
        XML Schema
        
        Defines the elements + attributes that can appear in a document
      - XML vs CORBA
        
        Self-describing: tags describe logical strucure + generic
        
        Extensible
        
        Human readable: tags+namespaces, textual data
    - - A lot more succinct
      - Object: {}
        Array: []
        String: " "
      - JSON vs XML
        
        Less configuration overhead
        
        XML has to be parsed with an XML parser. JSON can be parsed by a standard JavaScript function into a ready-to-use JavaScript object
        
        JSON serialisation produces shorter strings than XML -> reduce amount of data transmission + improve performance
- - - - Fault tolerance based on replicated services
      - Finding discovery servers
      - Better performance through replicated data
      - Propagation of event notification
  - - - Available only for UDP
      - An application can send UDP datagrams to a multicast address and ordinary port numbers
      - An application can join a multicast group by making its socket join the group
      - When a multicast message reaches a computer, copies are forwarded to all processes that have sockets bound to the multicast address and the specified port number
- - - - Client
        
        Create socket specifying server address + port
        
        Read + write data using stream associated with the socket
      - Server
        
        Create listening socket bound to server port
        
        Wait for clients to request a connection (Listening socket maintains a queue of incoming connection requests)
        
        Server accepts connection -> creates new stream socket for communication -> pair of sockets are connected by a pair of streams (one for input, another for output)
      - Start/renew with random number for
        
        Security purposes: avoid hackers
        
        Avoid thinking it's the same session
    - - Need pre-agreed format for data sent over socket
      - Blocking possible at both ends
      - If the process supports threads, recommend a thread being assigned to each connection so that other clients will not be blocked
    - - Data corruption: use checksum
      - Data duplication: use sequence numbers
      - Lost packets: timeouts and retransmission
      - Severe congestion: declare connections to be broken --> not reliable communication
      - Broken communications: cannot distinguish between network failure and process crash
      - Communicating process cannot definitely say whether the messages sent recently were received
  - - - Server (receiver) binds socket to server port; made known to client
      - Client (sender) binds socket to any free port on the client machine
      - Receive method returns
        
        Sender IP
        
        Sender port
        
        Message allowing replies to be sent
    - - Receiving process defines array of bytes to receive the message
      - If message is too big, gets truncated
      - Protocol allow packet lengths of 2^16 bytes, but practical limit is 8 KB
    - - Non-blocking sends + blocking receives (wait until something is received)
      - Operation returns when message copied to buffer
      - Message is delivered to the message buffer of the socket bound to the destination port
      - Outstanding/future invocations of the receive on the socket can collect the messages
      - Messages are discarded if no socket is bound to the port
    - - Receive will wait indefinitely until messages are received
      - Timeouts can be set on sockets to exit from infinite waits + check the condition of the sender
    - - Data corruption: use checksum
      - Omission failures: full buffers, corruption, dropping
      - Order: messages might be delivered out of order
    - - DNS
      - Voice over IP
- - - - Harder to program: need to know which messages are relating to each other
      - Would have higher performance
  - - - Exactly one receiver (process binded to it)
      - Multiple senders
  - - - For a process to receive messages, its socket must be bound to a local port on one of the Internet addresses of the computer
      - Can be used for sending and receiving
        
        Same socket can be used both for sending + receiving messages
        
        Processes can use multiple ports to receive messages
        
        Ports cannot be usually shared between processes for receiving messages
        
        Any number of processes can send messages to the same port
        
        Messages sent to a particular port of an Internet address can only be received by a process that has a socket associated with the particular port number on that Internet address
      - Each socket is associated with a single protocol (UDP or TCP)
- - - - How consistent is my store under my given workload right now
      - Useful for runtime monitoring +alerts; verifying compliance with service-level objects (SLOs)
    - - How consistent will my store be under a given configuration + workload
      - Useful for probabilistic what-if analyses; dynamic tuning system behaviour
      - Only as good as the underlying model + input data
      - Assume past behaviour is correlated with future behavior
  - - - Compensation: ensures mistakes are eventually correcte, but no guarantee mistakes are not made
      - Maximise B-R*C where R is the rate of anomalies
      - Rate of anomalies depend on system architecure, configuration + deployment
    - - CALM theorem
        
        Programs that are monotonic + do not ever retract emitted facts can be safely run on an eventually consistent store
        
        Consistency as logical monotonicity
        
        Monotonic programs
        
        Initialise vriables
        
        Accumulate set members
        
        Testing threshold conditions
        
        Non-monotonic programs
        
        Variable overwrites
        
        Set deletion
        
        Counter resets
        
        Negation
        
        Need to deal with inconsistencies outside the system
      - ACID 2.0
        
        Associativity: apply a function in any order
        
        Commutativity: arguments are order-insensitive
        
        Idempotence: call a function on the same input any number of times and get the same result (e.g. max(42, max(42, 42))=42)
        
        Distributed
      - Commutative, replicated data types (CRDTs)
        
        Embodies CALM + ACID 2.0 principles
        
        Keep count of # operations, not the values themselves if strictly increasing/changing in one direction
        
        Limits operations an application writer can employ
    - - Impossible to make staleness guarantees in a highly available system; e.g. give me latest value
      - Cannot maintain arbitrary global correctness constraints over sets of data items e.g. create account with ID 50 if it doesn't exist; bank account balance should be non-negative
    - - Causality: process writes are seen in order of writes then reads (e.g. comment threads are seen in the correct order, without dangling replies)
      - Transactions