I have a udp socket server written in C/C++ and a udp client written in C#. I can send packets back and forth, where the server simply echo's back the clients broadcasted message. However, when I send a udp packet to tell the server to reconfigure its network settings (IP, subnet, gateway, DNS) and rebind the adapter to refresh the settings, the client cannot receive the servers echo back anymore.
From what I have read so far, now that the server has different settings it could very well be on a different subnet on the same LAN. My question is how to send the packet back to the broadcasting client? I use the sendto() WIN32 api function, which sends the message to the IP Address and port it got from the broadcasted message. Is there another function that could send the packet back to the specific MAC of the client, therefore skipping the different subnet part? Or is there a different way to send the UDP packet across a local subnet?
Related
I am using Tcplistener to listen on a port for requests. When the requests come in from the client I want to know the client ip making the request.
the problem is : the server and all client take the same Ip
so I decided to send massage from server to client by port ... I search a lot on google But I did not knew how I can send message from server to client using the port ? so can any body help me ?
The clients are not listening for incoming connections, so the only way for the server to send a message to a client is by using an existing connection, that was previously established by the client.
You don't have to specify the port number when sending a message on an existing connection, your server can just use:
Socket handlerSocket = tcpListener.AcceptSocket();
// a connection is now established, "handlerSocket" can be used for both receiving and sending messages
handlerSocket.Send(...);
Your clients currently send data and immediately close the connection though, you'll have to modify them to read data from the NetworkStream in order to receive anything.
There are tons of tutorials available, I think you just googled the wrong keywords. Have you tried something like c# chat tutorial?
You are running them all in the same computer. That is why the IP is always the same.
SOP for this kind of thing is to have two ports: a control port and a data port.
The way this works is:
The control port is used to initiate the connection.
Upon successful connection, the server and the client negotiate a set of ports to be used for the data (local server data port and remote client data port).
The server establishes a connection to the remote client data port from the local server data port.
The client issues a request for data (e.g. command) through the control port.
The server sends the information back through the data port.
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.
How can I send data from my C# socket program to my clients?
Currently I have two programs, server and client.
I start my server, then my clients connect to server, in this way they are connected together, but now I want to send directly from server to client?
As my client cannot start its own connection, of course I have IP and port of my client, how can I send data from my server to a client with known IP and port?
Thanks.
Since your clients are not computer programs you can control, you really have no chance but to contact them from the server. If your clients can handle TCP communications, you need to treat them as servers, and Connect from the server to each client (open the socket on the server side, and Connect to each client IP and port).
It's possible that your clients understand UDP and not TCP. That is actually going to be easier for you, as you only need to create one UDP socket, and use SendTo to send a data to each client (one SendTo call per client).
Let's just hope your clients aren't stuck on the Ethernet level...
I would say that COM-ports are slightly easy to communicate than implementing TCP/IP protocol on your device. Could your device read/write its COM-port?
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
What is the best way of reading, changing, and resending UDP communications?
For instance i have a server application that tells a master server it's alive sending a packet over UDP on port 3209. It sends out "I'm alive, my ip is xxx.xxx.xxx.xxx and I have currently 3 clients connected to me." the master server then responds, "Hello xxx.xxx.xxx.xxx i see you there."
Whats the best way of MITM (Man In The Middle) of the server sending its packet to the master server? I would like to be able to change "I'm alive," to something like, "I'm changed," or even "currently 3 clients connected" to "currently 0 clients connected"
When trying to make a new UdpClient to the port the server is on i get a "Only one usage of each socket address (protocol/network address/port) is normally permitted" exception.
you mean packet analysis?
You should do two things:
Discover real protocol of
interserver communication. They are
comunicate over UDP but structure of
the data trasfered is not the
network protocol. You should
discover data structure are
transfered between servers
Decide on wich side you are going to
operate with packets. If you are on
one of the servers sides, you can
write filter driver wich would be
change data before it will be
sending or before it will be
recieving by application. If you are
not in the serber side I dont kwnow
hot to intercept network packets
UDP has no integrated security and is not connection oriented so in this case It will be much easier.
You can forge the source IP in the IP packet (no real problem doing that) and just sniff the UDP packets sent to the real IP server. The main problem here is avoiding the main server to receive the real packets from the real client. For that you'll have to tamper with the routing scheme which is not really easy to do...
I ended up writing a program to listen on the port that the server was sending to. I then resent all the data to the master server with the values changed that i needed. When the master server responded back i then sent that data back to the client application. Nor the server or the client application know there is a server in the middle changing the data.
Thanks for all the replies!