Simple BUT reliable serial protocol

pozz <pozzugno@gmail.com> writes:
> [...]
> Now the big question: how the sender can be *always* sure that the
> message has really arrived (then processed) by the receiver?
>
> Of course, if the sender receives the ack for the frame of interest,
> it can be sure the message has arrived and processed.
> But what happens if the sender doesn't receive the ack, because it is
> transmitted with errors?
> It can sends without problem the message again, indeed the receiver
> will detect the duplicate message and sends again the ack for that
> frame (without processing the message another time).
> And what happens if the sender doesn't receiver second, third, ...
> ack? This could happen for example when an intermediate
> router/forwarder/hub has been powered off or the receiever has
> physically disconnected from the link.
> Maybe the message has arrived (and processed) just before the
> connection trouble, so the ack will never arrive to the sender.
>
> In this odd case, the sender can't be 100% sure if its message has
> arrived.  What is the solution for this situation?
>
> This scenario is very similar with actual TCP/IP network.  As said
> before, TCP is a protocol that implements acks, retransmissions and
> sequence numbers.
> After a TCP connection has established, the two hosts start exchanging
> data. At some time, something goes wrong and one host doesn't know if
> the last message has arrived or not to destination.
>
> I'm sure a simple solution exists, because TCP/IP is now used for many
> applications, even critical (on-line banking and similar things), but
> I can't find it myself.

The system/hardware designer should be able to set an upper bound on the
time required for a response. Thus the message initiator should always
know when a message has not been received.
-- 
Randy Yates, DSP/Embedded Firmware Developer
Digital Signal Labs
http://www.digitalsignallabs.com

On 1/18/2016 3:09 PM, Randy Yates wrote:
> pozz <pozzugno@gmail.com> writes:
>> [...]
>> Now the big question: how the sender can be *always* sure that the
>> message has really arrived (then processed) by the receiver?
>>
>> Of course, if the sender receives the ack for the frame of interest,
>> it can be sure the message has arrived and processed.
>> But what happens if the sender doesn't receive the ack, because it is
>> transmitted with errors?
>> It can sends without problem the message again, indeed the receiver
>> will detect the duplicate message and sends again the ack for that
>> frame (without processing the message another time).
>> And what happens if the sender doesn't receiver second, third, ...
>> ack? This could happen for example when an intermediate
>> router/forwarder/hub has been powered off or the receiever has
>> physically disconnected from the link.
>> Maybe the message has arrived (and processed) just before the
>> connection trouble, so the ack will never arrive to the sender.
>>
>> In this odd case, the sender can't be 100% sure if its message has
>> arrived.  What is the solution for this situation?
>>
>> This scenario is very similar with actual TCP/IP network.  As said
>> before, TCP is a protocol that implements acks, retransmissions and
>> sequence numbers.
>> After a TCP connection has established, the two hosts start exchanging
>> data. At some time, something goes wrong and one host doesn't know if
>> the last message has arrived or not to destination.
>>
>> I'm sure a simple solution exists, because TCP/IP is now used for many
>> applications, even critical (on-line banking and similar things), but
>> I can't find it myself.
>
> The system/hardware designer should be able to set an upper bound on the
> time required for a response. Thus the message initiator should always
> know when a message has not been received.

That does not make sense.  The issue is how does the initiator 
distinguish between the message being lost and the message response 
being lost?

-- 

Rick

rickman <gnuarm@gmail.com> writes:

> On 1/18/2016 3:09 PM, Randy Yates wrote:
>> pozz <pozzugno@gmail.com> writes:
>>> [...]
>>> Now the big question: how the sender can be *always* sure that the
>>> message has really arrived (then processed) by the receiver?
>>>
>>> Of course, if the sender receives the ack for the frame of interest,
>>> it can be sure the message has arrived and processed.
>>> But what happens if the sender doesn't receive the ack, because it is
>>> transmitted with errors?
>>> It can sends without problem the message again, indeed the receiver
>>> will detect the duplicate message and sends again the ack for that
>>> frame (without processing the message another time).
>>> And what happens if the sender doesn't receiver second, third, ...
>>> ack? This could happen for example when an intermediate
>>> router/forwarder/hub has been powered off or the receiever has
>>> physically disconnected from the link.
>>> Maybe the message has arrived (and processed) just before the
>>> connection trouble, so the ack will never arrive to the sender.
>>>
>>> In this odd case, the sender can't be 100% sure if its message has
>>> arrived.  What is the solution for this situation?
>>>
>>> This scenario is very similar with actual TCP/IP network.  As said
>>> before, TCP is a protocol that implements acks, retransmissions and
>>> sequence numbers.
>>> After a TCP connection has established, the two hosts start exchanging
>>> data. At some time, something goes wrong and one host doesn't know if
>>> the last message has arrived or not to destination.
>>>
>>> I'm sure a simple solution exists, because TCP/IP is now used for many
>>> applications, even critical (on-line banking and similar things), but
>>> I can't find it myself.
>>
>> The system/hardware designer should be able to set an upper bound on the
>> time required for a response. Thus the message initiator should always
>> know when a message has not been received.
>
> That does not make sense.  The issue is how does the initiator
> distinguish between the message being lost and the message response
> being lost?

You're right. I did not read the whole message. 
-- 
Randy Yates, DSP/Embedded Firmware Developer
Digital Signal Labs
http://www.digitalsignallabs.com

