Information Technology Reference
In-Depth Information
reflect any changes or additions. At a tactical level, however, a ques
tion arises concerning when the updates should be reported.
Unfortunately, although updates may be done in several ways, each
approach has difficulties. Here are some of the choices:
Immediate update (sometimes called writethrough)
: The file
server could be notified immediately every time a user makes
any change in any part of a file. At an extreme, a message
would be sent from the client to the server for each character
added or changed in the file. Although this keeps the server's
copy up to date at all times, extensive editing generates con
siderable network traffic. Such traffic can interfere with other
work being done over the network and can slow processing
speeds of the word processing itself.
Update at the very end (sometimes called writeonclose)
: The
client could keep track of all changes made in a file, and no
tify the server only when the user completes the work, exiting
the word processor. This approach generates little network
traffic—just at the end of a session. On the other hand, this
requires the local machine to store a considerable amount of
data. Further, because no revisions are changed on the server
as they are made by the user, all updating work may be lost if
the hardware or software malfunctions. Of course, if a user
opens a file, makes a simple change, and quits, then writeon
close and writethrough may turn out to be quite similar.
Batched updates (sometimes called writedelayed)
: The client
could delay notifying the server about updates or additions
rather than reporting updates as they occur. Effectively, this
allows the client to keep track of changes as they occur and
report several changes at once to the server. This is a compro
mise approach between the two extremes and has elements of
many compromises. Batched updates generate network traffic
periodically—not with every change, but also not just once at
the end. Similarly, this approach saves changes that the client
has made to the file in batches. After a malfunction, work
from the last regular server report would be lost, but that
might be only a few minutes of work.
Remote file access often involves running an application on the
client's machine with delayed reports to the server regarding modi
fications. This provides a reasonable balance between generating
