RE: Friendly amendment #2c [Re: Straw poll on "synchronous" definitions]

  -----Original Message-----
  From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Walden Mathews
  Sent: Saturday, March 15, 2003 5:50 PM
  To: Anne Thomas Manes; www-ws-arch@w3.org
  Subject: Re: Friendly amendment #2c [Re: Straw poll on "synchronous"
definitions]



    ----- Original Message -----
    From: Anne Thomas Manes
    To: Walden Mathews ; Christopher B Ferris ; www-ws-arch@w3.org
    Sent: Saturday, March 15, 2003 6:11 PM
    Subject: RE: Friendly amendment #2c [Re: Straw poll on "synchronous"
definitions]


    The biggest issue I have with Ugo's definition (and all the others) is
that they tie synchrony with blocking versus non-blocking.

    [wm] Agree.  A better definition can show the relation to these
concepts, too.


     Synchronous means "at the same time". Asynchronous means "not at the
same time". Whether or not the sender has to wait idly for a response is a
separate issue.


    [wm] You've been cheating by looking at the dictionary!  But check this
out:

    2: (digital communication) pertaining to a transmission technique that
requires a common clock signal (a timing reference) between the
communicating devices in order to coordinate their transmissions [ant:
asynchronous] [1]

    That might be a better starting point than the lay "at the same time"
version.

    I believe the real issue is exactly how abstract to get with "same time"
so that
    it applies well across the board.  We should be trying real hard to find
that sweet
    spot of abstraction, I think.

    An interaction (one-way, two-way, or multi-way) is synchronous if the
sender and receiver must communicate at the same time (the reciever must be
available to receive the message when the sender sends it). A one-way
message is asynchronous if the sender and receiver do not need to
communicate at the same time (the message may be stored and delivered at a
later time).

    [wm] I can grasp it intuitively, but there are problems.  First, for
there to be "same time",
    there has to be a shared discrete clock, or at least a belief in one.
But then if we look
    at propagation delays (interpreted broadly), it's plain that
simultaneous send and receive
    doesn't work.  Maybe it's a nit, but how do you quantify 'close enough'?

    Good question.

    Define logical clocks as separate from physical clocks. (See Lamport et
al) Define physical clock synchronization derived from logical clock but
takes latency into account by proposing a resolution that is dependent on
the latency.

    So, if the latency is say 50~100ms, then at the same time is give or
take 100ms. But it's still at the same time. As opposed to two hours later.
After all, even though we have atomic clocks our computers will never
synchronize at that level. So one has to consider that each synchronization
is dependent on some arbitrary choice of time resolution.

    If you can estimate the latency for HTTP then you can estimate the
resolution by which you can say two activities occur at the same time using
HTTP as the protocol. But that's more interesting is that even if you can't
estimate the latency (e.g. using asynchronous messaging), you can still use
a logical clock that counts events (message sequence number) and gives you a
very precise definition of 'at the same time'.

    So short answer is: this problem has existed for quite some time and has
been handled by researchers and all we have to do is stop reinventing
solutions and look at what has already been solved and borrow from there.

    arkin

    I don't think you do.  I think you step back and realize it's about
expectations
    having to do with the clock, but it's definitely NOT about simultaneity
in any
    rigorous sense.  ...Which brings us close to the digital communications
definition
    cited above, in which the exact application of the clock is left
unspecified.

    I'd love to see someone do better, but I doubt it's possible.

    [1] http://dictionary.reference.com/search?q=synchronous


    --Walden

Received on Saturday, 15 March 2003 21:11:12 UTC