1 / 104

Socket-based Client-Server Application

Socket-based Client-Server Application. Client-Server application architecture Choosing services – Connectionless atau Connection-oriented. Evolution of Application Architecture. 3-tier Client-server application architecture. Internet Protocol and Network Application.

Télécharger la présentation

Socket-based Client-Server Application

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Socket-based Client-Server Application Client-Server application architecture Choosing services – Connectionless atau Connection-oriented norly@ftsm.ukm.my

  2. Evolution of Application Architecture norly@ftsm.ukm.my

  3. 3-tier Client-server application architecture norly@ftsm.ukm.my

  4. Internet Protocol and Network Application • Internet protocol supports: • General-purpose service for reliable data transmission • Mechanism for connecting hosts • Network application programs: • Use Internet Protocol to connect to other application • Provide user-level services norly@ftsm.ukm.my

  5. Client-Server Model • Server Application acts as a “listener” • Waits for incoming messages • Executes services • Returns the results/outcomes • Client Application makes connection • Sends messages to the server • Waits for response norly@ftsm.ukm.my

  6. Features of a Client • An application program • Becomes a client when a network service is needed • It can also executes other calculation • Is directly created by the users • Is executed locally by at the users’ computer • Initiates connection to a server • Able to access various services (at a given time) • Does not require a special device or operating system norly@ftsm.ukm.my

  7. Features of a Server • Special-purpose application for providing a network service • Is executed on a remote computer (usually is centralised and shared) • Waits and receives request for services from the clients • Requires high-performance device and operating system norly@ftsm.ukm.my

  8. Transport Protocol and Client-Server • Client and server exchange messages via transport protocol such as TCP or UDP • Both client and server must have the same protocol stack and both interact with the transport layer norly@ftsm.ukm.my

  9. Transport Protocol and Client-Server norly@ftsm.ukm.my

  10. Several Services on a Server norly@ftsm.ukm.my

  11. Identifying a Service • Every service has a unique identifier which is used by the client and server • Example - TCP uses port number protocol (port_num) as identifier • Server is registered under a specific port number for a service • Client asks for a session with the port number for the service • Every transport session contains 2 unique indentifier • (IP address, port number) at the server • (IP address, port number) at the client norly@ftsm.ukm.my

  12. Connection-oriented and Connectionless Transport Protocol • Which one should be chosen? • UDP - connectionless • Client builds a message • Client sends the message to a server • The server responds • Message must be loaded into a UDP datagram • TCP - connection-oriented • Client makes a connection to a server • Client and server exchange messages • Client terminates the connection norly@ftsm.ukm.my

  13. UDP • UDP is a connectionless transport protocol, i.e. it doesn't guarantee either packet delivery or that packets arrive in sequential order. • With UDP, bytes of data are grouped together in discrete packets which are sent over the network. norly@ftsm.ukm.my

  14. Packets may travel along different paths depending on the state of the network. • No two packets are guaranteed the same route. • Each packet has a time-to-live (TTL) counter, which is updated when it is routed along to the next point in the network. When the timer expires, it will be discarded, and the recipient will not be notified. norly@ftsm.ukm.my

  15. If a packet does arrive, it will always arrive intact. Packets that are corrupt or only partially delivered are discarded. norly@ftsm.ukm.my

  16. Advantages of UDP • UDP communication can be more efficient than guaranteed-delivery data streams. • Unlike TCP streams, which establish a connection, UDP causes fewer overheads. • Real-time applications that demand up-to-the-second or better performance may be candidates for UDP, as there are fewer delays due to error checking and flow control of TCP. norly@ftsm.ukm.my

  17. UDP sockets can receive data from more than one host machine. • Some network protocols specify UDP as the transport mechanism. norly@ftsm.ukm.my

  18. Java Support for UDP • Two classes are provided: • DatagramPacket class (java.net) • DatagramSocket class (java.net) norly@ftsm.ukm.my

  19. DatagramPacket Class • A DatagramPacket object represents a data packet intended for transmission using UDP. • It contains addressing information such as an IP address and a port. • When a DatagramPacket is read from a UDP socket, the IP address/port number of the packet represents the address/port number of the sender. norly@ftsm.ukm.my

  20. When a DatagramPacket is used to send a UDP packet, the IP address/port represents the address/port of the recipient. DatagramPacket IP address (java.net.InetAddr) Port address (int) Packet data (byte[]) norly@ftsm.ukm.my

  21. Creating a DatagramPacket • Constructor to use for creating a DatagramPacket for receiving incoming UDP packets: DatagramPacket(byte[] buffer, int length) • Example: DatagramPacket packet; packet = new DatagramPacket(new byte[256], 256); norly@ftsm.ukm.my

  22. Constructor to use for sending a DatagramPacket to a remote machine DatagramPacket(byte[] buffer, int length, InetAddress dest_addr, int dest_port) • Example: DatagramPacket packet; InetAddress addr; addr = InetAddress.getByName("192.168.0.1"); packet = new DatagramPacket(new byte[128], 128,addr, 2000); norly@ftsm.ukm.my

  23. DatagramPacket Methods • InetAddress getAddress() • byte[] getData() • int getLength() • int getPort() • void setAddress(InetAddress addr) • void setData(byte[] buffer) • void setLength(int length) • void setPort(int port) norly@ftsm.ukm.my

  24. DatagramSocket Class • The DatagramSocket class provides access to a UDP socket, which allows UDP packets to be sent and received. • The same DatagramSocket can be used to receive as well as to send packets. • Read operations are blocking - i.e. the application will continue to wait until a packet arrives. norly@ftsm.ukm.my

  25. Each DatagramSocket binds to a port on the local machine. The port number need not match the port number of the remote machine. • If the application is a UDP server, it will usually bind to a specific port number. norly@ftsm.ukm.my

  26. Creating a DatagramSocket • Constructor to use for creating a client DatagramSocket: DatagramSocket() throws java.net.SocketException • Example: DatagramSocket socket; try { socket = new DatagramSocket(); } catch (SocketException exception) { … } norly@ftsm.ukm.my

  27. Constructor to use for creating a server DatagramSocket: DatagramSocket(int port) throws java.net.SocketException • Example: DatagramSocket socket; try { socket = new DatagramSocket(2000); } catch (SocketException exception) { … } norly@ftsm.ukm.my

  28. DatagramSocket Methods • void close() • void connect(InetAddress r_addr, int r_port) • void disconnect() • InetAddress getInetAddress() • int getPort() • InetAddress getLocalAddress() • int getLocalPort() • int getReceiveBufferSize() throws java.net.SocketException norly@ftsm.ukm.my

  29. int getSendBufferSize() throws java.net.SocketException • int getSoTimeout() throws java.net.SocketException • void receive(DatagramPacket packet) throws java.io.IOException • void send(DatagramPacket packet) throws java.io.IOException • int setReceiveBufferSize(int length) throws java.net.SocketException • int setSendBufferSize(int length) throws java.net.SocketException • void setSoTimeout(int duration) throws java.net.SocketException norly@ftsm.ukm.my

  30. Listening for UDP Packets • Before an application can read UDP packets, it must • bind a socket to a local UDP port using DatagramSocket • create a DatagramPacket that will contain the data. norly@ftsm.ukm.my

  31. Packet Reads packets DatagramSocket DatagramPacket Translates packets Into a DatagramPacket UDP application norly@ftsm.ukm.my

  32. The following code illustrates the process for reading UDP packets. DatagramPacket packet; DatagramSocket socket; packet = new DatagramPacket(new byte[256], 256); socket = new DatagramSocket(2000); boolean finished = false; while (!finished) { socket.receive(packet); // process the packet } socket.close(); norly@ftsm.ukm.my

  33. ByteArrayInputStream • Java I/O streams are usually used to access the contents of the byte array in a DatagramPacket. See example later. DataInputStream DatagramPacket IP address (java.net.InetAddr) Port address (int) Packet data (byte[]) UDP application norly@ftsm.ukm.my

  34. Sending UDP Packets • When sending a packet, the application must create a DatagramPacket that will contain the data. The address and port information must also be set. • When the packet is ready for transmission, the send method of DatagramSocket should be invoked. norly@ftsm.ukm.my

  35. DatagramSocket Binds to a UDP port UDP application Send DatagramPacket using DatagramSocket Packet Constructs packet DatagramPacket norly@ftsm.ukm.my

  36. DatagramPacket packet; DatagramSocket socket; packet = new DatagramPacket(new byte[256], 256); socket = new DatagramSocket(2000); packet.setAddress(…); packet.setPort(2000); boolean finished = false; while (!finished) { // write data to packet buffer socket.send(packet); … } socket.close(); • The following code illustrates the process for sending UDP packets. norly@ftsm.ukm.my

  37. User Datagram Protocol Example • Run receiving application java PacketReceiveDemo • Run sending application java PacketSendDemo norly@ftsm.ukm.my

  38. norly@ftsm.ukm.my

  39. norly@ftsm.ukm.my

  40. norly@ftsm.ukm.my

  41. norly@ftsm.ukm.my

  42. DatagramPacket PacketSendDemo PrintStream print(str) ByteArrayOutputStream toByteArray() send(packet) DatagramSocket norly@ftsm.ukm.my

  43. DatagramPacket DatagramSocket receive(packet) ByteArrayInputStream getData() read() PacketReceiveDemo norly@ftsm.ukm.my

  44. Building a UDP Client/Server • Run echo server java EchoServer • Run echo client java EchoClient norly@ftsm.ukm.my

  45. Algorithm for Echo Server • Create socket • Create an empty packet • Repeat the following forever • Wait for a packet • Send the packet back to sender norly@ftsm.ukm.my

  46. Algorithm for Echo Client • Create socket • Set timeout value for socket • Repeat the following ten times • Create the message to be sent • Create packet containing the message as well as the destination IP and the port • Send the packet through socket • Wait for packet from receiver through socket or timeout • if packet received • Create an input stream to access data in the packet • Use the input stream to read the data and then display it on the screen. • Sleep for a second norly@ftsm.ukm.my

  47. Overcoming UDP Limitations • UDP limitations: • Lack of Guaranteed Delivery • Lack of Guaranteed Packet Sequencing • Lack of Flow Control norly@ftsm.ukm.my

  48. Lack of Guaranteed Delivery • Packets sent via UDP may become lost in transit. • UDP packets can also become damaged or lost. • For some applications, the loss of individual packets may not have a noticeable effect (e.g. video streams). • For other applications, loss of packets is not acceptable (e.g. file transfers). norly@ftsm.ukm.my

  49. If guaranteed delivery is required, • avoid packet-based communication, and use a more suitable transport mechanism (e.g. TCP). • send acknowledgement to sender after receiving packets. norly@ftsm.ukm.my

  50. Lack of Guaranteed Packet Sequencing • Applications that require sequential access to data should include a sequence number in the contents of a datagram packet. • This enables detection of duplicate packets and also missing packets. norly@ftsm.ukm.my

More Related