I am trying to implement Dbus client. Dbus server is actually implemented by a third party and I do not know what bindings does it use (but I guess gdbus). Now can I use QDbus bindings in my client application irrespective of whatever bindings used in Dbus server?
If so, how are the data types (w.r.t. complex data types/user defined structures) managed between server(e.g. glib types) and client(e.g. qt types)? Explanation of this concept would be greatly appreciated.
All types on the DBus have DBus types, the bindings simply translate them into their own format. For example, a uint32 type is an unsigned int in C/C++, and in the Java bindings it's a UInt32.
Basically, all implementations need to know the wire format of the message. As long as they understand that format, it doesn't matter what higher-level data type that is translated to. I wouldn't really call them complex data types, because you can only send basic data types across the bus.
Related
I have to serialize some data and after send it using socket AF_UNIX.
I have read (here) that I can't create a struct and just send it using a cast (void *). So, I would like to know which is the best method to handle this problem.
Thank you!
You basically have two options:
Roll your own exactly as in the question you referenced.
Use an off-the-shelf serialization/deserialization system. If you go this route, Google's Protocol Buffers are pretty much industry standard. For constrained projects (embedded, etc.) nanopb is a good choice for the implementation.
I have been working on some embedded software. This software is divided
into two main parts. The first one is the application software and the
second one is some system software. The system software consists of
set of drivers and RTOS. I have been developing the application part and
I have been using the prepared drivers. Among the drivers there are also
drivers for CAN communication. One of the functions has the following
interface
result_t can_set_receive_callback (can_receive_callback_t cb);
Along with this function there is also following definition of pointer to
function
typedef void (*can_receive_callback_t) (can_message_t msg);
I have problem to understand how to use the driver function. I know
that I have to define some function with following interface
void my_function (can_message_t m);
I also know that the function defined above is so called callback function.
But I don't know why I have to define the callback function.
Why is it not possible to simply call the driver function without no function pointer passed as an argument?
Does it mean that callback function defined by me "says" how to process the received messages? What is the information which is unknown for the drivers developer?
I meant that the receiving messages are
processed by prepared interrupt service routines but none of the mentioned
functions looks like an ISR.
Can anybody refer me to some good document where
this type of work with drivers is described? Thanks a lot.
OSI model speaking Drivers are supposed to manage the communication on the physical level.
So the driver perform communication device activation, configuration, read, write etc. to manage the HW to communicate on your bus (CAN).
Data link layer is responsible for managing the "protocol" of data sent and received on the bus.
So the driver developer require data link layer developer to set functions that will be called (callbacks) when a specific event is triggered by physyal layer.
In other words, in your specific case, you must set a callback that manage received data based on your protocol with its peculiarity (structure, timings, etc...)
I have a Windows UI, written in C#, that calls a DLL, written in C.
Data is exchanged between the C# UI and C DLL using the marshaling techniques available through pInvoke. Both the UI and the the DLL are legacy code.
All of the software runs on the cloud; specifically, on Amazon Web Services (AWS). But it is portable to any cloud service provider (Azure, Google, etc).
I need to write a new piece of C code ("NewCode"), that runs on a separate AWS (or other) instance, that does nothing except read data from a proprietary database and service data requests from the existing DLL.
For lots of reasons, this NewCode needs to run on its own instance, so that it has its own, exclusive access to memory, cpu, and disk. Newcode needs to service a variety of data requests: a single number, a char string, an array of numbers, array of strings, etc. NewCode will be portable C, so it can run under Linux, Unix, etc.
My question:
What are my options for having the existing C DLL communicate with NewCode? I know it is too broad a topic to ask for a list of options and their relative merits, so all I'm asking for here is to what should be on the list so I can begin my research. I am a complete newbie in this area, but so far I have determined that on the list should be sockets and pipes. What else should be on the list?
Since NewCode will be communicating over the network, I would look into protocol buffers. Protocol buffers would likely be the most efficient for communicating between to processes on separate machines who may be running different operating systems. There are protocol buffer implementations for many different languages, all of which use the same predefined structure definitions.
Of course, there are other options, like XML, JSON, or your own binary protocol.
https://code.google.com/p/protobuf/
I'm working on socket programming. The client has to send a structure variable to the server. How can I go about it? I have created the server and the client and I'm stuck at this point.
PS: I'm coding in C.
Use write on the client side and read on the server side?
I think you have to be more precise..
Is it always the same data structure? if not how do you know which message you receive?
Assuming you're trying to send an instance of a struct, you could just send the binary data up (write the struct with the size of the struct). This assumes that you don't have any pointers in the struct, and that your struct definition matches perfectly on both sides (same bit alignment as well).
This is not very portable, and makes quite a few assumptions.
The better option is to encode the data into a standard format. I like JSON, mostly because it's simple and there are tons of parsers for it. You would encode the struct as JSON (see http://json.org/ for libraries), send it over the socket, and decode it on the other side.
You'd need to also send how big the data is, so you may need to come up with a simple protocol (first 4 bytes are the size of the JSON data, then send the JSON data).
Custom protocols are pretty terrible, so you may want to look into a standardized protocol. If you just want to send binary data over TCP, consider the WebSocket protocol. It's basically what I described, but a little more flexible.
This is what I do, and it works pretty well.
I have a system that processes messages from various sources and I put a MIME type on each incoming message which is used for dispatching further down the line.
One type of messages coming in is data frames from a Controller Area Network (CAN). Now, this data usually isn't transmitted via HTTP or email etc., so Wikipedia or the standardizing organizations don't give a MIME type, at least not in an obvious place. Google couldn't help me, either.
For now, I'm just going with some made-up "application/vnd.*" MIME type, as I already do with some internal protocols. This is kinda OK, but it's not really correct, and if anybody knows of an existing MIME type, I would prefer to use it.
CAN is only defined for OSI-Layers 1 (Physical Layer) and 2 (Data Link Layer).
MIME (Multipurpose Internet Mail Extensions) is somewhere around Layer 6 (Presentation Layer) and will only describe informations from the layer above number 7 (Application Layer) or maybe it's own layer.
So it would not make any sense to have a MIME type for CAN as a bus technology, because you are interested in "what is transfered" and not in "how it is transfered".
If there would be a MIME type for CAN, you would also need one for Ethernet, WiFi... smoke signals :-)
Of course you can define and encode a MIME types for your information you transfer over CAN. But then these are related to your data transfered and not to CAN itself.
It would also be possible to run IP and HTTP protocols over CAN, but this is no common usecase.