Below my infrastructure:
[ Packet Sender Machine ] -------> [ S W I T CH ] ----------> [ Client Machine ]
Now let's say I have 10 different applications running independently in my Client Machine and each one of them has joined the same multicast group to receive the packet being sent to the multicast group.
Question: Does the SWITCHsend 10 copies of the packet to the Client Machine? Or does it send only one and the network card in the machine distributes to all 10 applications? Does it matter? Should I code a PROXY on the Client Machine so that only one packet in transmitted to the PROXY and the 10 applications connect locally to the PROXY? Is there a standard network solution/configuration to this problem?
No. A packet sent to a multicast group is like a broadcast, it goes everywhere. The difference is that hosts not subscribed to a multicast group simply ignore the multicast packet.
In fact multicast, by default, is restricted to a single network, so it never goes through a router. Routers route packets between networks, not from a network back to the same network. To route multicast to a different network, you must enable multicast routing, which is very different than unicast routing.
Related
I am trying to setup peer to peer networking and am trying to understand how this works.
Normally in Client to Server connection, I will connect to the server IP and port. Behind the scenes, it will create a client socket bound to a local port at the local ip, and the packet is sent to the router. The router will then NAT the local port and the local socket, to the client public ip and a different public client socket with a destination for the server IP and port.
When the server responds, the router then DENATs the public client ip and public client port back to the local ip and local port, and the packet arrives at the computer.
In a Peer to Peer networking, I may have the peer's public IP, but it is shared by many machines and the router hasn't allowed a connection yet, so there isn't a open port I can send the data to.
There was then an option that both peers contact a server. That opens a port on the router. Then the peers send packets to each other's client port.
However, usually the router will only accept packets from the same IP the request was made to, so the two peers cannot reuse the server's connection.
How do the two peers talk to each other in this scenario ?
Peer-to-peer networking works exactly the same way as client/server networking. Only one of the peers will become a server and the other a client.
Normally in a peer-to-peer app like bittorrent all peers are also servers but of course for any individual connection one machine must take the role of the client. However a single peer may have multiple connections. So for any single peer some of the connections to it will be server sockets and some will be client sockets.
How this works with NAT is exactly the same as a client/server architecture. You must configure your router to NAT back to your peer application in order for others to connect to it. If not then your peer can only connect to other peers but other peers cannot connect to you. For example, if your bittorrent client is generally acting slow, not managing to get a lot of connections and not managing to finish downloading some torrents this often signifies that you have not configured your router's port forwarding back to your PC for your bittorrent client.
For the use-case of non-expert users (consumers) there are several ways to get around NAT automatically without requiring your users to configure their routers. The most widely used method is UPnP (Universal Plug and Play). However a lot of more expert users who can configure their own routers often disable UPnP because it is a fairly well known DDoS target. So if you do decide to use UPnP you should make it optional for more advanced users to disable it if they don't want to use it.
For cases where you need a guaranteed connection regardless of router configuration then your app cannot be 100% peer-to-peer. You'd need a relay server that acts as a server to both peers that will forward the packet form the sending client peer to the receiving client peer. Of course, the disadvantage of this is that you now have a fixed cost of maintaining a server to support your app just like traditional client/server systems but in this case you're using peer-to-peer to reduce server costs, not eliminate the server.
One example of this "hybrid" approach is cryptocurrencies like Bitcoin and Ethereum. They need a core group of servers to exist in order to work. However, for these protocols the servers run the same software as the clients - they're all just nodes. The only difference is that you don't shut down the servers whereas most people quit their bitcoin wallet once they've done using it (unless they're mining). Another example that is similar is the TOR network. There is a set of core TOR nodes that act as the "server" part of the network ensuring that the network always exist.
You said it yourself: "peers send packets to each other's client port". Therefore, the router will "accept packets from the same IP the request was made to".
Say, Alice is behind router A and Bob is behind router B.
Having learned their public endpoints from a server, Alice will send UDP packets to Bob's public IP, and Bob will send UDP packets to Alice's.
Having seen Alice talk to Bob's IP, router A will accept UDP packets from Bob.
Having seen Bob talk to Alice, router B will accept UDP packets from her as well.
That is, some initial packets might be rejected as coming from the blue, but after both parties have initiated communication on their side, routers will have no reason to block what follows.
In terms of Symmetric NAT Traversal using STUN 2003, by sending a packet to Bob, Alice is creating a door for Bob in A. On the other side, by sending a packet to Alice, Bob is creating a door for Alice in B.
The trick in UDP hole punching seems to be for the routers to reuse the same NAT tunnel for different IPs - so that the port discovered by a server is the same as the port reused for direct communication.
We can talk with different IPs from a normal UDP socket (by skipping connect and using sendto), so it's kind of logical that a tunneled socket would be able to do the same.
Suppose that two computers use the same Wi-Fi to access the Internet. Each of these computers has the same program installed, which is bound to the same UDP port. I want to know, since both computers have the same external IP address and listen to the same port but on different machines, what will be the result if a UDP datagram is sent to this common external address and to a common port, then which machine will receive it and how to send it each machine its own personal datagram?
The router will not forward the packet to either computer, since it doesn't know which one it should forward to.
In fact, even if the program was only running on one computer, the router still wouldn't forward the packet. It has to see outbound traffic going from the computer to the outside world first, before it decides which external port to use for forwarding inbound traffic back to the computer. And the router might not decide to use the same port on the public IP that the computer used on the private IP.
This is why everyone hates NAT and likes IPv6.
Golang application with a client and server.
Server uses net.ListenUDP -- client also uses net.ListenUDP, connects to server and sends a packet with conn.WriteToUDP with the server address.
Server receives the packet with ReadFromUDP and grabs the return address. Using this return address, it then sends a large number of packets back to the client.
When running both client and server on local machine, this works perfectly. Using Wireshark I can inspect the UDP packets and see that they contain the source and destination ports - and in the application I can see that they arrive and my various checksum tests show the data is accurate.
I then moved the server off site to a remote machine. The application stops working. I can successfully send the first message from the client to server - this is received just fine. The server sends the response back 'toward' the client - but the client never receives them.
Using Wireshark, I can see that the packets do arrive back on the local machine with the correct IP address. It appears that my network router has performed NAT on the outgoing packets - and has correctly re-addressed response packets to the internal IP.. BUT there is no port.
So I have UDP packets arriving on the correct machine, but no port - so the client application does not receive them. Application times out on ReadFromUDP.
I don't know if it is relevant, but on local machine, Wireshark labels the packets as BT-uTP Utorrent packets. When they come in from remote server, this is what I see in Wireshark - note the lack of Port.
Any thoughts how I can solve this. I didn't think this was a UDP hole punching problem because although I am establishing a connection across a NAT it is with a server not a peer.
This packet is fragmented, You can see this under Internet Protocol Version 4 > Flags.
If you look at the frame as shown on the bottom of the picture you provided you should see the ports.
net.ListenUDP doesn't appear to support fragmentation at the socket level.
Do you have a PPPoe connection? You may need to reduce your packet size being sent by 8 bytes or change the MTU on the routers external interface of the remote side. You may also need to change the local routers MTU if it's on a PPPoe interface.
Can it be done in XE7+ to Broadcast the UDP packets to specific machines/IPs?
For example, I have 10 machine in LAN. Server Broadcasted to all 10 machines. Two machines accepted the packets (clients) and Server then tool its details and keep it in DB. Now these machines are down and up again. Server again Broadcasted the UDP packets but this time to only 8 machines/IPs; and two active machines who were already hand-shaked are not sent these packets. In this process we keep on adding the machine/IPs in our DB till the time all the machines/IPs are added. Once all are added then no UDP packets is sent by the Server. It would become responsibility of the machine to send data packets once it is up.
Update:
I need only suggestion and guidance. Rest would be taken care by me like coding, threading etc.
By definition, a UDP broadcast cannot target a specific peer IP, only a network subnet. If you target a specific IP, it is not a broadcast anymore, you are just doing direct peer-to-peer communication normally.
For what you are attempting, you will have to broadcast across the subnet each time so you can discover new machines, and just ignore responses from any machines you already know about.
Scenario:
Process 1 creates a socket and subscribes to a multicast group using the IP_ADD_SOURCE_MEMBERSHIP option [Group: 224.0.0.30 Source: 192.168.0.1 Device:eth0]. Binds the socket to 224.0.0.30:5555.
Process 2 creates a socket and subscribes to a multicast group using the IP_ADD_MEMBERSHIP option [Group: 224.0.0.30 Device: eth0]. Binds the socket to 224.0.0.30:5555.
Both processes are running simultaneously on the same box.
A source with IP 172.10.1.1 sends a packet with multicast destination 224.0.0.30:5555.
Will process 1 receive the multicast packet? Or will it be filtered out by the kernel?
Thanks.
From man 7 ip:
IP_ADD_SOURCE_MEMBERSHIP (since Linux 2.4.22 / 2.5.68)
Join a multicast group and allow receiving data only from a
specified source.,,,
This means that your first process will not receive packets sent from source 172.10.1.1.
But reading further:
... This option can be used multiple times to allow receiving data from more than one source.
, which might be useful for you.