Unit 9 Flashcards
Comparing how parameter data associated with HTTP GET requests and POST requests is sent and received, answer the following questions.
(a) What are the main similarities between GET and POST?
Parameter data is extracted by servlet code or JSP directives in exactly the same way, regardless of whether it is associated with a POST or a 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 how parameter data associated with HTTP GET requests and POST requests is sent and received, answer the following questions.
(b) What are the main differences between GET and POST?
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 lines 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 GET requests 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 bear in mind when comparing thin clients, applet clients and application clients in Java EE?
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 such as 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 may 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 – this 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 each of the following?
(a) Client polling
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 each of the following?
(b) RSS
RSS feeds eliminate the problem of unnecessarily downloading whole web pages even if nothing on that page has changed – the page is download 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 each of the following?
(c) The server push approach using multipart/x-mixed-replace
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 following push technologies for applets and application clients?
(a) UDP
**User Datagram Protocol **UDP
UDP is connectionless and therefore 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 following push technologies for applets and application clients?
(b) Multicast UDP
Multicast UDP has the same pros and cons as normal (unicast) UDP, but 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 following push technologies for applets and application clients?
(c) TCP
Transmission Control Protocol (TCP)
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 following push technologies for applets and application clients?
(d) Messaging services
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.
Can you think of situations or applications where each of the following types of clock synchronisation would be appropriate in distributed systems?
(a) External synchronisation
This is essential where the time used by hosts is required to be correct in relation to standard time such as UTC.
This would include applications that must carry out an activity at a specific actual time, such as the finishing time of an internet auction.
Coordinated Universal Time (UTC)
Can you think of situations or applications where each of the following types of clock synchronisation would be appropriate in distributed systems?
(b) Internal synchronisation
Internal synchronisation is acceptable when the system time does not need to reflect the real-world time accurately.
Such applications might be those where timestamping is used to indicate the order in which events occurred (such as in transactions).
Here the actual values of the time are not important, only their relative order.
In distributed systems, what is the difference between physically synchronised clocks and logical clocks?
Physically synchronised clocks on different hosts will hold time values that are the same to within some specified tolerance. If they are externally synchronised, 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.
