M362 - Unit 9 Flashcards Preview

M362 - Unit SAQs > M362 - Unit 9 > Flashcards

Flashcards in M362 - Unit 9 Deck (12):
1

Comparing how parameter data associated with HTTP GET requests and POST requests is sent and received, 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.

2

Comparing how parameter data associated with HTTP GET requests and POST requests is sent and received, 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.

3

What are the main issues to bear in mind when comparing thin clients, applet clients and application clients in Java EE?

Thin clients (browsers) may have limited functionality and operate mainly in pull mode, but require only very limited hardware and software resources on the client machine. Applets and application clients provide a richer user interface and take some processing load away from the server, but normally require more processing and storage on the client machine than thin clients. Thin clients and applet-based clients have minimal deployment/compatibility issues. Compatibility is of more concern for applet-based clients since browsers vary in their treatment of applets. For application clients, there has to be a way of installing the client software on each client machine and keeping this up to date – 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.

4

What are the advantages and disadvantages of 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.

5

What are the advantages and disadvantages of RSS?

RSS feeds eliminate the problem of unnecessarily downloading whole web pages even if nothing on that page has changed – the page is downloaded 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.

6

What are the advantages and disadvantages of 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.

7

What are the pros and cons of UDP for applets and application clients?

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.

8

What are the pros and cons of multicast UDP for applets and application clients?

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.

9

What are the pros and cons of TCP for applets and application clients?

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.

10

What are the pros and cons of the messaging services for applets and application clients?

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.

11

Describe physically synchronised clocks in distributed systems.

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.

12

Describe logical clocks in distributed systems.

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.