What is the difference between Send and SendMsg interface in tinyos?
SendMsg is an interface in TinyOS 1.x whereas Send is in TinyOS 2.x. It's possible to use only one of them, depending on your version of TinyOS. Probably you prefer to use the newer version.
By the way, SendMsg analogue in TinyOS 2.x is not Send, but AMSend. The former is used for address-free protocols and the latter for active message communication. See http://www.tinyos.net/tinyos-2.1.0/doc/html/tep116.html (especially section 2.2 Sending interfaces).
Related
I want to know which software/tool can be used to make custom packets and send them and capture responses
I am trying to observe my os behaviour for different packets comming and i want to make my own packets and it may be tcp upd or icmp or ssl packets with the fields i want in them so that i can send to my os and observe its response. So is there any tool/software to do there please help me
I have a pet project called CommsChampion Ecosystem. It was created to facilitate easy and highly compile time configurable implementation of binary communication protocols in C++ for embedded systems. I suppose you could use it to achieve your goal.
At first you use XML based domain specific language called CommsDSL to define your custom binary protocol, then you should use a code generator application called commsdsl2comms to generate a separate CMake project. The latter, may build the protocol analysis and visualization tools, which you could use to send your custom messages / packets and see the response. The CommsChampion Ecosystem is very well documented, you shouldn't have any difficulties navigating it and building everything that you need.
How to integrate other languages than those from .net world? For example to access messages from the bus in Java or C++? Do I have to listen to the queue in the backend instead? Is there a common Api provided by Rebus?
While Rebus may market itself as a "service bus"(*), it is actually more a kind of a "driver" with a common abstraction that enables .NET programmers to use various queues and persistence technologies without worrying too much about the specifics.
As such, Rebus cannot really be connected to, much as you would not be able to connect to, say, the NpgsqlConnection or the SqlConnection you would use to communicate with your Postgres or SQL Server database.
What you could do, was to interface with Rebus at the transport and/or persistence level, e.g. by using the same wire-level format when exchanging messages.
This would require that the chosen transport (MSMQ, RabbitMQ, SQL Server, etc.) can be interfaced with from the desired platform, and then you would need to be able to supply the correct headers for Rebus to accept the message as valid.
There is no official Rebus implementation for any other platforms besides .NET (.NET 4.5 + .NET Standard 1.3).
To my knowledge, no one has attempted to actually build a Rebus-compatible messaging library on any other platform.
(*) I actually usually use the word "messaging library" to describe it, because I think it carries way less confusion and semantic overload with it.
Yes. I think we need to know a minimal message format that an application for example PHP can compose and send directly to an endpoint queue. That would make life easy in certain cases.
I've used netty with udp and tcp protocols.
To my surprise it can be used with serial port as well.
Transport used is rxtx, there are a very few positive recommendations for rxtx.
Can netty be used with jssc instead of rxtx?
Should an application developer really care about the underlying implementation (rxtx or jssc)?
Should there be a problem developing in x86 then swapping to ARM?
There is currently no support for jssc, but you could write your own transport implementation using it.
As Norman said you could write your own jssc channel implementation to make it work with netty. However you may find ready libraries here below:
Original lib:
https://github.com/jkschneider/netty-jssc
My fork with some fixes:
https://github.com/tttomat19/netty-jssc
Regarding ARM/x86 question I believe jssc supports ARM, but I did not try it.
Regarding rxtx and jssc comparison I had unpleasant experience with rxtx performance and maven build.
I have a client which sends data via UDP-broadcast. (To let's say 127.0.0.255:12345)
Now I want to have multiple servers listening to this data. To do so on a local machine, they need to share the port 12345 for listening.
My question is, if that is possible, if there are any disadvantages and if there could be problems with this approach.
There is one alternative which unfortunately brings with a lot of overhead:
Implement some kind of registration-process. On startup, each server tells the client its port. The client then sends the messages to each port (having to send the data multiple times, some kind of handshaking needs to be implemented...)
Do you know any better alternative?
If that matters:
I'm using C++ with Boost::Asio. The software should be portable (mainly Linux and Windows).
You will have to bind the socket in both processes with the SO_REUSEPORT option. If you don't specify this option in the first process, binding in the second will fail. Likewise, if you specify this option in the first but not the second, binding in the second will fail. This option effectively specifies both a request ("I want to bind to this port even if it's already bound by another process") and a permission ("other processes may bind to this port too").
See section 4.12 of this document for more information.
This answer is referenced to the answer of cdhowie, who linked a document which states that SO_REUSEPORT would have the effect I'm trying to achieve.
I've researched how and if this option is implemented and focused mainly on Boost::Asio and Linux.
Boost::Asio does only set this option if the OS is equal to BSD or MacOSX. The code for that is contained in the file boost/asio/detail/reactive_socket_service.hpp (Boost Version 1.40, in newer versions, the code has been moved into other files).
I've wondered why Asio does not define this option for platforms like Linux and Windows.
There are several references discussing that this is not implemented in Linux:
https://web.archive.org/web/20120315052906/http://kerneltrap.org/mailarchive/linux-netdev/2008/8/7/2851754
http://kerneltrap.org/mailarchive/linux-kernel/2010/6/23/4586155
There also is a patch which should add this functionality to the kernel:
https://web-beta.archive.org/web/20110807043058/http://kerneltrap.org/mailarchive/linux-netdev/2010/4/19/6274993
I don't know if this option is existing for Windows, but by defining portable as an attribute for software which runs on Linux too, this means, that SO_REUSEPORT is OS specific and there is no portable solution for my question.
In one of the discussions I've linked it is recommended for UDP to implement a master-listener which then provides the incoming data to multiple slave-listeners.
I will mark this answer as accepted (though feeling kind of bad by accepting my own answer), because it points out why the approach of using SO_REUSEPORT will fail when trying to use it with portable software.
Several sources explain that you should use SO_REUSEADDR on windows. But none mention that it is possible to receive UDP message with and without binding the socket.
The code below binds the socket to a local listen_endpoint, that is essential, because without that you can and will still receive your UDP messages, but by default your will have exclusive ownership of the port.
However if you set reuse_address(true) on the socket (or on the acceptor when using TCP), and bind the socket afterwards, it will enable multiple applications, or multiple instances of your own application to do it again, and everyone will receive all messages.
// Create the socket so that multiple may be bound to the same address.
boost::asio::ip::udp::endpoint listen_endpoint(
listen_address, multicast_port);
// == important part ==
socket_.open(listen_endpoint.protocol());
socket_.set_option(boost::asio::ip::udp::socket::reuse_address(true));
socket_.bind(listen_endpoint);
// == important part ==
boost::array<char, 2000> recvBuffer;
socket_.async_receive_from(boost::asio::buffer(recvBuffer), m_remote_endpoint,
boost::bind(&SocketReader::ReceiveUDPMessage, this, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)
I'm building a Qt application that needs to use libssh, a SSH client library. libssh (understandably) performs its own network connections, however Qt has its own infrastructure for network connections (QTcpSocket etc).
Should I worry about these differences? Should I be trying to make libssh make network connections via QTcpSocket... Or if it works fine on the platforms I'm targeting, is that good enough?
The only downside is that you have another library that your code depends on.
The primary rule though is if it works, go with it.
I think it depends on how the abstraction you get from libssh looks like. If it is a socket-like API, you could create an QAbstractSocket implementation for it. If it is just some structure or handle to read from and write to, you could create a QIODevice subclass. Most I/O can be implemented generically operating on QIODevices (instead of explicitely operating on QFile, sockets, etc.).