Currently I have a process listening and processing a multicast data stream. I'm thinking about seperate it into two processes, one listening, one processing, both will subscribe to the multicast traffic.
my question is, will this lower the efficiency because now there are two listener to the multicast stream?
You are doing more work so by definition it is going to be less efficient. The better question is whether it really matters, and the answer is probably not.
Well, if you make it the way that the listening process will be restarting the processing process in case of crash it makes sense.
It will not be less efficient as you have already two listeners.`
Yes, this will be less efficient since the kernel will have to make a copy of each datagram to each socket listening to the multicast group.
Related
I realize it's a bad idea to rely on the UDP protocol to provide any sort of ordering guarantees and TCP should be used instead. Please refrain from answers suggesting I use TCP.
I am debugging some legacy networking code and was wondering what are the ordering guarantees provided by the socket interface. The setup I have consists of a linux box running Debian talking to an embedded device over a direct ethernet cable. The embedded device cannot fit an entire TCP stack and even if it did, the legacy stack is too old to refactor.
Specifically, if I have a NIC configured with the default single pfifo_fast, and I am sending packets over a single socket, using a single thread, and they all have the same ToS, under these conditions, am I guaranteed that all my packets will be sent over the wire in the order I send them?
This is the behavior I observe in practice but I haven't found any standard, POSIX or otherwise that guarantees this behavior and I would like to make sure this is in fact supported behavior under the environments and assumptions I listed above.
In contrast, if I send my packets over two separate sockets I observe that they are not sent over the NIC in the same order I sent them from the application code. It's clear that the kernel is reserving the right to re-order packets sent over separate sockets, but refrains from doing so when using a single socket.
As I understand it, calling send() on a socket places the packet into the appropriate queue for the NIC synchronously. The existence of a queue suggests to me a notion of order (otherwise a list would be a more appropriate name for the data structure). Whether or not such ordering guarantees exist, I am interested in some sort of documentation or specification stating so.
There's no guarantee of this behavior because in the general case it would be irrelevant, as user207421 mentioned. POSIX, or even Linux for that matter, wouldn't guarantee that behavior because it necessarily constrains the implementation for an extremely uncommon case. Reordering packets for various reasons is common, and allowing Linux to do that for performance or other reasons (e.g. packet filtering or QoS) improves throughput.
Even if the sender did guarantee this behavior, the receiver could still experience an overfull buffer or temporary network hardware issue that would prevent the packet from being received properly, so any guarantee on the sending side would still be meaningless. You just can't rely on in-order delivery of UDP packets without a higher-level protocol on top, no matter what.
If you need in-order retrieval and retries but can't use TCP, look at QUIC for an example of how to do it. You may (or may not) want to implement the crypto portion, but the protocol layering may be helpful.
I'm breaking a big application into several processes and I want each process to communicate with each other.
for now it's gonna be on the same server, but later several servers on same local network will have several processes that will need to communicate between each other. (means service on one server, with service on other server on same vpc)
so.. my raw options are tcp or unix sockets. I know that with Unix sockets can be useful only if you're on the same server. but we're thinking about writing our own implementation that on same server processes will communicate on unix sockets, and between servers that will communicate using tcp.
is it worth it ? of course tcp sockets are slower then unix sockets.. cause it doesn't go through the network and doesn't get wrapped with tcp related data. the question is by how much ? I couldn't find online proof of benchmarking between tcp and unix sockets. if tcp adds 3%-5% overhead that's cool, but can it be more then that ? I'd like to learn from experience of big projects.. of other people over the years, but didn't find anything relevant.
next...
our project is a NodejS project.
some people may say that I can use a broker for messages, so I tried using nats.io compared to node-ipc (https://www.npmjs.com/package/node-ipc) and I found out that node-ipc is 4 times faster but nats has the cool publish-subscribe feature... but performance is important.
so I have tons of options, no concrete decision.
any information regarding the issue would be greatly appreciated.
The question is actually too broad to answer, but one answer for TCP vs unix domain sockets:
Architect your code, so that you can easily move between those if necessary. The programming model for these is basically the same (both are bidirectional streams of data), and the read/write APIs on OS level as well as in most frameworks is the same. This means e.g. in node both will inherit from the Readable/WriteableStream interfaces. That means the only code that you need to change for switching between those is the listener on the server side where you call the TCP accept APIs instead of the unix domain socket accept APIs and the other way around. You can even have your application accept both types of connections and later on handle them the same internally.
TCP support is always nice because it gives you some flexibility. With my last measurement the overhead was a little bit more (I think 30% versus TCP over loopback) but these are all micro benchmarks and it won't matter for most applications. Unix domain sockets might have an advantage if require some of their special functions, e.g. the ability to send file descriptors across them.
And regarding TCP vs NATS & Co:
If you are not that experienced with network programming and protocol design it makes sense to use readymade IPC systems. That could be anything from HTTP to gRPC to Thrift. These are all point-to-point systems. NATS is different, since its a message broker and not RPC. It also requires an extra component in the middle. Whether this makes sense totally depends on the application.
I have an embedded system that can be treated as an Access Point. There's a program that runs in that system and performs some network communication with devices connected to that Access Point. It is sending UDP packets containing some diagnostic information (a data structure) and receiving commands. The problem is that sometimes some fields of that outgoing data structure are not filled with data (eg. there are zeroes or some garbage). I need those fields to be correctly filled every time and I know what values should be put there.
Another task that I need to accomplish is to filter incoming packets that come to this program (I know what ports it listens on) - usually I need to simply pass them, but occassionaly (eg. when I get some information from sensors) it is necessary to completely replace them with new packets that I would generate.
I have several ideas varying from some smart usage of iptables and pcap to writing my own kernel module. I do not own sources of that embedded application so I cannot embed this functionality in its code. Performance is a crucial thing here, and I'd like to hear your suggestions: what should I go for? Writing my own kernel modules seems to be the best solution to me, but I have no experience in network hacking so maybe there are some other ways that are better suited for this problem. Any opinion will be highly appreciated!
One standard approach is to use libnetfilter_queue to intercept and modify packets directly. You should at least try this before attempting to write your own kernel modules.
You could do it in userspace. Just write a server that receives the packets changes them and send them again out. You have to configure the application just to use your localhost as destination ip (or configure your system that it has the target address). Its a typical "man-in-the-middle" setup.
Are there any tools to dynamically and graphically display the iterations between a bound socket and connected clients? Debugging issues in sockets with multiple simultaneous interactions can be a huge mess, I would think that displaying the interactions graphically would be a great help to understanding what is going on in a server's interactions.
I'm unaware of graphical applications per se.
However, tcpdump or (for those who require a GUI) wireshark are pretty good at showing you the packets being sent, which is what you actually want here in general.
If looking at the big picture is enough for you - process hierarchy and the connections (TCP socket, Unix domain socket, pipes) between them - you can give a try to ipcvis:
https://sourceforge.net/projects/ipcvis/
The tool records process hierarchy and socket information for distinct states and then visualize new relations from state to state:
http://youtu.be/8XFKwzkexQY
I need to close all ongoing Linux TCP sockets as soon as the Ethernet interface drops (ie cable is disconnected, interface is down'ed and so on).
Hacking into /proc seems not to do the trick. Not found any valuable ioctl's.
Doint it by hand at application level is not what I want, I'm really looking for a brutal and global way of doing it.
Did anyane experienced this before and willing to share his foundings ?
The brutal way which avoids application level coding is hacking your kernel to activate TCP keepalive with a low timeout for all your connections.
This is rarely needed and is often wouldn't work. TCP is a data transfer protocol, unless there is data loss, nothing should be done. Think twice why you ever would need that.
Otherwise, you can try to periodically poll interface(s) and check for the UP flag. If interface looses UP flag, then OS already reacted on cable being unplugged and down'ed the interface. man 7 netdevice, see SIOCGIFFLAGS for more.
Network drivers also generate an event on even when cable is plugged, but I'm not sure whether you can access that or not from a user. You might want to check the udev as its documentation explicitly mentions network interfaces.