I need to make peer-to-peer communication between applications.
The applications also shall find each other automatically in internet. For this, among other things, I need to overcome NAT Traversal, etc.
As example, I need to use the communication something like following:
InternetPeer peer;
peer.setName("my_name");
peer.listen(); // accept connections
peer.startSearchForOthers(); // find another peers
connect(&peer, &InternetPeer::newConnection, this, ...);
connect(&peer, &InternetPeer::anotherPeerFound, this, ...);
QStringList peerNames = peer.availablePeers();
peer.sendMessage(peerNames.at(0), "Hello");
peer.close();
Then it would be good to have some way to access such a connection with QTcpSocket or QUdpSocket.
How this can be done on Qt and c++?
Related
I have a configured DBC in CANoe with CAN messages and mapped signals. Now I would like to send the messages configured in the DBC in my simulation via Ethernet/TCP and still keep the signal mapping. The two ECUs are activated in the CAN and Ethernet networks. The transmission of general TCP messages works.
So far I have not found a working approach. Do you have any ideas? Are there ways to keep the signal mapping?
There are at least two projects that allow you to send CAN messages over Ethernet:
socketcand
cannelloni
There are also Applications that allow you to send/receive CAN-messages using these protocols and that support DBCs:
SavvyCAN supports socketcand (disclaimer: I implemented this support myself)
CANdevStudio supports cannelloni (I haven't tested it)
Both will keep your signal mapping intact.
If you specifically want to achieve this with CANoe, you might have better luck contacting Vector.
I currently have an idea rolling around in my head about how to abstract away (to some degree) common data transfer mechanisms of embedded systems such as CAN, UART, SPI, I2C, Ethernet, etc. Ideally I would want to have something like the concept of a Pipe, but that the interface doesn't really care about what physical medium/protocol the data is flowing over. If I say "transfer this data through the pipe", it just works. Obviously there would have to be some protocol specific details in the construction of this pipe object but outside of that it shouldn't matter.
Is there an industry accepted name for what I'm trying to do?
Is this concept even a good idea? I feel like it will be useful for my purposes but I don't know if it's pointless in the grand scheme of the embedded engineering world.
Is there an industry accepted name for what I'm trying to do?
Hardware Abstraction Layer (HAL) comes closest. Keep in mind that the mentioned buses are hardware standards that don't define higher-layer protocols. At higher levels, this might be called "sockets", though that typically refers to IP specifically.
Is this concept even a good idea?
Probably not, unless you have specific requirements.
For example, it would be a good idea if you wish to replace an old RS-485 network with CAN but maintain the old hardware. It would then make sense to have as much of the software compatible as possible in that specific project.
Otherwise, from a general point of view, each of these buses are picked to suit quite different requirements. CAN when you need rugged & reliable, UART when you need backwards-compatibility, SPI when you need fast, synchronous, close-to-metal on-board communication, Ethernet when you need fast communication over long distances etc etc. The hardware requirements of one bus might exclude another.
For example, if I want my MCU to communicate with a "dumb" LCD, only SPI makes sense. I might have to toggle additional I/O pins together with the SPI signals. I might want to use DMA. Etc. In that context, there is no benefit for me if I have to use an abstract communication API which is portable to CAN, Ethernet etc. That's just bloat - this code will never run on any of those buses!
It makes far more sense to develop a HAL per bus type, so that you have one SPI HAL which is portable between microcontrollers. That's common and actually useful.
Pipes are commonly used for IPC (inter process communication) or redirecting output to a file or ... For all this exists remote technologies, 'remote' means over the network or over an interface or bus like RS232, SPI, ... The name for remote IPC is remote procedure calls (RPC), see https://os.mbed.com/cookbook/Interfacing-Using-RPC and https://github.com/EmbeddedRPC/erpc . Like with all IPC, security is a major problem, especially over a network.
I.e. writing a remote file (over TCP/IP) can be done like in https://askubuntu.com/questions/917200/how-to-redirect-command-output-from-remote-machine-to-local-file-via-ssh
The SSH login you can wrap into a function and this function to get the commands shorter (macros can also be used for wrapping a function Wrap function call with macro)
There are also various implementations of communication protocols over each other i.e. Ethernet over USB (https://en.wikipedia.org/wiki/Ethernet_over_USB)
How (GA) Global array library (an implementation of ARMCI) is used for communication between two process located on different remote machines.
Is that something similar to TCP socket programming where one process wait for data and the other transfers it ?
I try to see the documentation that ga_put() and ga_get() are two operation that used for inter-process communication. till now I only able to come up with a program running on the same machine that use shared-Memory architecture (I have used ga_put() and ga_get() to put data in Global array and to get it respectively ).
Now, I want use this program for communicating data (basically performaning one-sided communication) between two remote processes. Obiviously putting the program that I am running on single machine on the remote side will work out. It needs some way to tell which machine should we access and get the right data. And here is where I need your help. how can I do this? (what is its equivalent of TCP/IP listen, accept and connect ... on GA ? )
Or is that the case that GA also uses TCP/IP socket underneath ?
can some one please explain to me? and sample code of two remote processes communicating is also appreciable.
thanks,
I am answering my question after all. May be it will help some one looking for the same issue.
GA Library is implemented to work with MPI. So we have something like:
MPI_Init(..)
GA_Initialize()
MA_Init(..)
// .... do sothing here
GA_Terminate()
MPI_Finalize()
The answer to my question is:
MPI has the following primitives to be able to support client-server commuication:
//in the server side
MPI_Open_port()
MPI_Comm_accept()
//do MPI_Send() or MPI_Recv()
MPI_Close_port()
//client Side
MPI_Comm_connect()
//do MPI_Recv() or MPI_Send()
depending on the hardware support and the MPI implementation used, MPI might use sockets, or other mechanisms (e.g SAN (System area network)).
In general, most MPI implementations use sockets for TCP based communication.
So, yes GA also uses sockets underneath (of course depending on the MPI implementation used)
cheers,
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.).
I have an application that is being built using Qt. It will be running on machines that will have two (or more) network cards. I need the ability for my application to select which ethernet interfaces for a TCP connection. Before anyone suggests it I cannot guarenteed that routing tables will be setup correctly. I know how to do this using the windows socket classes but have been unable to find anything about it for Qt. Any help would be greatly appreciated!
Are you referring to an outbound connection or an inbound connection?
If you're referring to an inbound connection, all you need to do is specify a QHostAddress to the QTcpServer::listen call.
If you're talking about an outbound connection, you can call QAbstractSocket::setLocalAddress to force the local address to something specific.
Cheers,
If you are using Qt 4.2 or later, you can use QNetworkInterface to get a list of network interfaces in the computer and then create some sort of network interface selection.