I am trying to implement a [1] distributed key generation protocol. Supposing that there are 5 nodes and one of them Alice should broadcast its public key to others. Considering a broadcast channel is implemented as several p2p channels between each couple of nodes, Alice may attack the protocol by sending the different public keys to different nodes.
Does anyone know how to prevent this kind of misbehavior?
I have looked into an open-source implementation of the protocol, which uses the ETH smart contract as a broadcast channel. But I would like to solve the problem off-chain. Also, I have researched "reliable broadcast" which looks pretty complex to implement. AFAIK, reliable broadcast ensures a message delivered to ALL correct nodes, which is not identical to what I need. I want to prevent a malicious sender from sending different messages. But an honest receiver failed to receive is okay to me.
Related
I'm reading here, and I see a warning stating that PUB/SUB subscribers in Redis should not issue other commands:
A client subscribed to one or more channels should not issue commands,
although it can subscribe and unsubscribe to and from other channels.
I have two questions:
Why is this limitation?
For the scope of the paragraph, what's a client? A whole process? A Redis connection? A complete Redis instance? Or is it a bad idea in general to issue commands and subscribe to channels, and the admonition goes for every and any scope I can think of?
A client, in this case, is an instance of a connection to Redis. An application could well have multiple clients, each with different responsibilities or as a way to provide higher degrees of parallelism to the application.
What they are suggesting here, however, is that you use an individual client (think 'connection') to handle your incoming subscription messages and to react to those messages as its sole responsibility. The reason it's recommended not to make calls with this connection is because while it is waiting on incoming messages from subscribed channels, the client is in a blocked state.
Trying to make a call on a given client won't work while it's awaiting response from a blocking call.
Related WebRTC, ICE protocol gives the which pair of addresses will work for direct media transfer between the pairs.
Let A and B are two endpoints
To choose which address will work for direct communication between A and B, Person A first gather candidates, encode candidate attribute, encode the SDP offer message, and send it to another endpoint.
When B get offer message from A,then person B gather candidates, encode the SDP answer message with its own list of candidates and send it to person A.
At this end of this process, each agent has a complete list of local candidates and Remote candidates. Its pairs them up, resulting in CANDIDATE PAIRS. To see, which pair work, each agent performs the connectivity checks using STUN req/resp.
How many connectivity checks are performed, to nominate valid candidate pair?
What are the remaining ICE connectivity checks are performed regarding webRTC call?
To develop ICE module for webRTC call, I have to follow each step in RFC5245 or any thing else?
How many connectivity checks are performed, to nominate valid
candidate pair?
The number of candidate pairs are the number of connectivity checks done by each side.
What are the remaining ICE connectivity checks are performed regarding
webRTC call?
There are no extra ICE connectivity checks for webRTC.
To develop ICE module for webRTC call, I have to follow each step in
RFC5245 or any thing else?
You have to implement or use existing implementation of DTLS protocol, RFC5763 and RFC5764. DTLS implementation can be found on OpenSSL library.
All these seems a lot of work but if you use openssl then its easy enough.
In my situation multiple modules report their state over a CAN bus to a central processor, which replies and drives them. There's also a supervising processor, which listens in on the CAN bus and analyzes incoming messages from the modules for critically dangerous situations (two different modules reporting activating outputs which are absolutely forbidden from being activated simultaneously).
This all works okay as long as the CAN bus is noise-free.
CAN bus guarantees the recipient to receive a message; the message will be resent if no recipient confirms receiving it. The problem begins if there's more than one recipient and all of them absolutely must receive the message.
If the line is clean, both receive it, confirm it, and everything is okay.
If the message is badly damaged, neither will receive it, and it will be resent. That's okay.
But if the noise on the line is "just on the brink", one of them will receive it, and confirm, and the other will fail to receive it (noise on its end of the bus just minimally worse), and since the sender got the confirmation, the message won't be resent.
Is there a reliable way to assure two different recipients of a message both receive it? ...other than sending two messages with two addresses, specifically? (it's essential that the supervising CPU hears the same messages as the main CPU, not just similar)
There is no way at the CAN layer to detect receipt by more than one module. You would need to add messages to your communication protocol to confirm receipt if this is absolutely critical. As mentioned, you could have each module receive the same message and send a unique reply.
Some general thoughts:
1) Are the important messages broadcast periodically? If so, the recipient could test that the periodicity of the message is correct and fail safely if the period is violated.
2) CAN is a very robust network. In my many years, I have not seen noise affecting a single node like you described other than when the node was at the end of a exceedingly (and irrationally) long wire. You are correct to worry about this scenario and design your message format and system to be robust to all CAN failures. Generally, when safety or reliability was paramount, we would have more than one CAN bus communicating the information along with a number of crosscheck messages to verify that not only the path was intact but the device on the other end was operating intelligently. Our general assumption was that if crosscheck messages were making the trip, then our operational messages were making the trip successfully as well.
Obviously not.
It fails even in the simple case, that one receiver is shutdown.
There is no possibility for the master to detect this (for this single packet).
You need an advanced CAN, with more acknowledge slots, for each recipients one slot.
But you could request that each reciepient has to confirm the message with a unique response message.
So your master can detect by a timeout that not all reciepent received the message.
In our application the publisher creates a message and sends it to a topic.
It then needs to wait, when all of the topic's subscribers ack the message.
It does not appear, the message bus implementations can do this automatically. So we are leaning towards making each subscriber send their own new message for the client, when they are done.
Now, the client can receive all such messages and, when it got one from each destination, do whatever clean-ups it has to do. But what if the client (sender) crashes part way through the stream of acknowledgments? To handle such a misfortune, I need to (re)implement, what the buses already implement, on the client -- save the incoming acknowledgments until I get enough of them.
I don't believe, our needs are that esoteric -- how would you handle the situation, where the sender (publisher) must wait for confirmations from multiple recipients (subscribers)? Sort of like requesting (and awaiting) Return-Receipts from each subscriber to a mailing list...
We are using RabbitMQ, if it matters. Thanks!
The functionality that you are looking for sounds like a messaging solution that can perform transactions across publishers and subscribers of a message. In The Java world, JMS specifies such transactions. One example of a JMS implementation is HornetQ.
RabbitMQ does not provide such functionality and it does for good reasons. RabbitMQ is built for being extremely robust and to perform like hell at the same time. The transactional behavior that you describe is only achievable with the cost of reasonable performance loss (especially if you want to keep outstanding robustness).
With RabbitMQ, one way to assure that a message was consumed successfully, is indeed to publish an answer message on the consumer side that is then consumed by the original publisher. This can be achieved through RabbitMQ's RPC procedure calls which might help you to get a clean solution for your problem setting.
If the (original) publisher crashes before all answers could be received, you can assume that all outstanding answers are still queued on the broker. So you would have to build your publisher in a way that it is capable to resume with processing those left messages. This might turn out to be none-trivial.
Finally, I recommend the following solution: Design your producing component in a way that you can consume the answers with one or more dedicated answer consumers that are separated from the origin publisher.
Benefits of this solution are:
the origin publisher can finish its task independent of consumer success
the origin publisher is independent of consumer availability and speed
the origin publisher implementation is far less complex
in a crash scenario, the answer consumer can resume with processing answers
Now to a more general point: One of the major benefits of messaging is the decoupling of application components by the broker. In AMQP, this is achieved with exchanges and bindings that allow you to move message distribution logic from your application to a central point of configuration.
If you add RPC-style calls to your clients, then your components are most likely closely coupled again, meaning that the publishing component fails if one of the consuming components fails / is not available / too slow. This is exactly what you will want to avoid. Otherwise, why would you have split the components then?
My recommendation is that you design your application in a way that publishers can complete their tasks independent of the success of consumers wherever possible. Back-channels should be an exceptional case and be implemented in the described not-so coupled way.
We are running a course in robotics and Xbee is the most favorite communication protocol for the student. In last two years we helped them build around 62 various projects (40 more in pipeline).
All most all the projects involve sending different kind of data to the bot. Sometimes it is a 1 byte command where as sometimes it is a long string to be interpreted. Sometimes we face the issue of addressing a bot when one xbee is used in broadcast mode to send messages to a particular bot among several. Students use their creativity to address this issue each time.
I personally feel this is reinvesting the wheel. I wonder if any higher level protocol proposals exist for serial port communication and if there isn't any specific protocol design I wonder if if the worth designing one for the student needs.
Do you mean internal only protocol of your system? If yes, often embedded software engineers incline to roll their own protocols. Most of them talks that it lets them make most optimal system.
It is not ideal approach. I agree with you that it's good for students to learn good examples.
Unfortunately I don't know any protocol stack fitting well robotics application. But I advice you to try google's protocol buffer system, its able to simplify most efforts of building protocols engines, and it works with plain c too.
You can implement Modbus ASCII if you want to go with a standard protocol that's already open.
Comli is a master/slave protocol that is used in some older devices or when it is not possible to use ethernet. You can probably get the specification from ABB if you ask - it's no secret.
That said you can put an OPC server/client architecture on top of that to get a bit more powerful communication e.g.
+--------------+ +--------------+ +--------+
| OPC UA Client| -- | OPC UA Server| -comli- | Device |
+--------------+ +--------------+ +--------+
This would make your OPC UA client protocol indepedent which makes things a bit easier down the road.
Modbus is another serial protocol that is used a lot
I believe OPC will give you the highlevel operation that you want.
see
www.opcfoundation.org
www.abb.com
PS. OPC UA is not the same as the old OLE version and thus has nothing to do with COM/DCOM
Like mjh2007 said, Modbus is standard, open and easy. The only problem I can see is if you want the robot to respond "quickly" to a command, since serial Modbus uses timeouts to detect the end of a packet. You can get around this by ignoring the timeout requirements and calculating the expected size of a packet based on it's function code and parameters as you are receiving it, then you can start processing the command immediately upon receiving the last byte and verifying any checksums. This page has some more details on implementing such a scheme.
Be sure to make use of the XBee module's "Transmit Explicit" frame (type 0x11) running in API mode with ATAO set to 1. You can unicast to a particular bot on your network, instead of always broadcasting frames. On a mesh ZigBee network, you want to avoid broadcasts as much as possible.
I'm guessing you're either using "AT mode" for sending raw data, or using "API mode" with ATAO set to 0 (sometimes referred to as "transparent serial").
If you look at that frame type (0x11), you'll see that the recipient gets an 0x91 frame that contains multiple fields already (source/destination endpoint, cluster, profile ID). You can re-purpose those fields since you're not trying to do ZigBee networking.