1 / 111

Java EE Programming

Java EE Programming. UDP & TCP Java’s RMI. Topics. Networking and Internetworking Inter-process communication Distributed objects and remote invocation UDP & TCP Java’s RMI. Networking Issues for Distributed Systems. Previous networks had to meet simple application requirements:

donm
Télécharger la présentation

Java EE Programming

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. Java EE Programming UDP & TCP Java’s RMI

  2. Topics • Networking and Internetworking • Inter-process communication • Distributed objects and remote invocation • UDP & TCP • Java’s RMI

  3. Networking Issues for Distributed Systems • Previous networks had to meet simple application requirements: • File transfer, remote login, e-mail and newsgroups • With the growth of the Internet, more stringent requirements are necessary: • New modes of use • Additional and more stringent requirements

  4. Current Networking Requirements & Terms • Performance • Speed with which individual messages can be transferred between two interconnected computers • Latency – is the delay that occurs after a send operation is executed before data starts to arrive at the destination computer (network latency) • Data transfer rate – is the speed at which data can be transferred between two computers in the network once the transmission has begun • Bits per second • Message transmission time = latency + length/data transfer rate

  5. Current Networking Requirements & Terms • Scalability • The potential future size of the Internet is commensurate with the population of the planet • Indicates size and load of the Internet • Networks must scale

  6. Current Networking Requirements & Terms • Reliability • The degree in which an application can recover from communication failures • Security • Techniques for achieving security in distributed systems • Firewalls – creates a protection boundary between an organization’s intranet and the rest of the Internet • Distributed systems need a secure network environment with end-to-end authentication, privacy, and security • Example - encryption

  7. Current Networking Requirements & Terms • Mobility • Wireless networks provide connectivity to devices such as laptops, cell phones, PDAs • Addressing and routing schemes of Internet were developed before the advent of wireless devices so are not well-adapted to their intermittent connection to many different subnets • Quality of service • Applications that transmit multimedia data require guaranteed bandwidth and latencies

  8. Current Networking Requirements & Terms • Multicasting • One-to-many communication • Needed in distributed systems

  9. Types of Networks in Distributed Systems • PAN – Personal area network • Various digital devices carried by a user are connected to a low-cost, low-energy network • LAN – Local area network • Carry messages at high speed between computers connected by a single communication medium • Twisted copper wire, coaxial cable, fiber optics • WAN – Wide area network • Carry messages a lower speeds between nodes that are often in different organizations and may be separated by large distances • Uses routers to route the messages • MAN – Metropolitan area network • High speed network installed in towns/cities for transmission of data and video • DSL and Cable modem connections

  10. Types of Networks in Distributed Systems • WLAN – Wireless local area network • Used in place of wired LANs for wireless mobile devices • IEEE 802.11 (WiFi) standard protocol • WMAN – Wireless metropolitan area network • Supercedes 802.11 • IEEE 802.16 WiMAX protocol

  11. Types of Networks in Distributed Systems • Internetworks – communication subsystem in which several networks are linked together to provide common data communication facilities • Overlay the technologies and protocols of the individual component networks and methods used for their interconnection • Needed for the development of extensible, open distributed systems • Example – Internet

  12. Example Range Bandwidth Latency (Mbps) (ms) Wired: LAN Ethernet 1-2 kms 10-1000 1-10 WAN IP routing worldwide 0.010-600 100-500 MAN ATM 250 kms 1-150 10 Internetwork Internet worldwide 0.5-600 100-500 Wireless: WPAN Bluetooth (802.15.1) 10 - 30m 0.5-2 5-20 WLAN WiFi (IEEE 802.11) 0.15-1.5 km 2-54 5-20 WMAN WiMAX (802.16) 550 km 1.5-20 5-20 WWAN GSM, 3G phone nets worldwide 0.01-02 100-500 Network performance

  13. Network Protocols • Protocol – refers to a well-known set of rules and formats to be used for communication between processes in order to perform a given task • Two parts: • a specification of the sequence of messages that must be exchanged • a specification of the format of the data in the messages

  14. Message received Message sent Layer n Layer 2 Layer 1 Communication Sender Recipient medium Conceptual Layering of Protocol Software

  15. Protocol Layers • Network software is arranged in a hierarchy of layers • Each layer presents an interface to the layers above it and below it • Sending side – each layer (except top) accepts items of data in a specified format from the layer above it and applies transformations to encapsulate the data in the format specified for that layer • Receiving side – converse transformations are applied to data items received from the layer below before being passed to layer above

  16. Encapsulation as it is applied in Layered Protocols The tags in the headers are the protocol type for the layer above, needed for the receiving protocol stack to correctly unpack the packets

  17. Protocol Suites • Complete set of protocol layers is referred to as a protocol suite or protocol stack • Reference Model for Open Systems Interconnection (OSI) • Protocol layering brings substantial benefits in simplifying and generalizing the software interfaces for access to the communication services of networks • Also carries significant performancecosts • Why do you think this is so?

  18. Protocol layers in the ISO Open Systems Interconnection (OSI) model

  19. Layer Description Examples Application Protocols that are designed to meet the communication requirements of FTP HTTP, , SMTP, specific applications, often defining the interface to a service. CORBA IIOP Presentation Protocols at this level transmit data in a network representation that is Secure Sockets independent of the representations used in individual computers, which may ( SSL),CORBA Data differ. Encryption is also performed in this layer, if required. Rep. Session At this level reliability and adaptation are performed, such as detection of failures and automatic recovery. Transport This is the lowest level at which messages (rather than packets) are handled. TCP, UDP Messages are addressed to communication ports attached to processes, Protocols in this layer may be connection-oriented or connectionless. Network Transfers data packets between computers in a specific network. In a WAN IP, ATM virtual or an internetwork this involves the generation of a route passing through circuits routers. In a single LAN no routing is required. Data link Responsible for transmission of packets between nodes that are directly Ethernet MAC, connected by a physical link. In a WAN transmission is between pairs of ATM cell transfer, routers or between routers and hosts. In a LAN it is between any pair of hosts. PPP Physical The circuits and hardware that drive the network. It transmits sequences of Ethernet base- band binary data by analogue signalling, using amplitude or frequency modulation signalling, ISDN of electrical signals (on cable circuits), light signals (on fibre optic circuits) or other electromagnetic signals (on radio and microwave circuits). OSI Protocol Summary

  20. Internet Protocols • TCP/IP – Transmission Control Protocol/Internet Protocol • Grown now to over 60 million hosts • Example application services & protocols based in TCP/IP: • Web (HTTP) • email (SMTP, POP) • netnews (NNTP) • file transfer (FTP) • Telnet (telnet)

  21. Message Layers Application Messages (UDP) or Streams (TCP) Transport UDP or TCP packets Internet IP datagrams Network interface Network-specific frames Underlying network TCP/IP Layers

  22. TCP/IP Layers • Two transport protocols • TCP – reliable connection-oriented protocol • UDP – datagram protocol that does not guarantee reliable transmission • Internet Protocol (IP) is the underlying ‘network’ protocol • IP datagrams provide the basic transmission mechanism for the Internet and other TCP/IP networks • Internet protocols are usually layered over other network technologies • i.e, Ethernet

  23. Application message port TCP header TCP IP header Ethernet header IP Ethernet frame Encapsulation in a message transmitted via TCP over an Ethernet

  24. The programmer's conceptual view of a TCP/IP Internet

  25. IP Addressing • Scheme chosen for naming and addressing hosts and routing IP packets to their destination • Assigns an IP address to each host in the Internet – a 32-bit numeric identifier containing: • network identifier – uniquely identifies one of the subnetworks in the Internet • host identifier – uniquely identifies the host’s connection to that network

  26. Internet Address Space Class A is reserved for very large networks (i.e.,US NSFNet) Class B is used for organizations that operate networks likely to contain more than 255 computers Class C is allocated to all other network operators Class D is reserved for Internet multittask communication Class E contains a range of unallocated addresses – reserved for future use

  27. TCP and UDP • Provide the communication capabilities of the Internet in a form that is useful for application programs • TCP and UDP are transport protocols and must provide process-to-process communication • Accomplished by using ports • Port numbers are used for addressing messages to processes within a particular computer and are only valid for that computer • Once an IP packet has been delivered to its destination host, the TCP- or UDP-layer software dispatches it to a process via a specific port at that host

  28. UDP Features • UDP datagram is encapsulated inside an IP packet • Short header with source and destination port numbers, length field and a checksum • UDP does NOT guarantee delivery • Adds no additional reliability mechanisms except for checksum (which is optional) • Use is restricted to applications and services that do not require reliable delivery of single or multiple messages

  29. TCP Features • TCP provides a much more sophisticated transport service • Provides reliable delivery of a long sequences of bytes • Guarantees the delivery to the receiving process of all the data presented to the TCP software by the sending process in the same order • Provides retransmission if necessary • Done when the it does not receive an acknowledgement from the receiving process within a specified timeout

  30. Middleware • Looking at IPC from the Programmer’s point of view • Remote Method Invocation (RMI) • Remote Procedure Call (RPC)

  31. Interprocess Communication(IPC) • Distributed Systems • rely on exchanging data and achieving synchronization amongst autonomous distributed processes • Inter process communication (IPC) • shared variables • message passing • message passing in concurrent programming languages • language extensions • API calls • Principles of IPC • (Concurrent programs: collections of two or more sequential programs executing concurrently • Concurrent processes: collection of two or more sequential programs in operation, executing concurrently

  32. IPC Characteristics • Message passing between pairs of processes can be supported by two message communication operations: • send • receive • In order for one process to communicate with another, one process sends a message (sequence of bytes) to a destination and another process at the destination receives the message

  33. Types of Communication • Synchronous • Sending and receiving process synchronize at every message • Both send and receive are blocking operations • Whenever a send is issued, the sending process (or thread) is blocked until the corresponding receive is issued • Whenever a receive is issued, the process (or thread) blocks until a message arrives

  34. Types of Communication • Asynchronous • Send is non-blocking – sending process is allowed to proceed as soon as the message has been copied to a local buffer • Receive operation can have blocking and non-blocking variants • Non-blocking – receiving process proceeds with its program after issuing a receive operation which provides a buffer to be filled in the background • Must separately receive notification that is buffer has been filled by polling or interrupt • Today’s systems do not generally provide the non-blocking form of receive because it adds complexity to the application

  35. Sockets • Both UDP and TCP use socket abstraction • Provides an endpoint for communication between processes • Originated from BSD UNIX but in all Unix flavors (i.e., Linux) • IPC consists of transmitting a message between a socket in one process and a socket in another process

  36. agreed port any port socket socket message client server other ports Internet address = 138.37.94.248 Internet address = 138.37.88.249 Sockets and Ports

  37. Sockets and Ports • For a process to receive messages, its socket must be bound to a local port and one of the Internet addresses of the computer on which it runs • Messages sent to a particular Internet address and port number can be received only by a process whose socket is associated with that Internet address and port number • Processes may use the same socket for sending and receiving messages

  38. Moving from Interprocess to Distributed Communication • A distributed system breaks up a previously monolithic application into different components and then proceeds to place them on different systems (i.e. tiers). • We are decoupling the consumer and the supplier; we are spreading the activities of an application onto team players (systems)

  39. Moving from Interprocess to Distributed Communication • Analogy • Let us imagine for a moment a small business run by a single entrepreneur. This one person, Suzette Sellers, does everything, much like a monolithic application. She sells to customers, orders new product, manages the books, pays the bills, and does anything else. Internally, she has compartmentalized her job function (much like we program in a modular fashion): selling, ordering, and administration. There is no overhead associated with external communication she does everything. • When her store becomes successful, she finds that she simply cannot do it all and requires assistance. Suzette hires Henry Helpers, a capable and likeable chap. This is now similar to our two-tier architecture. Because Suzette and Henry work in the same physical location, this is a logical two-tier system. Communication is quick and easy. • Think about two programs on a computer: they can communicate via files, shared memory, pipes, or other constructs. • If you are familiar with processing on a UNIX- or Linix-based system, multiple commands are often strung together with pipes.

  40. Moving from Interprocess to Distributed Communication • Suzette’s store does so well that she moves her office into another building to increase the amount of retail floor space in her original store. Now Suzette and Henry are in different physical locations but still need to complete the same tasks of selling, ordering, and administration. We have moved into a physical two tier distributed system and things just become more complicated. Suzette and Henry still need to communicate but the previous methods will no longer work. • The obvious solution is the telephone, but this changes the dynamic of the entire conversation • In our computer analogy, we now have a client and a server tier where the previous solutions of files, shared memory, or pipes are no longer solutions as they only work within a single system.

  41. Moving from Interprocess to Distributed Communication • Suzette and Henry must now specifically locate each other (i.e. phone numbers) before communicating. • Conversations will be slower (network latency). • Data will need to be shared in different ways (difficult to draw a picture on the phone—the crayon keeps breaking on the handset). • And finally, the phone lines can go down or have interference (network errors or corruption).

  42. Moving from Interprocess to Distributed Communication • Yes, we have gained some benefits by spreading out Suzette and Henry (more retail floor space) but we have introduced complexity and latency into the business. • Similarly, when a distributed application is placed on different systems (whether physically or logically separated), we also introduce complexity and latency into the application. • However, the ability to take advantage of multiple computers is such a powerful incentive that we have devised many ways to accommodate our new problems • The stage is now set to discover how to implement this distributed communication.

  43. Middleware Layer • By choosing Java, we are explicitly ignoring the platform because Java (in theory) runs exactly the same on any platform that has a Java-compatible runtime environment. • We are not yet concerned with what capabilities an application will exhibit other than we will create a “server” component that holds the desired properties and a “client” component that requests these capabilities. • Assume that our distributed Java-based application will communicate via the TCP/IP protocol

  44. UDP Communication • Basis of TCP/IP protocol stack is the Internet Protocol (IP) data packet • IP is a connectionless and stateless protocol (“fire and forget”) • Once a IP packet is sent, the sender simply does not care about it anymore • IP packet can become lost, destroyed, misplaced, or corrupted on its way to its destination • If multiple IP packets are sent – they can arrive out of order • IP is quick to use but not reliable • Think of IP as simple postal envelopes: they can be easily damaged, lost, and delivered out of order. • However, IP envelopes are cheap and convenient. (The analogy to a postal service is very appropriate as the cost is low per message and the service is usually reliable but there is no capability to trace a wayward envelope.)

  45. UDP Communication • The User Datagram Protocol (UDP) is implemented on top of IP layer. • UDP is still a fairly lightweight protocol which means that most of its effort is spent on delivering data. • UDP adds two important features: larger “payloads” and data integrity. • If a message is larger than the size of a single IP envelope, UDP will split the message into multiple IP envelopes, taking care to remember how it split up the original message. • UDP guarantees that the data in a single UDP packet in the will arrive exactly as it was sent. • What happens if one of the IP packets that made up the UDP packet is lost? Then UDP discards the rest of the IP packets and thus the entire UDP packet rather than deliver a damaged UDP packet. • This is analogous to sending a four page letter in separate envelopes; if envelope #3 does not arrive, then UDP will throw array the remaining envelopes that did arrive as it has no way to reconstruct the original four page letter.

  46. UDP Communication • UDP is also a stateless and connectionless protocol • Stateless means that once a message is sent, the sender does not care about it anymore. • If the message arrives, then that is fine. If it does not arrive, we do not feel any grief • Connectionless means that there is no continued conversation. • The message is complete in and of itself. • Think about sending postcards. If we send one postcard from Europe and another from South America, neither of the postcards depend upon each other. They are separate communications

  47. UDP Design Considerations • For client-server applications that transfer relatively small amounts of data, UDP is acceptable • For the simplest application, a client will send a single message to the server and expect a response • If the client does not receive a response within a pre-determined amount of time, the client may send the request again. • This is similar to asking a person to repeat an answer. Of course, after asking for the answer so many times, it is likely that we (the client) will just give up. • If a DNS server does not respond after a couple of seconds, a client will simply accept that no answer is forthcoming and either ask another DNS server or return an error.

  48. UDP Example • UDP communications can be implemented in Java quite easily • However, it should be pointed out that UDP is simply a service to ferry data from point A to point B. • UDP does not understand data types or other Java constructs, such as objects. • To accommodate this understanding, we will use the capability of the String class to convert itself into an array of bytes and back. • We are implicitly relying on the String class to correctly convert an array of bytes using the correct code set. • Both the server and client will perform many of the same operations but the server has the additional task of existing in a state where it can receive requests at any time and must respond to them. A client, on the other hand, will only be executed on demand and exit as soon as it receives a response.

  49. UDP Server • The UDP server may look complicated but there is actually very little to it. • The server first creates a socket, which is a logical construct that we may attach to an actual port. • We have hard-coded the port upon which our server will listen, 7777. • You may choose any port between 1024 and 65535 (assuming that it is not already in use). • The server attaches to the port and then performs an endless loop of listening for any incoming message and sending the same message (known as a datagram) back to its sender. • The effect is similar to a mirror • See UDPServerSimple.java

  50. UDP Client • The UDP client seems to be much longer in length but that is because we have added in the ability to specify the message to send, the server name, and the port on which the UDP server is listening on the command line, rather than hard-coding it. • This approach should allow you to run the program as-is, even though you will run it on your system (which has a different network name and IP address than everybody else’s system). • The client, similar to the server, first creates a socket that can be bound to a network port. • However, we will not bind it to a particular port because we do not care—just as when you send a letter, the mailbox you use is irrelevant to the receiver.

More Related