Is there a way to get amount of bytes received/sent by a network interface using Qt on a Windows platform ? If it is cross-platform is even better.
I couldn't find anything useful in QtNetwork module.
The lowest OSI model layer which Qt can manage is the transport layer (maybe the layer 3 but I don't think). You can only get the number of received/sent bytes from/to a given port.
If you want to "sniff" the whole traffic on your interface, you should use a library based on pcap (winpcap for Windows, libpcap for GNU/Linux).
Related
I am currently learning about networking. I am going through the TCP IP and OSI model and try to pick apart what protocol belongs to which layer. I am a bit confused over Media Access Control. Does it just refer to the hardware id of the network card or is it the name of the protocol responsible for it? I tried to find any RFCs for MAC on IETF to provide some definitions for me, but I couldn't find anything.
"MAC" stands for media access control - it's a sublayer of the data link layer (L2) in the OSI model.
One of the most popular protocols in this layer is Ethernet which covers the physical layer and the data link layer. You can find all about Ethernet at IEEE 802.3 (requires registration but is free).
Another extremely popular L1/L2 protocol stack is WiFi (IEEE 802.11) but that's a lot more complicated and hard to start with.
No, the MAC is not a protocol in that you won't find any 'MAC spec' that you can implement. MACs are typically embedded in hardware devices and expose functionality to send and receive frames to the media that they're controlling.
How they expose that functionality is up to the manufacturer of the MAC. They don't follow any standard protocol. You might find simple SPI interfaces, register-based access, DMA transfer or others.
So here is the thing, I want to conceive a universal BUS CAN adapter using stm32 with a desktop interface using Qt.
Still in the conception phase, I'm wondering how to treat the frames coming from the stm to PC GUI, weather 1) as a USB frame; in this case, how to encapsulate and decapsulate them into CAN frames and is there a Qt library to facilitate the job, or 2) as a CAN frame in this case I found the QCanBusDevice and QCanBusFrame Class which seem to be so helpful but in this case a CAN plugin must be specified during the object creation. So what should i do?
It doesn't really matter what you do because you're designing a custom protocol that rides on top of USB. Here you have an option of implementing a USB communications class device so that you don't need custom drivers nor libusb - especially given that the performance of libusb on Unixes is abysmal.
Once the data is available to the userspace, you can access it using QSerialPort. You'll have to frame the CAN frames somehow, as serial port is a stream-oriented transport and doesn't know of any packets. Most trivially, you can encapsulate the frames using RFC 1662 HDLC octet-stuffed framing. You can encapsulate the commands to your device, and their responses, in the same fashion, using one of the fields, e.g. the ADDRESS field, to multiplex CAN data and commands/responses.
If you now wish to expose this device to the Qt Serial Bus framework, you'll have to write a custom CAN plugin to access it.
To give some idea of how much code this is: total for Qt code and microcontroller code should be well under 1500 lines for a proof-of-concept. A minimal demo would be probably <400 lines of Qt code and <400 lines of STM32 code.
I want use Alljoyn to communicate between devices in smart factory.
However,it seems there is no such use cases not yet.
So,i want to know if Alljoyn can't be used in factory for some technical reasons,
for instance,stability or performance.
In my case, I need device can communicate directly.
So,publish-subscribe-based protocol,like MQTT,wouldn't work for me.
I don't get the specific problem of your case. But I'm going to answer anyway.
AllJoyn runs on the proximal network (local network) by using Wi-Fi, Ethernet or Power Line (PLC). And AllJoyn does not require a cloud to function, cloud network connection is optional. It works in your case as long as the local network functions properly.
Transport name Value Description
TRANSPORT_NONE 0x0000 No transport.
TRANSPORT_LOCAL 0x0001 The local transport.
TRANSPORT_TCP 0x0004 Transport using TCP as the underlying mechanism.
TRANSPORT_UDP 0x0100 Transport using UDP as the underlying mechanism.
TRANSPORT_EXPERIMENTAL 0x8000 Select a release-specific experimental transport.
TRANSPORT_IP 0x0104 Allow the system to decide between TCP or UDP.
TRANSPORT_ANY 0x0105 Allow the system to choose any appropriate transport.
AllJoyn supports both TCP/IP and UDP/IP transport mechanisms. While developing your app, you can decide to use which transport mechanism you want.
AllJoyn documentation states that;
If an AllJoyn application desires to only use TCP as the underlying
layer 4 mechanism, it can do so by specifying TRANSPORT_TCP in
advertisement, discovery and Session join and bind options.
As TCP guarantees all sent network packages will reach their destination in the correct order. In your case you can choose TCP communication as a more reliable option.
Could i inject packets to Linux TCP stack without modifying the ethernet driver? Could i do this with using a library or sth ?
Thank you,
If by 'inject packets to Linux TCP stack' you mean send some data that the Linux kernel will treat as a frame coming from an Ethernet interface then you can use a 'tap' device. If an IP packet (layer 3) is good enough, then use a 'tun' device.
http://en.wikipedia.org/wiki/TUN/TAP
http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/networking/tuntap.txt
Libnet
Libnet is a generic networking API that provides access to several protocols. It is not designed as a 'all in one' solution to networking. Currently many features that are common in some network protocols are not available with Libnet, such as streaming via TCP/IP. We feel that Libnet should not provide specific features that are possible in other protocols. If we restrict Libnet to the minimal needed to communicate (datagram/packets) then this allows it to support more interfaces.
Otherwise, if you're just wondering about injecting hand-crafted packets into the network, read the man pages and look for online help with raw sockets. Some good places to start are man 7 raw, man packet, and there are some ok tutorials at security-freak.net, though the code there is not written particularly well for my tastes.
I'm doing a project where I must write a network library for a device connected to a Windows machine. The complication comes in that I may only communicate with the device using ethernet frames. So there is no TCP/UDP/IP at all. I don't think the bind/listen/accept approach can be applied here, but maybe I am wrong. Also, there is no routing or switching involved.
I have a few questions. How do I use a socket to communicate with this device? Does winsock have any support for just frames? I haven't been able to find many resources on this. Does anyone have any ideas about how I should proceed?
Is using sockets even a good idea or can I just send out the information with the appropriate headers?
Use WinPCap, it has an an API to send and listen to raw data.
You can build your communicate layer with it.
Give the WinAoE code a look-see - it says it lets Windows talk to ATA over Ethernet devices which means it has to communicate without any of the upper layers of the network stack.
Edited:
As near as I can tell, if you want to send raw ethernet frames, you want NdisSend and friends.
As well as winpcap and NDIS you could also look at raw sockets which are a standard part of the Windows API and don't require you to write driver code http://msdn.microsoft.com/en-us/library/ms740548(v=vs.85).aspx.