Summary of "sychronous" points

Folks,

In an attempt to bring this thread to closure and fruition, I've tried to 
summarize the main points I've seen regarding the definition of 
"synchronous" (though I may have missed a few details).  I've tried to take 
these into account in reworking my proposed definition.  The points below 
are in no particular order.  If I've missed any, it was due to the sheer 
difficulty of summarizing so many messages -- not due to any desire to 
slight anyone.

                                ----

Blocking
The word "blocking" has strong programming language connotations, and 
should be avoided in our definition.

Different levels/contexts
"Synchronous" can mean different things at different levels or contexts, 
for example, at the wire transmission level, at the message acknowledgement 
level, and at the operation, interaction or conversation level.  A protocol 
that is synchronous at one level can be implemented by a lower level 
protocol that is asynchronous.  A message can be synchronously 
acknowledged, but the processing of that message might be asynchronous.

Same communication channel
Some have suggested that "synchronous" implies that the "reply is on the 
same communication channel".  Although this is often the case, others have 
pointed out that an interaction can still be synchronous even if the 
request is on one channel and the response is on another.

Same time
Some have suggested that an operation is synchronous if it involves the 
initiator and respondent "at the same time".  This naturally led to the 
question of what "the same time" means, and some formal definitions were 
proposed.
However, several others talked about synchronous operations involving the 
requester waiting for the provider to respond

Sending party waits
The sending party waits for the receiving party to do something before the 
sending party continues.  Thus, they are "synchronized".  This also means 
that there is an expectation of immediate processing.
This seemed to be the strongest common theme I saw.

Speed
Someone suggested that an interaction is synchronous if "things happening 
in a timely manner".  Others pointed out that synchronous interaction 
doesn't have to be fast, even though asynchronous is usually preferred for 
interactions that are "slow".

Request/response
Someone mentioned that synchronous protocols require 
request/response.  Someone else pointed out that asynchronous may also have 
request/response.  Thus, although request/response may be a necessary 
condition, it isn't sufficient.

Correlation information
Someone suggested that synchronous exchanges do not require correlation 
information in the message, whereas asynchronous exchanges do.

Timing out
Someone suggested that synchronous operations "time out" if they take too 
long.  Someone else pointed out that "timing out" implies that one party is 
waiting for the other and that the "timing out" is more about how the 
initiator deals with the situation than a defining characteristic.


-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273

Received on Thursday, 27 February 2003 19:59:45 UTC