I understand that CoAP is a lightweight communication protocol used in IoT, and that it supports both client-server and Pub/Sub communications. However, I can't find a nice explanation of the Resource Directory and how it's used in a real life example. I tried reading the RFC but could not understand much. Could you please explain what's the role of the Resource Directory?
Thank you
Related
For network automation, I see that NETCONF, RESTCONF and gRPC are available. Can someone tell me which one should be chosen for a typical router and respective use cases.
Can you please share the known issues or challenges with respective approach in terms of implementation.
Today I have a bit tricky question. Imagine a situation when someone has written a custom connector to the network (let's say there are a lot of security features hidden and so on). Now imagine that each application can connect to the network (even IoT Edge Runtime) only through this custom connector (let's say, this connector has implementation of both https and plain MQTT protocols).
Now the issue! According to the documentation here https://github.com/Azure/iotedge/blob/master/doc/networking.md the IoT Edge Runtime connects to the network through moby-engine modified by Microsoft. According to the Microsoft, we cannot get this moby-engine. Moreover, if we use original moby project the support from the Microsoft will be caught off, which is a bad thing. So, we cannot modify moby-engine and make it use this custom connector.
Now the question!
Is it possible (may be I missed something in documentation. Not the first time tbh) to use custom connector with IoT Edge Runtime (no proxy, we need plain MQTT protocol)? If yes, can you explain in details how? If no, what posible features inside Iot Edge Runtime/moby engine can help to use custom connector?
Please ask, if you need more information. I will provide it right away. A similar question was asked by me on Microsoft github. No response from there.
The proposal from #silent pointed me to the correct direction. While reading manuals, how to properly setup a gateway, I once again began to read manual about creating custom modules. This pointed me to have a look at preparing a build environment. This again directed me to the SDK bit.
Honestly speaking, by accident and mostly out of curiosity I clicked the link about porting the SDK to my custom platform. This was the solution in my case https://github.com/Azure/azure-c-shared-utility/blob/master/devdoc/porting_guide.md
I have to mention here two other solutions I walked through:
Proxy server that supports your custom connector/protocol (will
work for cases where you do not need MQTT. However, MQTT websockets
can be used here)
Gateway. This is definitely a good one. Again many thanks to #silent.
Which one will work in your particular case is only up to you to decide.
I am new to this kind of architectures and I'm going to start using these shortly, but I can't understand how they work, what they do and their differences.
I've searched online but what I'm looking for is just some kind of small example that helps me understanding the basics.
Thanks in advance for any kind of help.
CORBA and DDS are both two open middleware standards for which there are multiple implementations. For both standards there are a lot of resources on the internet.
CARDAMOM is a component framework which is an implementation of the OMG LwCCM standard. It uses CORBA and DDS as underlying communication middleware standards. CARDAMOM is a product of Thales and Selex and there is not a lot of public information about it.
To understand the basics you can try to read the standards but those are not written as user manual. As alternative have a look at CIAO and AXCIOMA which are two alternative implementations of the LwCCM standard. Both also integrate CORBA and DDS as communication middleware but AXCIOMA also integrates ZeroMQ and MQTT as alternative options. CIAO uses the IDL to C++ language mapping where AXCIOMA is using the IDL to C++11 mapping.
How do I know when a web site uses an RDF ?
For example , I know that eBay and Amazon uses RDF because I've read in many articles, but as I know it in practice ?
In practice, there is currently no single standardized way for websites to "advertise" their use of RDF. You find out by them informing you about it in some fashion, e.g. by them publishing a link to API documentation that describes how they use RDF, or indeed by writing an article about it, so pretty much the same way you find out about any REST API / web service. Of course, in the case of RDF/linked data you are often helped by the fact that other datasets you already know about may be linking to the new source, thus making it discoverable.
There are some attempts at defining more standardized mechanisms for 'advertising' a website's linked data use. The W3C VoID specification is the closest thing to a standard in that regard: it provides a vocabulary for publishers to describe the data and access mechanisms they offer, and it also gives pointers on how to make things discoverable. Unfortunately, it is not (yet) very widely adopted.
I am in trouble finding API for the "local Erlang client" for Riak.
Here is what Riak wiki says:
The local Erlang client is a tightly-integrated part of Riak and the Riak REST interface uses the Erlang client internally. You can find more information about the Erlang-native driver in the edoc API.
The link redirects to the main wiki-page. There is plenty of information on PBC Client though.
How do both clients compare and what are the pros and cons in using one or another?
The API for the native erlang client or edoc is found here
But I would second what Dan says. However, note that the PBC is still very much at the alpha stage of development and as far as I know does not yet have map reduce capabilities.
I would recommend using the PBC client. The performance is comparable to the native erlang client. It is also easier to decouple your application code from Riak. The native erlang client requires the entire Riak code base as a dependency.
From Riak 2.0 and on, it is highly recommended to use PB (Protocol Buffers) APIs over HTTP APIs. They have become a primary APIs, have more functionality and also is faster than HTTP APIs.
Getting Started with Erlang client
GitHub repo for official Riak Erlang client