General

Communication models

• producer-consumer problem
  • represents common type of inter-process cooperation
  • producer: produces information (& puts into buffer)
  • consumer: consumes information (e.g. display)
• unbounded buffer: places no practical limit on the size of the buffer
• bounded buffer: assumes: fixed puffer size

Shared memory

• shared data

  • bounded buffer: pseudocode

    #define BUFFER_SIZE 10
    typedef struct {
      ...
    } item;
    item buffer[BUFFER_SIZE];
    int in = 0;
    int out = 0;
    

  • allows at most BUFFER_SIZE-1 items in buffer at same time
    • "one" of the common communication method
    • different implementations: can use all BUFFER_SIZE items
  Pseudocode

  s
  

Message passing

• mechanism for communication & synchronization
• without sharing the same address
• particularly useful: in distributed environment
• IPC facility: provides
  • send (message)
  • receive (message)
• message size: can be either fixed / variable
• in order to processes to communicate, they need to
  • establish a communication link between them
    • 👨‍🏫 need to know somehow each other's identity!
    • such processes can eue either direct / indirect communication
  • exchange messages visa primitives: send(), receive()
• different methods exist

Direct communication

• processes: must name each other explicitly
  • usually: PID, but can be acronyms, etc.
  • send(P,m)
• d

Indirect Communication

• messages: sent to and received from mailboxes
  • each mailbox: w/ unique id
  • processes: can communicate only if they share a mailbox
• properties of communication link
  • link: established written a pair of processes
    • only if both members of pair: w/ shared mailbox
  • d
• basic mechanism to support:
  • create a new mailbox
  • send & receive messages through the mailbox
  • destroy the mailbox
• primitives: defined as
  • send(A,message): send message to mailbox: $A$
  • send(A,message): receive message from mailbox: $A$
• mailbox sharing
  • $P_1,P_2,P_3$: shares mailbox
  • can $P_2,P_3$ receive message from $P_1$?

  • solutions

Synchronization

• message passing: either blocking / non-blocking
  • or: synchronous - asynchronous
• 4 possibilities
  • status of sender & receiver
• blocking: considered synchronous
  • blocking send: sending process: blocked until message is received
    • i.e. I'll until you confirm
  • blocking receive: receiver blocks until a message is available
    • i.e. give me message! give me message! give me message!
• non-blocking: considered asynchronous
  • non-blocking send: sending process: sends message & resumes operation
  • not waiting for message reception
  • non-blocking receive: receiver: retrieve either a valid message / null
• rendezvous: when send() and receive() are both blocking
  • i.e. common place
  • pseudocode

  • producer-consumer: becomes trivial

Buffering

• either direct / indirect, messages exchange by communicating processes reside in a temporary queue
• queue: either in three ways
  1. zero capacity: no messages are queued on a link
     • sender: must wait for receiver
  2. zero capacity: no messages are queued on a link
     • sender: must wait if link is full
  3. unbounded capacity: infinite length
     • sender never waits

Pipes

• piped: one of the first IPC mechanism in early UNIX systems
  • is communication: unidirectional / bidirectional?
  • must there exists a relationship between processes?
    • e.g. parent-child
  • can the pipes:used over a network?
    • or only on the same machine?
• ordinary pipes: cannot be accessed from outside the process that created it
  • typically: parent process creates a pipe
  • and uses it to communicate with child, made by fork()
• names pipes: can be accessed without a parent-child relationship
  • destroyed by the OS upon process termination

Ordinary pipes

• communicates in a standard producer-consumer fashion
• pipe(int fd[]) in unix: unidirectional
  • producer: writes to one end (write end, fd[1])
  • producer: reads from end (read end, fd[0])
• requires parent-child relationship
• cannot be accessed from outside the process created them
  • cease to exist after processes finish communication & terminated
• 
• unix: treats pipe as a special type of file
  • standard read(), write(), and the child: inherits pipe from parent process
  • parent process: use pipe() to create pipe
    • then use fork to create a child process
      • child: inherits pipe as well
      • 👨‍🏫 inherited fo one child only, in original UNIX
• example code

Names pipes

• more powerful than ordinary pipes!
  • bidirectional
  • no parent-child relationship required
  • multiple process can use it (w/ several writers)
• names pipes: continues to exist after processes terminate
  • must be explicitly deleted
• names

Client-server communication

• sockets
  • defined as: endpoint for communication
    • pair of process communicating over a network:
    • employs a pair of socket
  • uniquely identified by an IP address and a port number
    • port: specifies process / application on client / server side
  • server: waits for incoming client requests
    • by listening to a specified port (well-knowns)
    • once received: server can choose to accept the request
      • to establish a socket connection
    • port number: different for different process
      • although they are the same application
      • e.g. two tabs of chrome browser: separate process & separate port number!
• remote procedure calls (RPC)
  • one of the most common forms of remote services
    • procedure-call mechanism: for use between systems w/ network connections
  • RPC: commonly used for implementing distributed file systems

Sockets

• servers: listen to well-known ports (SSH-22; FTP-21; HTTP-80)
  • all ports below 1024: well-known and reserved for standard services
  • server: always running & with well-known IP address & IP
• only client: can initialize communication
• when client initiate a request:
  • it should know its OP address
  • and select a client port number not in use ($1024$)
  • 4-tuple: uniquely determines a pair of communication
    • source IP address
    • source port number
    • destination IP address
    • destination port number
  • 👨‍🏫 even only 1/4 are different: they are different pair!
• ⭐⭐ requirements for communication to occur
  1. server: MUST BE ALWAYS RUNNING
  2. server address & port: MUST BE KNOWN
     • server side port: the same
       • HTTP: 80
     • IP address: known by domain naming system (DNS)
       • original idea: having a gigantic machine with single IP address
       • however: cannot handle world-size traffic like Google
     • professor: has a 1999 paper on how to allocate replica
       • which server to access (i.e. nearby / quickest)
       • which IP to access (relating to DNS)