[E-Lang] security, comms, ordering guarantees

[Karp, Alan]

Ralph Hartley wrote:
>
> If I thought there were NO situations where weaker ordering 
> was usefull, 
> I wouldn't have written about them.
> 

No offense intended.  On rereading your note, I see my point was unnecesary.
I intended to point out that I thought your statement about "most" was too
strong.  Perhaps if you had said "many" :-)  In parallel, scientific jobs,
out of order delivery and processing is quite common.

>
> Your (more than likely invalid) patent doesn't really cover 
> what we are 
> talking about here. We are considering the order in which 
> messages are 
> DELIVERED, only for some applications is there even a concept of 
> messages being "processed".
> 

My (almost certainly invalid) patent is a way to communicate a change
without an additional round trip as is done today.  In general networks, no
one controls the order of message delivery.  Any time there's more than one
path between sender and receiver, messages can be received out of order.
Software goes to a lot of trouble to provide the appearance of in order
delivery, trouble that often introduces delays.  I believe, for example, IP
packets are frequently delivered out of order, but TCP doesn't notify the
receiver until the full message has been assembled.  In other words,
delivery is out of order but processing is in order.  By the way, I am using
the word "processed" here to mean "used to update the receiving process's
state".

> 
> In any case, it is more often the recipient, not the sender, 
> who is in a 
> position to judge what order to process the messages in. Only the 
> recipient knows how many messages were recieved, and in what 
> order, and 
> has any idea of the cost of getting a different order. Ordering 
> constraints are a contract with the reciever, which the reciever may 
> chose waive ((b weak) allows this). The sender might advise, but it 
> can't enforce the order anyway.
>

I don't know about "often", but both situations arise.  If the receiver
knows, there's no issue.  If the sender knows, then there must be a way to
inform the receiver.  However, the issue is not how many messages have been
received and in what order.  The issue is whether or not the receiver can
update its state based on the most recently received message or must it wait
for one sent earlier but not yet received.

I agree that the receiver can choose to ignore the sender's advice, but I
assume both parties benefit from getting the right answer.

> 
> In most cases, the order sensitivity of messages is fixed by the 
> (application layer) protocol anyway, the applications already 
> know if it 
> matters or not. I wouldn't expect per-message canges in 
> ordering policy 
> to be all that common.
> 

Well, we did the work in 1992, so I don't remember the details, but we
developed the protocol in response to a specific need.  I do recall that the
changes in ordering policy were frequent enough that the developers wanted
to avoid the handshake.

> 
> I wouldn't expect the patent office to notice, but if your what you 
> describe was invented AFTER the telgraph, I would be supprised.
> 

Hmmm.  I recall looking at telegraph protocols and convincing myself they
don't apply, but I'll be darned if I can remember why.

_________________________
Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/