I am looking for some hints to build a network packet splitter. What i want is some sort of tools/code that split the packets of a logic link (tcp/ip connection for ex.) over several network interfaces.
I used with success the Linux bonding driver, however the best performance is only achieved when the bandwidth/latency of the several network interfaces is similar, since the bonding driver uses round robin packet splitting.
Anyone know any tool that can effectively split packets (not logical links) over network interfaces using a weighted manner, instead of round robin manner?
You can use sysfs to change your bonding mode to a more effective choice for your setup.
/sys/class/net/bond0/bonding/mode
You may have some luck also changing the queue_id in the same place to make different adapters more important.
Take a look at the Linux bonding documentation for information about the settings.
Related
I would like to communicate over USB using COAP protocol.
I am currently planning to use libcoap, it has examples but it is based on UDP server-client.
If I want to use USB, what must be done?
Thanks
Depends a bit on the deployment scenario, but in general I'd recommend using USB Ethernet inbetween (CDC-ECM). Then you can use CoAP over USB like you use it over any other network connection. (If you use RIOT for your embedded device and build the gcoap example on a board with native USB and enable the usbus_cdc_ecm module, you get that almost out of the box).
The large downside of this approach is that you are subject to the whims of the host OS's network setup. Probably it'll take up at least the IPv6 link-local interface so you can go ahead with requests to fe80::addr:ess (or even use link-local multicast to find your device), but there may be pitfalls.
There is the slipmux proposal which would do CoAP over serial, but a) I don't know implementations thereof, and b) it leaves you with similar issues of how to make sure your application can really find the right serial port.
It wouldn't be impossible to specify CoAP over custom USB commands (which would then be taken up by an application), but there'd need to be really good reasons not to just go through USB networking to justify them, and I'm not sure that the complexity of ensuring that your NetworkManager is set up correctly counts.
I am still trying to understand DDS and its concepts.
I have a configuration where 2 laptops run dds based application. My environment does not permit multicast so I decided to go for peer to peer connection(unicast). To bring both the laptops in the same network, I connected them using ethernet cable (Not sure if it was necessary or not).
Now I did not change anything in the QoS i.e. i did not do any settings for unicasting. But now my applications are communicating with each other.
Question :
How are the participants being discovered ? Multicasting ? as I did not do any settings for unicasting.
Was it necessary to bring them under one network i.e. connect with ethernet cable if I wanted to use unicasting ?
EDIT :
Configuration is as follows :
First laptop : Windows OS : Native DDS based application : Publisher : Multicast not allowed.
Second Laptop : Linux : ROS2 based subscriber : Multicast no problem
Out of the box, DDS is required to support Multicast and Unicast Discovery. Anonymous connections are handled through multicast. If you know the IP address of the recipient, you can manually configure those addresses into the unicast discovery list (each vendor will have their own way to name/process this list).
"Multicast is not permitted on our network", in most cases, means that your IT department has turned off multicast packet forwarding at the switch (or the switches) that define the fabric that is your network.
The as-shipped, standard-compliant DDS configuration, however, has no knowledge of this local policy (how could it?). If you haven't changed the configuration in line with your local policies, the DDS Participants are still going to try to connect via Multicast, because you haven't turned it off.
If the DDS-using machines are connected to the same hub, or to an unmanaged switch (defined here as one that your IT department doesn't care about, or is misconfigured), and the network topology does not cross a managed switch, and they are using the default configuration, and they find each other, then they are using Multicast anonymous discovery.
Figure out how to configure your DDS implementation, to add the unicast ip addresses of the machines that need to communicate. Because discovery is usually only needed in one direction (if A discovers B, then it is true that B has discovered A, assuming neither A nor B are configured to ignore the other[1]).
Once you have configured for unicast discovery, you can configure for no-multicast. If the machines are on IP hopping networks (WiFi, etc) it will be difficult unless the DDS implementation understands multipathing. Talk to the vendor to see if this is the case.
[1] DDS is nothing if not overly configurable.
How are the participants being discovered ? Multicasting ? as I did not do any settings for unicasting.
It is not possible for me to answer this question with complete certainty since you are using DDS as part of the ROS2 framework and I am not familiar with the exact details of how the two are set up to interact together. Having said that, from your description it does seem that the participants are indeed using multicast to discover each other.
The best way to get a conclusive answer is by sniffing the network -- assuming that you have the required privileges to do so. For example you can use Wireshark , which comes with an RTPS dissector that allows you to filter on RTPS messages. (RTPS is the name of the standardized DDS wire protocol.) Check out the destination address and see if you detect any addresses in the multicast range. You can do this while firing up a single DDS-based application. It will start announcing itself over the network immediately.
Was it necessary to bring them under one network i.e. connect with ethernet cable if I wanted to use unicasting ?
If you want to use unicasting, you will need to know IP addresses or host names of all peer nodes. As long as those peer nodes can reach each other over UDP, you are good to go. Often, but not always, ping will let you know whether this is the case. Firewalls are a typical cause of problems.
However, be aware that different types of network have their own specific properties that you might have to adjust your configuration to. Over WiFi for example, the likelihood of packets being dropped (especially with bursts of data) is much larger than when connecting nodes directly with a wire. DDS allows for tuning its protocol to deal with that.
is it possible to bond (aggregate) multiple connections over GPRS (usb stick) and use it as one link in linux?
It is technically possible. Linux has a module called bonding which can assemble several interfaces into one logical interface. If you set the mode of the bonding interface to balance-rr, it will distribute the packets between the two interfaces. You will also need a server somewhere to reassemble the traffic that will come from your two links.
However, in practice the results with such setups are awful, especially with high latency and high jitter links like GPRS. The main reason is that you get a lot of out of order delivery and protocols like TCP become crazy in these conditions. So the resulting throughput will never reach the total throughput of the two links.
I am working on fpga firmware, in which i want to have very fast data transfer using ethernet . I got help from FPGA forum they say that suggest designs for data transfer using light weight internet protocol (LWIP).
How this is different from transfering the data using NDIS. I will be grateful if you can suggest me some guide to interface my visual c++ application to the network guide and tranfer the data.
many greeting in advance.
LWIP is a library for talking IP on a network.
NDIS is a specification for how an OS talks to network cards.
Neither is necessarily what you appear to want.
If you want to transfer data very simply and quickly point-to-point using Ethernet, you need to understand how Ethernet works at the packet level, and form your data into some Ethernet packets. You can make up your own protocol for this if you have control over both ends of the link.
If you want to transfer the data over an existing network topology, you would be better doing it using an existing protocol. UDP/IP might be one such protocol, depending on your requirements for data-rate, latency, software complexity, reliability etc. LWIP is one library which implements UDP, so might be of use.
I am writing a Linux device driver which supports multiple devices. I have a x8 PCIe card with 4 of these devices on it. Each runs through a PCIe switch and gets 2 PCIe lanes. Is there a way to have the driver write to multiple lanes at the same time? If so, how would I do this? I would think it should be possible since it is all on one PCIe slot, but I have no idea how this would be done from the driver.
PCIe doesn't work quite the way you think it does. The switch is not partitioning up the upstream x8 link into multiple x2 links -- it simply forwards traffic from one link to another. So what you will see is a x8 link to the switch, and then 4 x2 links from the switch to the downstream devices. However with a different switch and different downstream devices, it would be equally possible to (for example) have x8 links everywhere, ie a x8 link from the root port to the switch and x8 links from the switch to the downstream devices.
However, in your case you have a matched amount of bandwidth on both sides of the switch, so there should be no issue with devices competing for a limited amount of bandwidth. Your driver can talk to all the devices simultaneously as efficiently as if there were independent links.
It sounds like you're looking for PCIe multicast. This has no connection to the number of lanes, but would simply be a function of delivering a single write to multiple destinations as efficiently as possible. There is a standard for this, mostly intended for backplane uses, see: http://www.pcisig.com/developers/main/training_materials/get_document?doc_id=12f5c260ccf5e054366d4c96ee655fa6827db5b3
It looks like this is supported with a new PCI BAR type, where multiple devices would have the same mapped physical address range, and the switch would also be configured to know about this multicast range. But this all needs OS support, and I haven't found anything on the web to suggest that Linux has the pieces necessary to configure the devices to do all this.
Since your parent link has enough bandwidth to saturate all four child links, you don't have a throughput problem. The only thing you'd save with multicast is bandwidth from the memory subsystem. If you have a modern architecture, the amount you'd save would be in the noise.
In other words, don't worry about it. Treat your devices as independent (this will make for a cleaner driver, anyway) and get on with your project.