Field vs. Web: Is there a difference

Peer-Peer
A peer-to-peer architecture has two systems that are each responsible for maintaining and manipulating their own information according to their own rules, but they communicate information between them. The key distinction is that either system is effectively independent of the other, insofar as it can operate without the exchange of information, even if that would often reduce the uset%lness of the system dramatically. In most peer-peer architectures, the flow of information between the systems is (or could be) asynchronous – the sending system need not wait for the receiving system to process and respond to the message.

Comparison
A web browser is clearly near the master-slave end of the spectrum, providing a common and very generic client that does little more than provide a means of accessing data and functionality that is offered by a server. The World Wide Web was conceived as a means of providing easy access to a body of published information. Its style and communications protocols still reflect that original concept, although it has become much more interactive in the last few years. The vast majority of web applications have little or no processing and manipulation of information at the client end. Even with browser plug-ins and Java, the client functionality is usually limited to controlling presentation of packets of data received from the server or doing very basic pre-processing of information prior to sending it back.

This is generally true of even the more sophisticated Web GIS clients; relatively small amounts of data are downloaded to the client, which may provide local pan, zoom and basic presentation manipulation. However, user activities that require any real processing, or even simply panning around will typically cause a request to be sent back to the server, and (probably) another download of data in response.

Most solutions sold as field systems today are clearly at the opposite end of the spectrum, having a peer-peer relationship with the host GIS system. The field system will get a cut of data from the main database, and will happily provide usefid functionality without any fiu-ther reference to the “server”. Some time later, an exchange of information will occur, and then the two systems will again proceed independently. Being self-sufficient in this manner places requirements on the system designers that simply do not exist for the implementers of slave systems.

Communications
A related subject is that of the nature of the communications link between the two systems. However, the two can be viewed independently, because the functional relationship between the two systems is not determined by the means of communicating between them, although poor communications clearly have a much more substantial effect on less intelligent clients.

There are several key measures of a communications link, each of which affects the efficacy of a particular system architecture in its own way.

Bandwidth or Throughput - a measure of the amount of data that can be transferred in a given time period.
Message Latency (Turnaround Time)- a measure of how long it takes to send a (small) message from one end to the other – and back, in the case of turnaround time.
Reliability – a measure of how likely the message is to arrive with no errors at the other end.

The following table illustrates these points by comparing sending a tape overnight and using a good modem connection:

Measure	Tape	Modem
Bandwidth	High (around 1000 Kb/s)	Low (Up to 56 Kb/s)
Latency	High (24 Hrs)	Low (-1S)
Reliability	High	Medium to low

Reliability is a little hard to judge because most communications systems have error correction built in. If a message is damaged in transit, this is usually detected and a resend automatically requested at a low level in the system. However, anyone who has tried downloading large tiles from the Internet over modems will know that the underlying reliability is reflected in an inability to receive the message at all within a reasonable period of time.