IAP Tools for D

John Carter via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Sun Dec 20 11:03:14 PST 2015


On Sunday, 20 December 2015 at 17:52:40 UTC, Jakob Jenkov wrote:
> I just had a look at Cap'n Proto. From what I can see in the 
> encoding spec, performance of ION will be comparable.

"If a disease has many treatments, it has no cure".

This is certainly true for serialization protocols.

The major advantage I see in Cap'n'Proto is the pipelining can do 
quite a lot to reduce round trip latency. (You don't have to 
google far to find rants pointing out that latency is often more 
important than bandwidth in determining throughput.)

I was just reading your IAP web site, when I came across "No 
Stateful Communication" under the heading "What is Wrong With 
HTTP?".

The designers of HTTP would strongly argue that is a major thing 
HTTP got right, and is the feature primarily responsible for it 
huge success.

Certainly in the realm of IoT HTTP is way too heavy.... so in 
that domain I would reach for
http://coap.technology/

The use case I keep challenging my colleagues with is....

So one end or the other dies. Or resets. Or fades and comes back. 
Or changes batteries.

This is the IoT things. It will happen, and you will be required 
to recover the whole end to end system automatically without 
manual intervention.

What is your plan?

Too often the answer is... "We don't have a plan but we will have 
a wheel restarting the link.... umm, then a wheel resending the 
stuff that was lost in the link buffers when the link went 
down.... and a, errrr, maybe wheel restarting Everything when we 
realise the other side has lost it's state about our connection.

And in practice the only wheel that works is shutting everything 
down and restarting everything up.

Suddenly "No stateful communication" is looking really really 
Good.

Coap clearly has thought these issues through.


More information about the Digitalmars-d-announce mailing list