Unit 9 The client tier Flashcards
Comparing parameter data associated with HTTP GET requests and POST requests are sent and received, what are the main similarities between GET and POST?
(Part 2) Parameter data is extracted by servlet code or JSP directives in exactly the same way, regardless of whether it is associated with a POSTor GET request. The underlying differences are hidden by the standard Java method calls or JSP directives. For both types of request, parameter data is normally sent in URL-encoded form, which means that any unsafe characters are replaced by their percent-encoded hexadecimal ASCII code values.
Comparing parameter data associated with HTTP GET requests and POST requests are sent and received, what are the main differences between GET and POST?
(Part 2) GET requests append the parameter names and their values to the URL in the GET command line itself. POST requests send the parameter data in the body of the request, following the lines containing the POST command and any line of header data. This means that parameters associated with a POST command are less visible to users. This can also accommodate much more parameter data, since the maximum length of the extended URL used by GETrequests is limited on most systems. POST can also deal with more complex data such as files or binary data, whereas GET request data is much more limited in type.
What are the main issues to consider when comparing thin clients, applet clients and application clients in Java EE?
(Part 4) Thin clients, typically browsers, may have limited functionality and operate mainly in pull mode. although these can be improved to some extent by the use of scripting languages (like JavaScript). They require only very limited hardware and software resources on the client machine.
Applets and application clients can provide a richer user interface and take some of the processing load away from the server for a more responsive client. They normally require more processing and storage on the client machine than thin clients.
Thin clients and applet-based clients have minimal deployment issues, assuming that most clients have a standard browser, though sometimes issues of browser versions and compatibility amy arise. Compatibility issues are of more concern for applet-based clients since browsers vary in their treatment of applets, although this is often solved by using the Java Plug-in.
For application clients, there has to be a way of installing the client software on each client machine and keeping this up to date - thsi can be problematic, but some Java EE implementations allow deployment of the application client software on the server for automatic downloading to clients as required.
What are the advantages and disadvantages of Client Polling?
(Type 5) Client polling (using the refresh META tag) is simple and works on all browsers. Its disadvantage is that it can generate considerable web traffic by frequent reloading of web pages. It also requires opening and closing connections to the server for every request, and many of the reloads may be unnecessary.
What are the advantages and disadvantages of RSS?
(Part 5) RSS feeds eliminate the problem of unnecessarily downloading whole web pages even if nothing on that page has changed - the page is downoaded only if something has changed since the last time it was checked. However, repeated polling of the server is required by the RSS reader, so the overhead of repeated connection opening and closing is similar to the case of client polling.
What are the advantages and disadvantages of using the server push approach using multipart/x-mixed-replace?
(Part 5) The server push approach using multipart/x-mixed-replace puts the server in control of when the web page is reloaded. Hence page reloads should happen only when there is something new to download.
Because the server keeps the HTTP connection with the client open while downloading a series of parts, it avoids the overhead of repeated opening and closing of HTTP connections. However, keeping the HTTP connection open may be a problem if there are many clients using this approach as most servers limit the number of possible HTTP connections. This approach is not supported by some browsers.
What are the pros and cons of the UDP push technology for applets and application clients?
(Part 5) UDP is connectionless and so each message is relatively efficient. However, it is unreliable in that messages can be lost or corrupted. It also has the disadvantage for large-scale systems that it requires the server to store IP addresses of all registered clients and to send one message per registered client for each notification.
What are the pros and cons of the Multicast UDP push technology for applets and application clients?
(Part 5) Multicast UDP has the same pros and cons as normal (unicast) UDP, but it is more efficient when the sender has to communicate the same message to many receivers. A disadvantage is that not all routers support multicast UDP.
What are the pros and cons of the TCP push technology for applets and application clients?
(Part 5) TCP is a reliable connection-oriented protocol - in that lost, corrupt or out-of-order data packets will be restored automatically by the TCP protocol software. Its disadvantage is relative inefficiency - setting up connections takes significant time and effort, and means that it is not suited to multicasting.
What are the pros and cons of the Message services, push technology for applets and application clients?
(Part 5) Messaging services are the most general approach. They use asynchronous communication, which can aid responsiveness, combined with reliability. The publish/subscribe approach is well suited to implementing server push.
However, the middleware may introduce a significant performance overhead in some cases, and most middleware is proprietary rather than standard.
In distributed systems, what is the difference between physically synchronised clocks and logical clocks?
(Part 6) Physically synchronised clocks on different hosts will hold time values that are the same to within some specific tolerance. If they are externally synchonised, this common time will be synchronised to some standard time such as UTC. If they are internally synchronised, then the common time may differ significantly from standard time, but in some applications only internal synchronisation is essential.
Logical clocks can be used in some situations where synchronisation is not required. Each host maintains a clock which it updates immediately after an event, such as sending or receiving a message. Messages sent to other hosts are time-stamped with the logical time of the sender. Receivers update their local logical clocks, if necessary, to ensure that events always have a later logical time than the event that caused them. Thus logical clocks can be used to record an order of events, although they are not applicable when the actual standard time is needed, such as in many real-time systems.
