Let clients in a network find eachother - c#

I have multiple pc's in a network, they each need to get each other ipaddress, i looked at broadcasting, but this requiers a server, but all pc's need to find all other. can anyone kick me in the right direction on how this could be implemented?

Well a server is technically a client that just listen for connection most of the time or provides a service.
Now, if you want that all client should discover each other. The simple way to achieve that would be send Listen for Broadcast Message at a specific port and send a broadcast message in the network that will help other client know that a EndPoint (Node) is now active.
An example would be
Listen on port XXXX as client starts up.
Broadcast a message at port XXXX this will help other client discover the node.
Once the client receives a discovery message, it sends its own detail to the client from which it received the message!

Related

Is it possible to connect gps reciever (teltonika fm1110) to a home server?

My friend has got a Gps receiver installed in his car. The Gps receiver emits signal using GPRS-UMTS network.
I have created a server socket (C#) and listening for connections but am not getting any of them which should be sent from the receiver itself.
The receiver does not have an interface it just sends data and because of that I can not program a client socket on it.
How should I solve such problem? Do I have to have specialised mobile servers to catch such data or am I able to this with my Home server (actually a normal computer which acts as a server).
when you communicate with teltonika fm1100 first you confgure your router to redirect traffic via a specific port number wich you use when configuring your gps
that you have to configure the gps tyo communicate to your public IP server
than you need a parser to read data received from gps. and first the device send it's IMEI you have to respond to this message with "1" if IMEI is correct "0" if it's not
if you need a c# parser I just wrote one this may help you begin:
https://github.com/temala/Teltonika-FM1100

How to Access WCF Service Behind NAT

Here is my situation :
I have a WCF with TCP Binding Service behind NAT and I am not able
to reach it.
I can reach my service using BasicHttpBinding and Raw TCP Sockets.
At server side port forwarding is done.
What may cause this ?
My Network Topology: Picture Link
I'm not experienced with WCF and nettcpbinding but this could help.
Theoretically it is not possible because your service has a local IP address, corresponding to the LAN where it is attached, and not a public IP address. So it could not be reached from the Internet, outside the NAT. However, almost all NAT devices, maybe your router/Access Point, have a feature for "Port Forwarding". This feature allows you to define that all packets addressed to a specific port are forwarded to a specific machine within you LAN, with a private IP address.
This could be a solution for you if you can overcome two hinders:
1-I don't know how the node in the Internet will send a message to the callback server. If it uses the IP address from which it received the request, there is not problem. If it receives a callback-IP address, then you have to figure out how to find out the public IP address of you NAT (maybe router/Access Point) and send out that IP address.
2-Your service behind a NAT needs to open a client port, or ephemeral port, to communicate with the service outside the NAT. If the second sends the message to the client port from which it received the message, you have to find a way to determine the client port you want to open (must be the same you configured in port forwarding). Will it listen in port 808 by default?
I hope this helps.
Check with URI "net.tcp://0.0.0.0:8000", this will ensure that the service will accept connection from any inbound IP address. At server side, the IP address mentioned in the URI & address from which the connection is accepted differs so the server is dropping the connection.

RemoteEndPoint giving wrong IP address

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.

Client-Client communication through a server

I'm trying to figure out how to do a very small chat program where I have a server and several clients, lets say 3, the server should be the middleman in all the communication and all message should be passed to it before passing it forward to the right client.
Now I'm quite new at this so all I got is a client that can connect to the server using TcpListener and Socket. The client can then send a message to the server and the server can reply.
Essentially what I'm asking is how can I connect 3 clients at once, and how I can i destinguish the difference between them, so I know which client to forward my message to.
This is what I got so far:
https://gist.github.com/4555536
Also, how do I handle when I want to send several messages in a row without having to send back an acknwoledgement ? I mostly do games where I got an update method that can handle this for me.
Edit: How do I do it localy ? I know I can use IP adresses otherwise.
Best Regards, Fredrik
You could identify the connecting client by its IP

Changing incoming and outgoing UDP Communication

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!

Categories