I am trying to build a client server socket library that will abstract the complexities of sending and receiving data. I was wondering if you have a UDP server setup to have a multicast group. Can it still send and receive unicast requests to specific clients if needed? Or do you have to have to open two sockets to handle either type?
You can do multicast and unicast at the same time using the same socket.
You can send and receive any multicast and/or unicast UDP packets interleaved in anyway, so even if you want to talk to many different peers, some multicast, some unicast, you can use a single socket for this, and it fact it is often useful to do so in terms of complexity of the application.
Some things to consider:
On Linux you will want to bind() your UDP socket to your desired port and to the IP address 0.0.0.0 (INADDR_ANY). This will enable you to receive UDP packets targeted at any multicast address and any unicast address. Specifying a concrete IP address for bind() with UDP has a filtering effect and will only let UDP packets in targeted at that specific UDP address, which is rarely useful in practice, as all multicast servers usually also want to allow the same traffic to arrive as unicast, transparently.
On Windows binding to a fixed nonzero IP address has different semantics: It binds the UDP socket to a specific interface (the one with the given IP address). Sending and receiving UDP traffic for multicast/unicast should work on Windows even without binding to 0.0.0.0.
Related
Building a bit of code that does auto configuration of IP addresses, when they start they all have the same IP, this software uses multicast to find the other devices on the network and uses that information to figure it's own IP configuration.
However if they have the same IP they stop receiving multicast packets, but if I force them to have different IPs multicast starts working again. Is multicast tied to IP address or can multiple devices with the same IP receive multicast.
We cannot use APIPA/Link-Local addressing.
Thanks,
Dan
Multicast does not mean broadcast. Multicast means to send data only to devices which have previously requested this multicast group.
You cannot use multicast to reach any previously unconfigured machines. For this you have to, use broadcast (i.e. 255.255.255.255).
Multicast relies on the IGMP protocol, which in turn relies on a working IP unicast setup, which in turn requires that all devices can be uniquely identified by their IP addresses. IGMP messages contain the unicast IP address of the sending device.
In your setup all the nifty optimization algorithms in all the network components along the path (routers, switches, also the devices themselves) will fail since they cannot identify the targets which request the multicast group. They may fail in any random way. It is completely undefined how multiple devices with the same IP address behave.
In your case some network component decides that there is no need to distribute the multicast packets to the involved ports, as there is no unique receiver connected to the port. (I am just speculating here. Any other answer will be correct, too. Just an example to explain how this could behave the way you see it.)
We're using Fleck for our Websockets.
When we test our network program locally it all works fine. The process of a client connecting is:
Establish TCP connection
Send/receive infrequent TCP messages
Start sending/receiving UDP stream to server
The problem is on the live server which is far away geographically, clients can receive and send TCP messages, and they can send UDP messages, but they do not receive UDP messages.
We've investigated it as far as we can, and have found that the RemoteEndPoint property of the TCP connection on the server has the wrong IP address. It appears to be an IP address from our ISP. We use this IP address to attempt to send UDP messages back to the client. As it has the wrong IP, the client never receives these UDP messages.
The actual source IP address of the client must be known somewhere, as the TCP messages make it back OK. I've gone through the Fleck source and have printed out the RemoteEndPoint of the underlying System.Net.Socket but it keeps giving the wrong IP address.
Does anyone know what is going wrong and how we can expose the actual IP addresses of the clients?
The most likely reason is that your client does not have a public IP address, but a private address behind Network Address Translation (a very common setup). A common private addresses are of the form 10.X.X.X or 192.168.X.X.
NAT device replaces private address in a packet from your client with its IP address, which is public. For the outside world it seems that the traffic originates from the NAT device. The main advantage of NAT is that it allows many clients to use a single public IP address (IP addresses are sparse). But NAT introduces a problem: an incoming packet needs to be routed to a correct client, but it does not have a client IP address. Some other strategy needs to be used to recognize to which client a packet should be routed and such routing is not always possible.
For example, the most well known limitation of NAT is that you can't simply start a listening TCP server behind a NAT and then connect to it from the outside world. The reason is that NAT device has no idea that your server listens on a given port and thus, it has no way to known that TCP SYN packets from the outside world need to be passed to your client. A workaround for this is to explicitly configure the NAT device to route SYN packets directed to a given port to a specific client (port forwarding).
When a client behind a NAT initiates a TCP connection, a NAT device remembers state of the connection (client address, client port, remote address, remote port). Because of this, when a response arrives, the device knows to which client the response should be passed. When the connection is closed, the device discards state information. This is why your client can communicate over TCP.
But UDP is more difficult to handle because it is connectionless and stateless. When the device sees a UDP packet it does now known if a reply is expected and when, so not all NAT devices handle UDP traffic. Although there is a technique that allows to do it.
To summarize: the problem you are seeing is not C# specific. Setting IP address in packets from your server to the client IP address won't help, because it is most likely a private address that is not routable. To solve the problem you need to use a NAT device that can pass UDP traffic in both directions. But if you are developing a generic client to be used in many setups, you may want to reconsider if UDP is the best option. TCP connection forwarding is a basic feature that all NAT devices support, but some devices may not support UDP.
I am attempting to create a server and client that utilizes both TCP and UDP. The server works very well in a LAN setting but the UDP messages are not being received when transmitted over a WAN. I believe it is because the UDP socket used to send the data is not remaining in the NAT tables long enough to return any information. Is there a way to either make the UDP port stay open in the router (without port forwarding) or use the same port for UDP as the already connected TCP connection? Thanks in advance.
If you're not getting any traffic it is probably simply blocked by the firewall. In this case it is not about forwarding, it is about opening the port.
Most (if not all) NAT/Firewall devices will allow UDP traffic in both directions once a hole is punched through the NAT. That is, if my laptop here, sitting behind a NAT/firewall, sends a UDP packet out to the Internet my NAT/firewall will allow return UDP traffic to the originating port number through. I work a lot with UDP and my experience is that this is the rule and very few exceptions.
Keep in mind though UDP packets are not guaranteed to be delivered.
Is your client behind a NAT? Do any packets the client send get to the server? Is the problem in the server to client direction?
If you use the same port number for UDP and TCP this will not change the situation. You can't piggyback on a TCP connection because it is a different protocol.
Network Address Translation (NAT) Behavioral Requirements for Unicast UDP
http://en.wikipedia.org/wiki/UDP_hole_punching
I have a Visual C++ programm with a proprietary point-to-point protocol built on top of TCP/IP sockets that allows a set of messages to be flow between a third party software.
There is a note in documentation to that protocol:
IP logical packets do not necessarily map directly to physical packets on the underlying network socket, they may be broken apart or aggregated by the TCP/IP stack.
What does this mean?
I've write my C# application to connect and due to technical restriction it is able to run and communicate only locally. Plus every millisecond is critical.
Seems this is not about named pipes: pipelist.exe doesn't show any specific entries.
If you are just using loopback there may be no IP packets at all, and in any case (a) the implementor of your protocol should have already taken all that into account and (b) TCP hides all that from you too - it just provides a byte stream interface.
When TCP/IP packets go out over, say, Ethernet, the packets are repackaged as Ethernet frames. This may include breaking up the original packets.
When the frames arrive at their destination, the Ethernet header information is removed and the original packet (reassembled if necessary) is presented to the TCP/IP layer on the destination machine.
But this repackaging can also happen within the TCP/IP stack. TCP and IP are actually separate protocols; IP is responsible for routing, TCP does the "handshaking" (maintains session state, guarantees delivery [or tries to], etc.)
Named pipes are a completely different interprocess communication mechanism. Usually faster than TCP/IP, but typically restricted to use on a single machine, I believe.
IP logical packets do not necessarily map directly to physical packets on the underlying network socket, they may be broken apart or aggregated by the TCP/IP stack.
TCP/IP is not the lowest level network protocol that exists. There are others: the Ethernet protocol that connects ethernet devices, the 802.11x wireless protocols, and others. All this statement says is that a single IP packet may correspond to multiple packets in the lower-level protocols, and that the IP networking layer is responsible for buffering or joining these packets.
Your application shouldn't need to worry about this at all. TCP/IP networking is handled very efficiently by all modern OS kernels, and unless your requirements are very unusual you should never have to worry about the way your application protocol is broken up into packets by TCP/IP or the lower-level protocols.
My problem is that I have more than one instance of my class, while trying to listen the same port. I've found that I can do it (listen on the same port) with the code I found (using the "ReuseAddress"), however it only works with multicast and broadcast packets, whilst I need unicast packets.
Anyone knows how I can make it work with unicast aswell?
Thanks.
Unfortunately, since UDP does not support the concept of a connection, it's usually not possible to bind multiple UDP sockets to the same local address:port pair. What you can do, however, is write your own wrapper around a single, shared UDP socket that figures out which client an incoming packet comes from, and routes it to the appropriate point within your own code.