![DatagramPacket
28
The class DatagramPacket contains several constructors that
can be used for creating packet object.
One of them is:
DatagramPacket(byte[] buf, int length, InetAddress address, int port);
The key methods of DatagramPacket class are:
byte[] getData() Returns the data buffer.
int getLength() Returns the length of the data to be sent or
the length of the data received.
void setData(byte[] buf) Sets the data buffer for this packet.
void setLength(int length) Sets the length for this packet.](https://image.slidesharecdn.com/lect4-250328080030-69d96e93/85/COMPLEXITY-CHAPTER-4-LECTURE-FOR-FOURTH-YEAR-pptx-28-320.jpg)
![Registering the hello world server
class HelloServer {
public static void main (String[] argv) {
try {
Naming.rebind("rmi://localhost/HelloServer",
new Hello("Hello, world!"));
System.out.println("Hello Server is ready.");
}
catch (Exception e) {
System.out.println("Hello Server failed: " + e);
}
}
}
48](https://image.slidesharecdn.com/lect4-250328080030-69d96e93/85/COMPLEXITY-CHAPTER-4-LECTURE-FOR-FOURTH-YEAR-pptx-48-320.jpg)
![The hello world client program
class HelloClient {
public static void main (String[] args) {
HelloInterface hello;
String name = "rmi://localhost/HelloServer";
try {
hello = (HelloInterface)Naming.lookup(name);
System.out.println(hello.say());
}
catch (Exception e) {
System.out.println("HelloClient exception: " + e);
}
}
}
49](https://image.slidesharecdn.com/lect4-250328080030-69d96e93/85/COMPLEXITY-CHAPTER-4-LECTURE-FOR-FOURTH-YEAR-pptx-49-320.jpg)
COMPLEXITY CHAPTER 4 LECTURE FOR FOURTH YEAR .pptx
- 2. Fundamentals Inter-process communication is at the heart of all distributed systems. As such systems are made up of several processes running on different machines How processes on different machines can exchange information? Given, these processes do not have shared memory and clock 1. Traditional approach Use low-level message-passing primitives offered by the transport layer (send and receive). However, these are difficult to use for large-scale distributed Apps. 2. Use middleware systems that offer a higher level of abstraction Easier to express communication between processes 2
- 3. Layered protocols 3 Communication often requires agreement at different levels From the low-level details of bit transmission to the high-level details of how information is to be expressed. Thus, communication protocols are often organized as layered protocols Examples Open Systems Interconnection Reference Model (ISO OSI) TCP/IP
- 4. Layered Protocols (1) Figure 4-1. Layers, interfaces, and protocols in the OSI model. 4
- 5. Layered protocol Each layer deals with one specific aspect of the communication. Each layer provides an interface to the one above it. When process A on machine 1 wants to communicate with process B on machine 2 It builds a message and passes the message to the application layer on its machine. Application layer add a header information and pass it to the next layer (presentation layer) Every layer does same up until data link layer Finally, the physical layer sends out the packet When the message arrives at machine 2, it is passed upward, with each layer stripping off and examining its own header. 5
- 6. Layered Protocols (2) Every layer adds a header to the front of the message But some put trailer either Figure 4-2.A typical message as it appears on the network. 6
- 7. Low level layers Physical layer: contains the specification and implementation of bits, and their transmission between sender and receiver Data link layer: prescribes the transmission of a series of bits into a frame to allow for error and flow control Network layer: describes how packets in a network of computers are to be routed. Note: For many distributed systems, the lowest-level interface is that of the network layer. 7
- 8. Transport Layer The transport layer provides the actual communication facilities for most distributed systems. Turn the underlying network into something that a developer can easily use Example transport layer protocols TCP: connection-oriented protocol, reliable communication UDP: connectionless protocol, Unreliable, Application has to handle error 8
- 9. Higher-Level Protocols OSI has three additional layers above transport layer In TCP/IP suite, everything above transport layer is grouped together Session layer is an enhanced version of transport layer Provides dialog control, e.g., keeps track of who is talking and provide synchronization Presentation layer is mainly concerned with the meaning of the bits Application layer : Protocols for things like mail, file transfer, communication terminals. Examples: FTP (File Transfer Protocol) HTTP (HyperText Transfer Protocol) 9
- 10. Drawbacks of OSI reference model Focus on message-passing only Contained often unneeded or unwanted functionality Session and presentation layers are not effectively used and in practice only the application layer is ever used. 10
- 11. Middleware Middleware communication protocols support high- level communication services. Middleware is invented to provide common services and protocols that can be used by many different applications A rich set of communication protocols (Un)Marshaling of data Naming protocols, to allow easy sharing of resources Security protocols for secure communication Scaling mechanisms, such as for replication and caching 11
- 12. Middleware Protocols The session and presentation layer have been replaced by a single middleware layer that contains application-independent protocols. Supports Communication protocols, Naming protocols, Security protocols, Scaling mechanisms, such as replication and caching Figure 4-3.An adapted reference model for networked communication. 12
- 13. Types of Communications Persistent communication A message is stored at a communication server as long as it takes to deliver it. The sending application can exit after submitting The receiving application does not have to be active Transient communication-message is stored as long as the sending/receiving is executing Comm. server discards message when it cannot be delivered at the next server, or at the receiver. Asynchronous communication Sender continues immediately after submitting a message Synchronous communication Sender will wait until it is certain that the message is received 13
- 14. Communication in Client/Server 14 Client/Server computing is generally based on a model of transient synchronous communication: Client and server have to be active at time of communication Client issues request and blocks until it receives reply Server essentially waits only for incoming requests, and subsequently processes them Drawbacks synchronous communication Client cannot do any other work while waiting for reply Failures have to be handled immediately: the client is waiting The model may simply not be appropriate (mail, news)
- 15. Message-oriented middleware(MoM) 15 Aims at high-level persistent asynchronous communication: Processes send each other messages, which are queued Sender need not wait for immediate reply, but can do other things Middleware often ensures fault tolerance
- 16. Remote procedure call RPC is a normal looking procedure call processed on a remote machine Mitivations Application developers are familiar with simple procedure model Well-engineered procedures operate in isolation (black box) There is no fundamental reason not to execute procedures on separate machine Conclusion Communication between caller & callee can be hidden by using procedure-call mechanism. 16
- 17. RPC between Client and Server RPC achieves transparency through client and server stubs client stub packs parameters into a message to the server, and inspect the result from server and copy it to the caller Server stub unpacks parameters, calls the procedure, and packs the result to the client Figure 4-4. Principle of RPC between a client and server program. 17
- 18. RPC steps 18
- 19. RPC Steps 1) The client procedure calls the client stub in the normal way. 2) The client stub builds a message and calls the local OS. 3) The client’s OS sends the message to the remote OS. 4) The remote OS gives the message to the server stub. 5) The server stub unpacks the parameters and calls the server. 6) The server does the work and returns the result to the stub. 7) The server stub packs it in a message and calls its local OS. 8) The server’s OS sends the message to the client’s OS. 9) The client’s OS gives the message to the client stub. 10) The stub unpacks the result and returns to the client. 19
- 20. Case study on Inter-process communication 20
- 21. Characteristics of IPC 21 Message Passing Primitives: Send, Receive ƒ Message = <Destination, Content> ƒ Destination = <Network address, Port> ƒ Port = destination within a host that identifies a receiving process Ports are uniquely identified by their port number Hosts are uniquely identified Some port numbers (0 to1023) are assigned for well known services SMTP 25 Domain Name Server 42 HTTP 80 So don’t use them unless you are a power user
- 22. Sockets 22 One of the mechanisms for IPC is Socket Socket is End point for inter-process communication Characteristics Message transmission is done between sockets A socket is associated with either UDP or TCP Sockets are bound to ports One process can use many ports Processes don’t share sockets Implementations Originally by Unix, but available in Linux,Windows OSes APIs in programming languages (e.g., java.net)
- 23. Communication Primitives 23 Send- ƒ send a message to a socket associated to a process Receive – ƒ receive a message on a socket Broadcast/Multicast – ƒ send to all processes/all processes in a group
- 24. Send in Asynchronous Communication 24 Characteristics ƒ Non-blocking(process continues after the message sent out) Buffering needed (at receive end) Mostly used with blocking receive It is efficient implementation Problems ƒ buffer overflow (messages might exceed buffer size) Error reporting (difficult to match error with message) This Maps closely onto connectionless service (UDP)
- 25. Send in Synchronous Communication 25 Characteristics ƒ blocking(sender suspended until message received) Synchronization point for sender & receiver Easier to understand Problems ƒ Failure and indefinite delay causes indefinite blocking (use timeout) Multicasting / broadcasting not supported implementation more complex Maps closely onto connection-oriented service (TCP)
- 26. APIs for UDP and TCP 26 Java provides APIs for UDP and TCP via its networking package (java.net) Communication between processes on different machines require to know IP address of the nodes Java API for Internet Addresses (used by both UDP and TCP) Class InetAddress Represents an IP address InetAddress serverAdd = InetAddress.getByName(“www.kmu.edu.et”); throws UnknownHostException Returns InetAddress of the hostname (“www.kmu.edu.et”); encapsulates details of IP address (4 bytes for IPv4 and 16 bytes for IPv6)
- 27. UDP API 27 Payload/message (Array of Bytes) Payload length Destination IP address Destination Port# UDP sends message in the form of packet Structure of UDP packets DatagramPacket and DatagramSocket are the two classes used by UDP Class DatagramPacket packets may be transmitted between sockets packets are truncated if too long provides getData, getPort, getAddress, getLength methods
- 28. DatagramPacket 28 The class DatagramPacket contains several constructors that can be used for creating packet object. One of them is: DatagramPacket(byte[] buf, int length, InetAddress address, int port); The key methods of DatagramPacket class are: byte[] getData() Returns the data buffer. int getLength() Returns the length of the data to be sent or the length of the data received. void setData(byte[] buf) Sets the data buffer for this packet. void setLength(int length) Sets the length for this packet.
- 29. DatagramSocket 29 The class DatagramSocket supports various methods that can be used for transmitting or receiving data/datagram over the network. The two key methods are: void send(DatagramPacket p) Sends a datagram packet from this socket. non-blocking void receive(DatagramPacket p) Receives a datagram packet from this socket. Blocking DatagramSocket constructors DatagramSocket () – bounds to any free port DatagramSocket (InetAddress, Port) throws SocketException if port unknown or in use
- 30. Java API for TCP Socket 30 The two key classes from the java.net package used in creation of server and client programs are: ServerSocket - is used to listen for client request Socket – is used to exchange data between client and server
- 31. Simple Server Program in Java 31 A The steps for creating a simple server program are: 1. Open the Server Socket: ServerSocket server = new ServerSocket( PORT ); 2.Wait for the Client Request: Socket client = server.accept(); 3. Create I/O streams for communicating to the client DataInputStream is = new DataInputStream(client.getInputStream()); DataOutputStream os = new DataOutputStream(client.getOutputStream()); 4. Perform communication with client Receive from client: String line = is.readLine(); Send to client: os.writeBytes(“Hellon”); 5. Close socket: client.close();
- 32. A simple Client Program in Java 32 The steps for creating a simple client program are: 1. Create a Socket Object: Socket client = new Socket(server, port_id); 2. Create I/O streams for communicating with the server. is = new DataInputStream(client.getInputStream()); os = new DataOutputStream(client.getOutputStream()); 3. Perform I/O or communication with the server: Receive data from the server: String line = is.readLine(); Send data to the server: os.writeBytes(“Hellon”); 4. Close the socket when done: client.close();
- 33. Remote Method Invocation (RMI)
- 34. “The network is the computer”* Consider the following program organization: If the network is the computer, we ought to be able to put the two classes on different computers SomeClass AnotherClass method call returned object RMI is one technology that makes this possible computer 1 computer 2 34
- 35. RMI and other technologies CORBA (Common Object Request Broker Architecture) has long been king CORBA supports object transmission between virtually any languages Objects have to be described in IDL (Interface Definition Language), which looks a lot like C++ data definitions CORBA is complex and flaky Microsoft supported CORBA, then COM, now .NET RMI is purely Java-specific Java to Java communications only As a result, RMI is much simpler than CORBA 35
- 36. What is needed for RMI Java makes RMI (Remote Method Invocation) fairly easy, but there are some extra steps To send a message to a remote “server object,” The “client object” has to find the object Do this by looking it up in a registry The client object then has to marshal the parameters (prepare them for transmission) Java requires Serializable parameters The server object has to unmarshal its parameters, do its computation, and marshal its response The client object has to unmarshal the response Much of this is done for you by special software 36
- 37. Terminology A remote object is an object on another computer The client object is the object making the request (sending a message to the other object) The server object is the object receiving the request As usual,“client” and “server” can easily trade roles (each can make requests of the other) The rmiregistry is a special server that looks up objects by name Hopefully, the name is unique! rmic is a special compiler for creating stub (client) and skeleton (server) classes 37
- 38. Processes For RMI, you need to be running three processes The Client The Server The Object Registry, rmiregistry, which is like a DNS service for objects You also need TCP/IP active 38
- 39. Interfaces Interfaces define behavior Classes define implementation Therefore, In order to use a remote object, the client must know its behavior (interface), but does not need to know its implementation (class) In order to provide an object, the server must know both its interface (behavior) and its class (implementation) In short, The interface must be available to both client and server The class should only be on the server 39
- 40. Classes A Remote class is one whose instances can be accessed remotely On the computer where it is defined, instances of this class can be accessed just like any other object On other computers, the remote object can be accessed via object handles A Serializable class is one whose instances can be marshaled (turned into a linear sequence of bits) Serializable objects can be transmitted from one computer to another 40
- 41. Conditions for serializability If an object is to be serialized: The class must be declared as public The class must implement Serializable The class must have a no-argument constructor All fields of the class must be serializable: either primitive types or serializable objects 41
- 42. Remote interfaces and class A Remote class has two parts: The interface (used by both client and server): Must be public Must extend the interface java.rmi.Remote Every method in the interface must declare that it throws java.rmi.RemoteException (other exceptions may also be thrown) The server: Must implement a Remote interface Should extend java.rmi.server.UnicastRemoteObject May have locally accessible methods that are not in its Remote interface 42
- 43. Remote vs. Serializable A Remote object lives on another computer (such as the Server) You can send messages to a Remote object and get responses back from the object All you need to know about the Remote object is its interface Remote objects don’t pose much of a security issue You can transmit a copy of a Serializable object between computers The receiving object needs to know how the object is implemented; it needs the class as well as the interface There is a way to transmit the class definition Accepting classes does pose a security issue 43
- 44. Security It isn’t safe for the client to use somebody else’s code on some random server Your client program should use a more conservative security manager than the default System.setSecurityManager(new RMISecurityManager()); Most discussions of RMI assume you should do this on both the client and the server Unless your server also acts as a client, it isn’t really necessary on the server 44
- 45. The server class 45 The class that defines the server object should extend UnicastRemoteObject This makes a connection with exactly one other computer If you must extend some other class, you can use exportObject() instead Sun does not provide a MulticastRemoteObject class The server class needs to register its server object: String url = "rmi://" + host + ":" + port + "/" + objectName; The default port is 1099 Naming.rebind(url, object); Every remotely available method must throw a RemoteException (because connections can fail) Every remotely available method should be synchronized
- 46. Hello world server: interface import java.rmi.*; public interface HelloInterface extends Remote { public String say() throws RemoteException; } 46
- 47. Hello world server: class import java.rmi.*; import java.rmi.server.*; public class Hello extends UnicastRemoteObject implements HelloInterface { private String message; // Strings are serializable public Hello (String msg) throws RemoteException { message = msg; } public String say() throws RemoteException { return message; } } 47
- 48. Registering the hello world server class HelloServer { public static void main (String[] argv) { try { Naming.rebind("rmi://localhost/HelloServer", new Hello("Hello, world!")); System.out.println("Hello Server is ready."); } catch (Exception e) { System.out.println("Hello Server failed: " + e); } } } 48
- 49. The hello world client program class HelloClient { public static void main (String[] args) { HelloInterface hello; String name = "rmi://localhost/HelloServer"; try { hello = (HelloInterface)Naming.lookup(name); System.out.println(hello.say()); } catch (Exception e) { System.out.println("HelloClient exception: " + e); } } } 49
- 50. rmic The class that implements the remote object should be compiled as usual Then, it should be compiled with rmic: rmic Hello This will generate files Hello_Stub.class and Hello_Skel.class These classes do the actual communication The “Stub” class must be copied to the client area The “Skel” was needed in SDK 1.1 but is no longer necessary 50
- 51. Trying RMI In three different terminal windows: 1. Run the registry program: • rmiregistry 2. Run the server program: • java HelloServer 3. Run the client program: • java HelloClient If all goes well, you should get the “Hello,World!” message 51
- 52. Summary 1. Start the registry server, rmiregistry 2. Start the object server 1. The object server registers an object, with a name, with the registry server 3. Start the client 1. The client looks up the object in the registry server 4. The client makes a request 1. The request actually goes to the Stub class 2. The Stub classes on client and server talk to each other 3. The client’s Stub class returns the result 52
- 53. References Trail: RMI by Ann Wollrath and Jim Waldo http://java.sun.com/docs/books/tutorial/rmi/index.html Fundamentals of RMI Short Course by jGuru http://developer.java.sun.com/developer/onlineTraining/ rmi/RMI.html Java RMITutorial by Ken Baclawski http://www.ccs.neu.edu/home/kenb/com3337/rmi_tut.html 53
- 54. End of Lecture 4
Editor's Notes
- #3: CP/IP LayerCorresponding OSI LayersApplication LayerApplication, Presentation, SessionTransport LayerTransportInternet LayerNetworkNetwork Access LayerData Link, Physical