I've to send a message over network using netty producer on machine A to netty consumer on machine B.
I have two NICs on machine A, and I want to use only the second. How can I set a Netty producer to bind the socket on the second NIC? Is it possible?
Thanks
If you are using UDP, you can use the option networkInterface to bind to a NIC by name. See the official Camel docs for this.
Consumer only. When using UDP then this option can be used to specify
a network interface by its name, such as eth0 to join a multicast
group.
Related
I have a TCP client and server running on Linux platform. Basically using setsocketopt I am able to mark SYNC packets. But I don't know how to apply DSCP priority to SYNC-ACK packet. I can set correct DSCP once socket is accepted on server but SYNC-ACK packet goes before application receives connected socket.
FYI, I also tried to apply DSCP on server listener socket. But Linux doesn't use that value for SYNC-ACK packets.
from this page, the SYNC_ACK is the same as SYNC which from client.
I am writing on UDP server/client application.
I want my single server to handle 40 clients at a time. For this, I want to create 40 dedicated threads, each dedicated for one single client. Since there are 40 threads one for each client, I want to create 40 dedicated sockets as well.
But the problem that:
I don't know what will be the 40 IP addresses to which I shall bind() my sockets. (since as far as I now, I have to bind() to my Server\s IP address.) Normally I bind() to "INADDR_ANY" when there is only single socket.
But what should be the IP addresses at which I should bind() each of my 40 sockets?
Please help me. Any comment/ help is appreciated.
One common way to do this with UDP is:
Server bind() to a well known port.
Client sends the initial packet to that well known port
Server receive the first packet from a client on the well known port.
Server creates a new socket with a random port
Server replies to the client from this new socket.
Client receives the reply, notices it comes from another port than the well known
server port, and uses that port as the destination for further communication.
You'll use the getpeername() call to learn the remote address.
Keep in mind that UDP is connection-less, you'll need some way to signal the end or time out you sockets.
bind only needs the local address, not the remote address.
If you want one socket for each client, then you'll need to use different ports for each (using bind). That way, each client can send its traffic to a dedicated port, and you can have a thread for each socket/port.
It's probably a better idea to only have one socket (and one port) though, and have logic in your code to assign traffic to a thread based on the remote address (retrieved using recvfrom eg.).
The usual way is to bind a single socket and accept incoming connections. Each connection will be assigned a unique socket by accept.
As you are using UDP, I would simply use TCP as described above to let the clients know of their respective server UDP addresses.
Create a single listening socket in a dedicated listening thread.
When it receives a new packet, use the packet's remote addr/port, or put a unique clientID in the packet payload, to uniquely identify the client.
Create a new thread for that client if one does not already exist, pass the packet to that thread for further processing, and go back to listening.
If a given client thread does not receive any packets for awhile, it can terminate itself.
This question might stem from a fundamental misunderstanding of IP multicast, so please correct me if I'm off base.
I'm trying to write C code to find the IP address of all the DHCP servers on the network. The use case is this:
Client broadcasts DHCP discover.
My proprietary relay agent picks up the packet, adds some essential information, and forwards it UNICAST to the DHCP server at a known IP address.
The problem I'm having is telling the relay agent where the DHCP server(s) is(are). I found that multicast address 224.0.0.12 is reserved by IANA for DHCP servers, so I figured I'd just configure the servers to listen for that multicast traffic. But whenever I configure a linux socket option to IP_ADD_MEMBERSHIP to 224.0.0.12, it uses IGMP, which is an entirely separate protocol which I don't want to have to implement.
Am I just misunderstanding how multicast works? Shouldn't I be able to send a ping from the relay agent to 224.0.0.12 and have it return a ping response from all DHCP servers?
Additional Info:
the interfaces on all the boxes do have MULTICAST listed when I do an ifconfig
I have added the multicast route using ip route add 224.0.0.0/4 dev eth0 on all boxes
Perhaps you should do what clients do - broadcast (not multicast!) on the target network with a DHCPDISCOVER packet? I have a couple of running, working DHCP servers and none of them are listening on the 224 network.
You'll probably also want to either request your existing address, or send along a DHCPRELEASE for any offers you get back, so as not to tie up addresses in fake reservations on the servers.
In a general IPv4 setting use broadcast to UDP port 67, not multicast. The broadcast request should be answered by all DHCP servers on your network. Take a look at the details explained on the Wikipedia page or read the broadcast explanation in RFC 2131, Section 3. Also see this thread.
In my own experience,I bind 1 socket and dispatch the requests to other threads.
But the famous web server nginx is bind() multiple sockets on the destination port.
What's the benefit to do it this way?
Looking through nginx source, I don't see that possibility. To quote from the man page ip(7)
When a process wants to receive
new incoming packets or connections,
it should bind a socket to a local
interface address using bind(2). Only
one IP
socket may be bound to any given local (address, port) pair.
So, I think that there is something else going on. Can you mention how you determined that nginx was doing this?
I have an application bound to eth0, sending UDP packets on port A to 255.255.255.255. At the same time, I have a UDP server bound to eth0, 0.0.0.0 and port A.
What I want to do is to make sure that the server won't receive messages generated by the application (handled purely in software by the kernel) but it will receive messages generated by other hosts in the network.
I can't change the payload of UDP packets nor add any headers to it.
I've already implemented a solution using RTNETLINK to fetch all IP addresses of the machine I'm sitting on (and filter basing on address from recvfrom()), but I'm wondering if there might be a simpler and cleaner solution.
EDIT: I thought about something like tagging the skb - the tag would disappear after leaving a physical interface, but wouldn't if it's just routed in the software.
Any ideas?
If you can patch your Linux kernel, you could use a setsockopt() option for choosing if you want to loopback the broadcast packets you're sending or not.
This patch reuse the IP_MULTICAST_LOOP option exactly for this purpose.
Also, instead of "messing" with the IP_MULTICAST_LOOP option, you could easily add your own setsockopt() option, maybe called IP_BROADCAST_NO_LOOP. This would guarantee that you're not changing the behavior for any other application.
You can compute a checksum or CRC (better) over the payload and filter against this.
You can do this at the firewall level by dropping packets to broadcast address port A with source address of the eth0.