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.
Related
I'm looking to enhance a WPF app I have that currently receives/broadcasts UDP datagrams within its network with a bridge functionality to share packets with other instances of the app on different subnets.
I essentially want one instance to connect with another and then be broadcast UDP packets while a connection is maintained. To do this, I figure a TCP connection will work at least for the handshake and periodic acks. However, I do not require the TCP overhead for the data itself, which could be transmitted multiple times per second for hours or longer (however long the two are connected).
Given these requirements does it make sense to do a hybrid where the TCP is used for handshaking/acks but data is sent via UDP (I assume the TCP connection can be configured to be kept open indefinitely), or would the additional overhead of sending the datagrams as TCP payloads be negligible? Or should I implement a syn/ack functionality within the UDP transmission? Is there an established standard for this sort of connection?
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.
I have a working system that receives data via UDP packets sent to a fixed IP:Port and I want to use a program (some kind of proxy?) to send a copy of those packets to a new IP:Port (or a list of IP:Ports, but all inside the same LAN as the program).
Not as easy as it seems, because I need the copied packets to have the same Source IP address as the original ones.
In my research, I have found PCap.Net (WinPCap .NET wrapper) to be useful, because it can build a Packet from scratch and it supports modifying all the address fields. I have managed to capture the packets and build them. But somewhat they are not arriving at the desired destination (!?). Should I use a different PacketCommunicator to receive and send them?
Anyway, the question is not fully related to PCap.Net but to know alternative ways to achieve my desired goal. Via a free application? commercial application? Open source sample? Any other library to use?
My systems are Windows based (no Linux available here). And I have C# (.NET) experience (I can not use a C++ library, if NET bindings are not available).
Many thanks for your help
I know it's an old question, but this is the answer:
http://code.google.com/p/samplicator/
Listens for UDP and forwards it to one or more other IP addresses, optionally spoofing (the original) source IP address.
Used for forwarding netflow/sflow/syslog etc. packets.
you should think about network first. it may not be possible if traffic needs to go through router.
the original packet came through:
source->router->your server
if you are trying to sent it back out like so:
your server->router->another computer
then the router may not even accept this traffic, since it can not originate from your computer, according to routers configuration. just think about it - i could send traffic as anybody, if that was allowed.
however, in LAN that's very doable (unless you have some sort of MAC spoofing protection on your switches)
What you are trying to do is called "UDP Forwarding". You receive a UDP packet and then forward it to another host
Here is an application that does that (seems to be free)
in addition to keeping the source ip address and changing the destination ip address
you MUST swap the source and destination mac addresses.
if you send a raw packet out to your router/switch/modem, but the mac address is not addresses to it.
it will be dropped.
basicly, you have to revise every network layer your dealing with, and handle addressing approperately.
Sorry for my spelling
If you try to spoof the destination address to do things like netflow relaying you often will get blocked by anti-spoofing routers inbetween. I encountered this with AWS for example.
The solution is to take the RAW udp packet and then just send that along to your new destination inside another udp packet. When it reaches the destination you have to "unwrap" the packet and then send it to itself on the loopback interface (essentially "unwrapping").
You can do this with python code with the sockets module.
I'm not sure how best to approach my problem. I have a service with runs on a remote machine with receives and process UDP packets. I want the service to be able to re-send these packets to anyone that happens to want them (could be no-one, will typically be one machine, but may be more)
I figured UDP Multicasting would be ideal - the service can send to the multicast group and it doesn't matter how many receivers have registered, or even if there are none.
However, I want to be able to access this over the internet and from what I gather this is nigh-on impossible with UDP Multicasting. Is there another method I might use to achieve this?
If relevant, both my client and service are written in C#.
In general this is not possible since multicast packets aren't routed.
There are some techniques to work around this (DVMRP, MOSPF and others) but they all require that you can configure all the routers between your server and the clients (or create a tunnel). There are backbone networks (Abilene, Mbone) with multicast support, but those are of most interest for universities and such. The normal consumer's internet does not have multicast.
Unfortunately you need point-to-point communication. But you are in good company, internet, radio and TV all do point-to-point, transmitting the same data numerous times. Quite a waste of bandwidth.
The preferred method is to use overlay multicast, i.e. use TCP links between peers and implement multicast semantics above that.
Many IPv4 routers do not support multicast or have it disabled, IPv6 is mandated to support multicast and broadcast semantics have been removed.
I'm trying to write a BOOTP server in c#.
I'm receiving and parsing the BOOTP packet from the client and I need to reply with my server IP address.
The problem is:
The computer can have multiple network adapters
The client doesn't yet have an IP address
Is there any way to find out what adapter the UDP packet was received on?
There are a few possible ways to do this. Bind a separate socket on each IP on each physical interface, then you'll always know which interface the packet arrived on. You can also try the IP_RECVIF flag together with the recvmsg socket function, although I don't know if that's supported on Windows. Steven's has examples in Section 22.2 and 22.6 of Unix Network Programming. You can use the SIOCGIFCONF flag with ioctl to get a list of interfaces on the machine. There is an example program in UNP section 17.6. If c# doesn't give you access to these functions but their supported on Windows you could write a simple C program to collect and update the interface / IP info and then use mmap to share a memory region between your C# program and the interface enumerator.