Simple BUT reliable serial protocol

I did not make such claims. I never said I implemented such a system instead of TCP/IP. If you need a reliable bidirectional communication on an channel, which may not be an IP network at all, it is possible to do it like this.

If there is a possibility of using TCP/IP, of course you should use it.

Fair enough; my misapprehension.

The TCP protocol does not /require/ IP. There are examples of it running on morse, icmp, Infiniband, ipx and probably avian carriers.

Not everyone realises that :(

You have to be able to query the far node for state after the line drops and comes back up. Even better ( if you have the bandwidth for it), the far node asynchronously sends state periodically when the line is up

--
Les Cargill

But you may actually be able to shape your own, UDP based ( in color and shape ) solution that will have advantages over TCP.

Principally, this has to do with broken connections - TCP takes a very long time to give up. Minutes in cases; at least I have never found a set of config flags for sockets and/or the stack that will make it give up sooner.

I'd say the nearly universal state of Web protocols over TCP damns it with very faint praise. It sort of flabbergasts me what people are willing to put up with.

This is "comp.arch.embedded" and the audience is highly likely to have run into cases where TCP did not perform.

It's a lousy metaphor, but I like saying "TCP just sells you life insurance; it does not guarantee immortality."

You'll find very frequently that people fail to make this distinction.

--
Les Cargill

Which is the other half of the two generals problem.

--

Rick

So the transaction is in an indeterminate state until the connection to the remote node comes back up? Which then begs the question of what state the remote node thinks the transaction is in once it's sent the ack? How will it know if or when the ack is processed by the local node?

Now if the remote node is simple a backup for the local node, and it does nothing until some (outside) intervention causes it to take over, the problem is simplified, but like the two generals problem, you often have two nodes controlling different things, and they may need the same view of the state of the overall system.

You are asking about the two generals problem. There is always a possible state where the one end doesn't know what state the other is in if a message is lost because it can't know *which* message was lost.

--

Rick

I would have the both nodes query for the ID of the last completed transaction on reestablishment of the link. There are other strategies.

This gets relatively involved. It's roughly equivalent to transaction handling in databases.

--
Les Cargill

On Monday, January 4, 2016 at 4:29:54 AM UTC-5, pozz wrote: []

In those cases, you don't use a simple serial link.

You use real networks with multiple possible data and control paths. You have error recovery protocols up to and including the application level. And in the end, you have a supervisor/administrator who can manually override failed transactions, either rolling them back or correcting them before they are committed.

For your case, you have to decide what failure rate your application can tolerate and choose hardware and software/firmware that meets the requirements.

Bottom line, however, is that there are no systems that can meet the requirement for "applications where I can't accept *any* error."

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

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

You're right. I did not read the whole message.

--
Randy Yates, DSP/Embedded Firmware Developer 
Digital Signal Labs 
http://www.digitalsignallabs.com

[]

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.

a useful starting point, but there are many other books that are equally useful.

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

will

gets

the

One more vote for Modbus/TCP. Supported by many SCADA tools (even mobile apps - see HMI Draw) and easy to debug (Wireshark).

--------------------------------------- Posted through

[]

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