Chapter 4: Interprocess communication

1. Chapter 4: Interprocess communication • Introduction • The API for the internet protocols • External data representation and marshalling • Client-server communication • Group communication

2. Introduction • The middleware : • Design of the components: • Request-replay protocol • Marshalling and external data representation • Integrating communication into a programming language paradigm, for example: • Remote method invocation.(RMI) • Remote procedure calling.(RPC)

3. Figure 4.1Middleware layers

4. The API for the internet protocols

5. The characteristics of interprocess communication • Synchronous and asynchronous communication • In the synchronous form of communication, the sending and receiving process synchronize at every message • In the synchronous form of communication, Send and receive are blocking operations. • In the asynchronous form of communication, the use of send operation is non-blocking . • In the asynchronous form of communication, the transmission of the message proceed in parallel with the sending process • In the asynchronous form of communication, the receive operation can have blocking and non-blocking variants

6. The characteristics of interprocess communication • Message destinations • Each port has one receiver and could be many senders • Process may use multiple ports to receive messages • If the client uses a fixed internet address to refer to a service, then that service must always run on the same computer • That can be avoided by providing location transparency as follows: • Client programs refer to service by name and use a name server or binder to translate their names into server locations at run time.(service relocate) • The operating system. E.g.: Mach ( how does it work?).(service relocate and migrate)

7. agreed port any port socket socket message client server other ports Internet address = 138.37.94.248 Internet address = 138.37.88.249 Figure 4.2Sockets and ports

8. The characteristics of interprocess communication • Reliability: • validity • A point-to-point message service can be described as reliable if messages are guaranteed to be delivered • A point-to-point message service can be described as unreliable if messages are not guaranteed to be delivered • Integrity • Messages must arrive uncorrupted and without duplication • Ordering • Some applications require that messages be delivered in sender order

9. Sockets • For process to receive messages, its socket must be bound to a local port and one of the internet addresses of the computer • Java API for internet addresses InetAddressclass InetAddressaComputer= InetAddress.getByName(“bruno.dcs.qmul.ac.uk”);

10. UDP datagram communication Some issues related to datagram communication: • Message size: the receiving process needs to specify an array of bytes of a particular size. (message size is restricted) • Blocking: non-blocking sends and blocking receives • Timeouts : timeouts can be set on sockets and it should be fairly large in comparison with the time required to transmit a message. • Receive from any : invocation of receive method gets a message addressed to its socket from any origin. • Failure model • Omission failures : messages could be dropped • Send-omission failure • Receive-omission failure • Ordering : out of order

11. UDP datagram communication • Use of UDP • In DNS • In VOIP: Voice over IP • Java API for UDP datagram • DatagramPacket: • Message • Length of message • IP • Port # • DatagramSocket: • Send and receive • setSoTimeout • connect