On Monday, January 18, 2016 at 5:26:23 PM UTC-5, rickman wrote:
> On 1/18/2016 3:09 PM, Randy Yates wrote:
> > pozz <pozzugno@gmail.com> writes:
> >> [...]
> >> Now the big question: how the sender can be *always* sure that the
> >> message has really arrived (then processed) by the receiver?
> >>
[]
> >> I'm sure a simple solution exists, because TCP/IP is now used for many
> >> applications, even critical (on-line banking and similar things), but
> >> I can't find it myself.
> >
> > The system/hardware designer should be able to set an upper bound on the
> > time required for a response. Thus the message initiator should always
> > know when a message has not been received.
> 
> That does not make sense.  The issue is how does the initiator 
> distinguish between the message being lost and the message response 
> being lost?
> 
> -- 
> 
> Rick

It doesn't matter. Think about it.
case 1
Message lost, receiver never sees it and never sends an ACK. Initiator times out and will resend the message.
case 2
Message delivered, receiver  sees it and  sends an ACK. The ACK is lost. Initiator times out and will resend the message.

Don't look at it from a narrator's view. Look at it from the Initiator's view.

ed

How about simple nagging-type algorithm. The message to be transmitted will contain a "message id" counter along the payload.

The message id will be incremented for each new message to be sent.

The sender will keep sending the same message until it gets an acknowledgement with the same message id ie. it keeps nagging until it gets an acknowledgement for the message it has been trying to send.

When the receiver will receive a message with a new id, it will execute the command and send the acknowledgement message with the same message id.

If the receiver received a message with same id that is is trying to acknowledge, it will send an acknowledgement message with the same id.

The sender may decide to give up after certain period of time (timeout). 

However, the sender will never be able to know whether the command was properly executed without the acknowledgement message.

Br,
Kalvin

People can save a lot of fruitless effort and hence enable them
to contribute to novel improvements. The only technique necessary
is simple standard ordinary *researching* the literature.

Then people will understand what is and is not possible, and
what techniques are known to reduce the "impossible" problems
to something that is tolerable.

There has been a vast amount of literature about "distributed
systems" over the past 60 years. It has been a *long* time since
I've seen anything new.

But I've seen a lot of people waste a lot of their lives
repeating old known mistakes.

The pure hardware analogy is "metastability", which was a
topic of debate up to and including the early 70s. New digital
engineers have the grace and sense to not try to find tricks
to circumvent metastability.

I found "Jean Bacon�s Concurrent Systems: Operating Systems,
Database and Distributed Systems � An Integrated Approach"
http://www.amazon.co.uk/Concurrent-Systems-Distributed-Integrated-International/dp/B00EKZ0PQK
a useful starting point, but there are many other books
that are equally useful.


On 28/01/16 13:04, kalvin.news@gmail.com wrote:
> How about simple nagging-type algorithm. The message to be transmitted will contain a "message id" counter along the payload.
>
> The message id will be incremented for each new message to be sent.
>
> The sender will keep sending the same message until it gets an acknowledgement with the same message id ie. it keeps nagging until it gets an acknowledgement for the message it has been trying to send.
>
> When the receiver will receive a message with a new id, it will execute the command and send the acknowledgement message with the same message id.
>
> If the receiver received a message with same id that is is trying to acknowledge, it will send an acknowledgement message with the same id.
>
> The sender may decide to give up after certain period of time (timeout).
>
> However, the sender will never be able to know whether the command was properly executed without the acknowledgement message.

On Thu, 28 Jan 2016 05:04:49 -0800 (PST), kalvin.news@gmail.com wrote:

>How about simple nagging-type algorithm. The message to be transmitted will contain a "message id" counter along the payload.
>
>The message id will be incremented for each new message to be sent.
>
>The sender will keep sending the same message until it gets an acknowledgement with the same message id ie. it keeps nagging until it gets an acknowledgement for the message it has been trying to send.
>
>When the receiver will receive a message with a new id, it will execute the command and send the acknowledgement message with the same message id.
>
>If the receiver received a message with same id that is is trying to acknowledge, it will send an acknowledgement message with the same id.
>
>The sender may decide to give up after certain period of time (timeout). 
>
>However, the sender will never be able to know whether the command was properly executed without the acknowledgement message.
>
>Br,
>Kalvin

Instead of inventing the wheel again, take a look at Modbus/TCP
protocol.

>On Thu, 28 Jan 2016 05:04:49 -0800 (PST), kalvin.news@gmail.com wrote:
>
>>How about simple nagging-type algorithm. The message to be transmitted
will
>contain a "message id" counter along the payload.
>>
>>The message id will be incremented for each new message to be sent.
>>
>>The sender will keep sending the same message until it gets an
>acknowledgement with the same message id ie. it keeps nagging until it
gets
>an acknowledgement for the message it has been trying to send.
>>
>>When the receiver will receive a message with a new id, it will execute
the
>command and send the acknowledgement message with the same message id.
>>
>>If the receiver received a message with same id that is is trying to
>acknowledge, it will send an acknowledgement message with the same id.
>>
>>The sender may decide to give up after certain period of time (timeout).

>>
>>However, the sender will never be able to know whether the command was
>properly executed without the acknowledgement message.
>>
>>Br,
>>Kalvin
>
>Instead of inventing the wheel again, take a look at Modbus/TCP
>protocol.

One more vote for Modbus/TCP. Supported by many SCADA tools (even mobile
apps - see HMI Draw) and easy to debug (Wireshark).
---------------------------------------
Posted through http://www.EmbeddedRelated.com

On Thursday, January 28, 2016 at 8:04:58 AM UTC-5, kalvi...@gmail.com wrote:
> How about simple nagging-type algorithm. The message to be
> transmitted will contain a "message id" counter along the payload.
> 
[]
> 
> However, the sender will never be able to know whether the command was properly executed without the acknowledgement message.
> 
> Br,
> Kalvin


Either you are mixing terms or misunderstanding the problem.

The serial communications software doesn't know OR CARE if it is a command. It only knows that it has a packet of data to transmit, and whether the data was transmitted and received. That's all.

Stop mixing in the application level work.

ed