12. Figure 4.3UDP client sends a message to the server and gets a reply import java.net.*; import java.io.*; public class UDPClient{ public static void main(String args[]){ // args give message contents and server hostname DatagramSocket aSocket = null; try { aSocket = new DatagramSocket(); byte [] m = args[0].getBytes(); InetAddress aHost = InetAddress.getByName(args[1]); int serverPort = 6789; DatagramPacket request = new DatagramPacket(m, args[0].length(), aHost, serverPort); aSocket.send(request); byte[] buffer = new byte[1000]; DatagramPacket reply = new DatagramPacket(buffer, buffer.length); aSocket.receive(reply); System.out.println("Reply: " + new String(reply.getData())); }catch (SocketException e){System.out.println("Socket: " + e.getMessage()); }catch (IOException e){System.out.println("IO: " + e.getMessage());} }finally {if(aSocket != null) aSocket.close();} } }

13. Figure 4.4UDP server repeatedly receives a request and sends it back to the client import java.net.*; import java.io.*; public class UDPServer{ public static void main(String args[]){ DatagramSocket aSocket = null; try{ aSocket = new DatagramSocket(6789); byte[] buffer = new byte[1000]; while(true){ DatagramPacket request = new DatagramPacket(buffer, buffer.length); aSocket.receive(request); DatagramPacket reply = new DatagramPacket(request.getData(), request.getLength(), request.getAddress(), request.getPort()); aSocket.send(reply); } }catch (SocketException e){System.out.println("Socket: " + e.getMessage()); }catch (IOException e) {System.out.println("IO: " + e.getMessage());} }finally {if(aSocket != null) aSocket.close();} } }

14. Figure 4.3UDP client sends a message to the server and gets a reply import java.net.*; import java.io.*; public class UDPClient{ public static void main(String args[]){ // args give message contents and server hostname DatagramSocket aSocket = null; try { aSocket = new DatagramSocket(); byte [] m = args[0].getBytes(); InetAddress aHost = InetAddress.getByName(args[1]); int serverPort = 6789; DatagramPacket request = new DatagramPacket(m, args[0].length(), aHost, serverPort); aSocket.send(request); byte[] buffer = new byte[1000]; DatagramPacket reply = new DatagramPacket(buffer, buffer.length); aSocket.receive(reply); System.out.println("Reply: " + new String(reply.getData())); }catch (SocketException e){System.out.println("Socket: " + e.getMessage()); }catch (IOException e){System.out.println("IO: " + e.getMessage());} }finally {if(aSocket != null) aSocket.close();} } }

15. TCP stream communication The following characteristics of the network are hidden by the stream abstraction: • Message size : the underlying implementation of a TCP stream desides how much data to collect before transmitting it as one or more IP packets. • Lost message : using ACK scheme • Flow control : matching the speed of processes • Message duplication and ordering : using message ID • Message destination : the processes simply read from and write to the stream without needing to use IP addresses and ports.

16. TCP stream communication Some outstanding issues related to stream communication: • Matching of data items : two communicating processes need to agree as to contents of the data transmitted over a stream. • Blocking : • The process that reads data may be blocked until data becomes available • The process that writes data to a stream may be blocked by the TCP flow control mechanism • Threads: when a server accepts a connection, it creates a new thread which to communicate with the new client.

17. TCP stream communication • Failure model • Checksum & sequence# for integrity. • Timeout & retransmissions for validity. • Some times TCP does not provide reliable communication . (how?) • When a connection is broken, a process will be notified if it attempts to read or write and this has the following effects: • The process cannot distinguish between network failure and process failure • The processes cannot tell whether the messages they sent have been received or not.

18. TCP stream communication • Use of TCP • HTTP • FTP • Telnet • SMTP • Java API for TCP streams • ServerSocket • Socket It provides methods such as: • getInputStream returns InputStream • getOutputStream returns OutputStream • WriteUTF of DataInputStream • ReadUTF of DataOutputStream

19. Figure 4.4UDP server repeatedly receives a request and sends it back to the client import java.net.*; import java.io.*; public class UDPServer{ public static void main(String args[]){ DatagramSocket aSocket = null; try{ aSocket = new DatagramSocket(6789); byte[] buffer = new byte[1000]; while(true){ DatagramPacket request = new DatagramPacket(buffer, buffer.length); aSocket.receive(request); DatagramPacket reply = new DatagramPacket(request.getData(), request.getLength(), request.getAddress(), request.getPort()); aSocket.send(reply); } }catch (SocketException e){System.out.println("Socket: " + e.getMessage()); }catch (IOException e) {System.out.println("IO: " + e.getMessage());} }finally {if(aSocket != null) aSocket.close();} } }

20. Figure 4.5 TCP client makes connection to server, sends request and receives reply import java.net.*; import java.io.*; public class TCPClient { public static void main (String args[]) { // arguments supply message and hostname of destination Socket s = null; try{ int serverPort = 7896; s = new Socket(args[1], serverPort); DataInputStream in = new DataInputStream( s.getInputStream()); DataOutputStream out = new DataOutputStream( s.getOutputStream()); out.writeUTF(args[0]); // UTF is a string encoding see Sn 4.3 String data = in.readUTF(); System.out.println("Received: "+ data) ; }catch (UnknownHostException e){ System.out.println("Sock:"+e.getMessage()); }catch (EOFException e){System.out.println("EOF:"+e.getMessage()); }catch (IOException e){System.out.println("IO:"+e.getMessage());} }finally {if(s!=null) try {s.close();}catch (IOException e){System.out.println("close:"+e.getMessage());}} } }

21. Figure 4.6 TCP server makes a connection for each client and then echoes the client’s request import java.net.*; import java.io.*; public class TCPServer { public static void main (String args[]) { try{ int serverPort = 7896; ServerSocket listenSocket = new ServerSocket(serverPort); while(true) { Socket clientSocket = listenSocket.accept(); Connection c = new Connection(clientSocket); } } catch(IOException e) {System.out.println("Listen :"+e.getMessage());} } } // this figure continues on the next slide

22. Figure 4.6 continued class Connection extends Thread { DataInputStream in; DataOutputStream out; Socket clientSocket; public Connection (Socket aClientSocket) { try { clientSocket = aClientSocket; in = new DataInputStream( clientSocket.getInputStream()); out =new DataOutputStream( clientSocket.getOutputStream()); this.start(); } catch(IOException e) {System.out.println("Connection:"+e.getMessage());} } public void run(){ try { // an echo server String data = in.readUTF(); out.writeUTF(data); } catch(EOFException e) {System.out.println("EOF:"+e.getMessage()); } catch(IOException e) {System.out.println("IO:"+e.getMessage());} } finally{ try {clientSocket.close();}catch (IOException e){/*close failed*/}} } }

23. External data representation and marshalling • Motivation: • Different data types • Different floating-point representations • Big-endian order • Little-endian order • The set of codes used to represents character: • ASCII • Unicode standard • Methods: • Agreed external format • Sender format + indication

24. External data representation and marshalling • External data representation: An agreed standard for the representation of data structures and primitives values • Marshalling Is the process of taking a collection of data items and assembling them into a form suitable for transmission in a message • Unmarshalling Is the process of disassembling data items on arrival to produce an equivalent collection of data items at the destination www-01.ibm.com

27. CORBA CDR • CORBA’s Common Data Representation • CORBA CDR can represent all of the data types that can be used as arguments and returned values and these include 15 primitive types: • Short (16-bit) • Long(32-bit) • Unsigned short (32-bit) • Unsigned long(32-bit) • Float(32-bit) • Double(64-bit) • Char(8-bit) • Boolean(8-bit) • Octet(8-bit) • Any ( basic or constructed types) • Composite types

28. CORBA CDR Primitive types • CDR defines a representation for big-endian and little-endian ordering • Values are transmitted in the sender’s ordering • The recipient translates if it requires a different ordering • Floating-point values follow the IEEE standards • Characters are represented by a code set agreed between client and server Constructed types • The primitive values are added to a sequence of bytes in particular order

29. T y p e Re pr e s e n ta t i o n s e q ue n ce l e n g th ( u n si g n ed l o n g ) fo ll ow ed b y el e m e nt s i n o r d e r s t ri n g l e n g th ( u n si g n ed l o n g ) fo ll ow ed b y ch a ra c te rs i n o r d e r ( ca n al so ca n h av e w i de ch a ra c te rs) a r ra y a rr ay e le m e n t s i n o r de r ( n o l en g t h s p e ci f ie d b eca us e i t is f i x e d ) s t ru ct i n t he or de r o f de c la r at i o n o f t he co mp o n e n t s e n u m e r a t e d u n s i g n e d l o n g ( t h e v a l ue s a re s pe c i f ie d b y t he o r de r d ec l ar e d ) u ni o n t y p e ta g f o l l o we d b y t h e s el e cte d m e mb er Figure 4.7CORBA CDR for constructed types

30. notes index in on representation sequence of bytes 4 bytes length of string 5 0–3 "Smit" 4–7 ‘Smith’ "h___" 8–11 12–15 6 length of string "Lond" 16–19 ‘London’ "on__" 20-23 1934 24–27 unsigned long The flattened form represents a Person struct with value: {‘Smith’, ‘London’, 1934} Figure 4.8CORBA CDR message

31. CORBA CDR • The type of a data items is not given with the data representation in the message ( why?) • Marshalling in CORBA: • It can be generated automatically from the specification of the data types • The types are described in CORBA IDL (interface definition language ) Struct Prerson { string name; string place; unsigned long year; };

32. Java • Java object serialization • Serialization: the activity of flattening an object or a connected set of objects into a serial form that is suitable for storing on disk or transmitting in a message • Deserialization: restoring the state of an object or a set of objects from their serialized form. • The information about a class consists of the name & the version • Handle: is a reference to an object within serialized form • Serialization procedure must ensure that: • There is a 1-1 correspondence between object references and handles • Each object is written once only

33. Explanation Serialized values Person 8-byte version number h0 class name, version number java.lang.String java.lang.String number, type and name of int year 3 name: place: instance variables 1934 5 Smith 6 London h1 values of instance variables The true serialized form contains additional type markers; h0 and h1 are handles Figure 4.9Indication of Java serialized form

34. Java (con.) • The use of reflection: • Reflection: • It is the ability to Enquire about the properties of a class, such as the names and types of the instance variables and methods. • It enables classes to be created from their names • It enables a constructor with given argument types to be created for a given class • By using reflection, there is no need to generate special marshalling functions for each type of object

35. Java (con.) • In Java: • Java object serialization uses reflection to find out the class name of the object to be serialized and the names, types and values of the instance variables • For deserialization, the class name in the serialized form is used to create a class. This is then used to create a new constructor with argument types corresponding to these specified in the serialized form. Finally, the new constructor is used to create a new object with instance variables whose values are read from the serialized form.

36. XML • Extensible markup language: • It was defined by (W3C) for general use on the web. • It’s term refers to a textual encoding. • It was derived from SGML • It was designed for written structured documents for the web. • XML data items are tagged with ‘markup’ strings • The tags are used to describe the logical structure of the data and to associate attribute-value pairs with logical structures. • The tags relate to the structure of the text that they enclose.

37. XML • XML is used to enable clients: • to communicate with web services • For defining the interfaces and other properties and retrieval systems • XML is readable on any computer. • The use of XML includes : • The specification of user interfaces • The encoding of configuration files in operating systems. • XML is extensible because the users can defined their tags • If an XML document is intended to be used by more than one application, then the names of tags must be agreed between them (e.g SOAP message) • XML is used by multiple applications for different purposes. So, it uses namespaces to define the meaning of the tags.

38. XML & HTML

39. XML advantages and disadvantages Advantages • The use of user- defined tags • The use of namespaces • Textual XML documents: • Readable • independent Disadvantages • Long messages • Long process and transmission time • More space to store ( how could the problem be solved?)

40. Figure 4.10 XML definition of the Person structure <person id="123456789"> <name>Smith</name> <place>London</place> <year>1934</year> <!-- a comment --> </person >

41. XML (con.) • XML elements and attributes • Elements: • An element in XML consist of a portion of character data surrounded by matching start and end tags. • One element can enclose another element. (what is the benefit?) • An empty tag has no content and is terminated with /> • Attributes: • The start tag may include pairs of associated attribute names and values such as id=“123456789” • Multiple attribute values are separated by spaces. (how to choose element or attribute?)

42. XML (con.) • Names: • They generally start with a letter but can also start with an underline or a colon. • Letters are case-sensitive • Names that start with xml are reserved. • Binary data: • Encrypted elements can be represented in base64 notation using only the alphanumeric characters together with +,/and= which has a special meaning.

43. XML (con.) • Parsing and well-formed documents • Structure rules: • Each start tag has a matching end tag. • All tags are correctly nested • Every XML document must have a single root element. • Parsing: • parser is easy to be implemented if we follow structure rules. • When parser reads an XML document that is not well formed it will report a fatal error. • XML parsers normally parse the contents of elements (why?) • Every XML document must have a prolog as its first line which must at least specify the version of XML

44. XML (con.) • XML namespaces • XML namespace is a set of names for a collection of elements types and attributes, that is referenced by a URL • An XML namespace can be used by any other XML document • Any element that makes a use of an XML namespace can specify that namespace as an attribute called xmlns

45. Figure 4.11 Illustration of the use of a namespace in the Person structure <person pers:id="123456789" xmlns:pers = "http://www.cdk4.net/person"> <pers:name> Smith </pers:name> <pers:place> London </pers:place > <pers:year> 1934 </pers:year> </person>

46. XML (con.) • XML schemas It defines the elements and attributes that can appear in a document It defines how the elements are nested It defines the order and the number of elements, whether an element is empty or can include text • APIs for accessing XML XML parser and generators are available for most commonly used programming languages. ( e.g. marshaling and unmarshaling in Java)

47. Figure 4.12 An XML schema for the Person structure <xsd:schema xmlns:xsd = URL of XML schema definitions > <xsd:element name= "person" type ="personType" /> <xsd:complexType name="personType"> <xsd:sequence> <xsd:element name = "name" type="xs:string"/> <xsd:element name = "place" type="xs:string"/> <xsd:element name = "year" type="xs:positiveInteger"/> </xsd:sequence> <xsd:attribute name= "id" type = "xs:positiveInteger"/> </xsd:complexType> </xsd:schema>

48. Remote object reference • Remote object references Is an identifier for a remote object that is valid throughout a distributed system. It is passed in the invocation message to specify which object is to be invoked. It must be unique over space and time. It must no be reused if the remote object is deleted. ( error message must be produced)

49. 32 bits 32 bits 32 bits 32 bits interface of Internet address port number time object number remote object Figure 4.13Representation of a remote object reference

50. Client-server communication This form of communication is designed to support the roles and message exchanges in typical client-server interactions. In normal case it is: • Synchronous • Reliable • The request-replay protocol