The project I am working on is a client/server architecture. In a LAN environment, I want the client's to be able to automatically determine the server's address. I want to avoid having to manually configure each client with the ip address of the server. What is the best way to do this? Some alternatives I have thought about doing are:
The server could listen for
broadcast packets from the clients.
The message from the client would be
a request for the IP address of the
server. The server would respond with its address.
The machine running my project's server could also have a
bind server running. The LAN's router could
be configured to use it as one of its
DNS servers.
I think I saw that
there is a bind library. Does that
mean I can build the bind service
into my server so that bind doesn't
have to be installed on the server?
Any other ideas? What have you done in the past? What are the pros/cons of these approaches and others that might be suggested?
Thanks for your help!
I like number one, that seems shortest and simplest to me. Might get tricky if the "LAN" actually involves switches that you can't broadcast through. Multicasting should help, then.
You can also use DNS, as in Zeroconf. See Bonjour for information about an implementation.
You can use WCF 4.0's new Discovery feature. Two things are possible:
The server can announce to the network that he has gone up or down, and clients can connect to it or look elsewhere, respectively.
The client broadcast an inquiry for a service and all matching services on the network will reply. The client can then pick the service he wishes to use.
You can use either or both, and it's all handled by WCF, so there's little work to actually use it. You can even set up WCF proxies if you have a restrictive network topology (such as NAT or other routing issues). The proxies can cross/convert protocols and even have custom load-balancing or other routing logic.
http://msdn.microsoft.com/en-us/library/dd456782.aspx
Related
Suppose that I have a server and the clients are connected to the server. The server is accessible through a public ip.
I would like to "forward" the connection so that the clients would be directly connected to each other withouth the server in the middle.
I do not know if this is possible at all and I myself couldn't find a way to do it.
Other assumptions:
neither client has a public IP, both clients are behind a NAT
there can be more connections initiated if necessary
I am looking for a strictly software solution, without the need to reconfigure router, open ports, etc. etc.
The reason I would like to achieve this is to reduce the load on server. Once a two clients are associated together there is no real need (except technical one) to continue using the server as a, sort of, proxy. Direct client connection would also reduce the latency of the connection.
Take a look at http://en.wikipedia.org/wiki/UDP_hole_punching. If neither machine has a public IP, and you can't open ports, and you don't want all data to pass through the server, this is probably the only other potential option. If this wouldn't work for you, you're likely stuck with all data going through the server. If you can set up port forwarding, that would make for a better solution, then just use the server to exchange IP and port information (as it exists at the time the connection is established).
A short answer is: it is not possible.
One of the main problems is that router do not know where to redirect the request from the server (or other client). Just a case : You have a router which has multiple devices(computer, cell phone...) behind it. It gets a request and do not know, who wants to get the request.
There is a workaround for that but it is not reliable (Does not work always.) Some Companies use it if it is possible, but they have always an alternative to that (like communication over server) if it fails. It is called nat punching. More details here: http://en.wikipedia.org/wiki/TCP_hole_punching
I do not know for which reason do you need. If you need it for client server connection you can use something like long polling, call back....
Otherwise you need to set the router, or take the route over the server.
You can do two things one is hole punching http://en.wikipedia.org/wiki/TCP_hole_punching
so this will allow you to respond to your client who are behind NAT (you can configure your client to send their private ip and port number used by NAT to reply to them).
Other thing you can do is to make a peer-to-peer network as done by skype and make one of the client as relay network and keep track of active relay's and update them periodically. (see http://en.wikipedia.org/wiki/Skype_protocol )
So now your server has to just act as proxy and as an admin which kind of manage all connection but least amount of info pass through it.
I hope this help.
Some home routers support upnp and can be instructed to open a certain port and forward it to a certain client on the LAN.
You can use upnpc on GNU/Linux to open ports on the router. It also has a library to do it from C code (but it's not very well documented).
However this method might not work on all home devices, so in that case see the other answers.
A broad question.
We have a client application that currently talks to a web service to exchange data between two clients. The first client stores data on the service and other clients poll the service to collect it at some later time.
We are looking to change this infrastructure a little in that clients will Connect() to the service supplying the IP and Port that they will 'speak' on. When client A wishes to send data to client B it will look up client B's IP and port on the service and then send the data directly to that IP and port.
In the situation where several clients exist behind a common firewall (and NAT), my gut instinct is that I would need to configure port forwarding for each client so that inbound messages at the public IP (ie public side of firewall) can be routed to the appropriate client. As our application is designed to shield 'techy' details we'd like to avoid this it all possible. One caveat is that we are quite happy for the client to have to open a port on the firewall, but to avoid the extra step of setting up port forwarding.
Hope this makes sense, and please feel free to ask for any clarification.
-- Edit --
We are aware of UPnP but it is a non-starter for us due to the fact that it is either not available on some routers and the fact that some corporate environments don't allow it.
Thanks,
Simon
Most home routers provide a UPnP interface to allow applications to set up port forwarding without requiring the user to do anything. Depending on the router model, they may need to enable it on the router, usually a checkbox in some buried config screen.
Some background first. I have a .net client agent installed on each of the machines in the lan. They are interacting with my central server [website] also on the same lan.
It is important for my website to figure out which of the machines can talk to each other. For example, machines of one subnet cannot directly talk to machines of another subnet without configuring the routers and such. But machines in the same subnet should be able to talk to each other directly.
The problem I am facing is when the lan setup is like in Figure 1.
Because Comp1, Comp2 and Comp3 are behind a router, they have got the ipaddress 192.168.1.2 till 192.168.1.4. My client agent on these machines report the same ipaddress back to the server. However, machines Comp4, Comp5 also have the same ipaddresses.
Thus, as far as my server is concerned, there are 2 machines with the same ipaddress. Not just that, because the subnet mask is 255.255.255.0 for all machines, my server is fooled into thinking that Comp1 can directly talk to Comp5, which is not possible.
So, how do I solve this? What do I need to change in my client or in my server, so that I can support this scenario. These two are the only things in my control.
EDIT: Seems that the network diagram
is over simplified and there could be
multiple router/subnet levels. My
original answer will not handle this
scenario. Also, with the restriction
of modifying only the client app or server
app and not tampering with the
routers and firewalls makes
it more difficult.
EDIT2: Using 'arp -a' you can extract
the MAC address of the router. If the
client apps can manage to do this then
the puzzle is solved!
The client app knows the local machine address and passes it to the server app.
The server app knows the remote address when a connection comes in. This would be machine address or a router address.
From these two values you can work out what you ask.
For example:
Server app receives connection from 10.10.10.2 with client supplying 192.168.1.2
Server app receives connection from 10.10.10.3 with client supplying 192.168.1.3
The 'remote address' distinguishes the subnets.
So, all you need to figure out is how to extract the remote address of a client connection. If you are using any of the popular web technologies for your server app then this is very easy.
One approach is for the individual client machines to determine who they can see using a broadcast message. Have each client listen on some particular UDP port, and each client broadcast its presence to whatever the local broadcast domain is. When clients can see each other in this way, they can probably also make TCP connections to each other.
If the server needs to know which clients can talk to each other, just have the clients tell the server.
If the network diagram is complicated enough I think if would be very difficuilt to find what you need.
You should also take into account that Comp1 can establish direct connection to Comp6.
The solution I can suggest is probing. Client receives list of all other clients from server and tries to establish connection to each of them. I think that would be the only way to know which clients are REALLY accessible assuming any number of routers/firewalls/NATs in the network. Doesn'r scale much for a big number of computers of course.
We meet a testing scenario which needs to tamper with source IP address of a Http request to simulate clients coming from different countries. Do you know any tool help on this?
Last but not least, our web site is built with ASP.NET.
Thanks.
In a test environment it usually isn't difficult. First read this SO question about virtual network interfaces.
If the server and client are on the same machine, all you have to do is figure out how to get your client software to bind to your virtual interface.
wget for instance has the --bind-address option to specify which local address to bind to. Web browsers are a bit more difficult to do this with; you may need to just run it in a VM.
If your server and client are on the same LAN, you just need to configure your router with some static routes to your client machine. In this case you probably don't need a virtual network interface, just set a static IP for your client machine; as long as the gateway is set up correctly it should be able to send packets to the server, and as long as the route is set up correctly the replies should find their way back to the client.
If the client and server are separated by an internet, it's rather more difficult. One option is to set up a network tunnel endpoint on the server and tunnel it to the client machine, which "knows" that it has the virtual network interface.
As noted in answers to the ServerFault question "Are IP addresses trivial to forge", you cannot easily forge source addresses in a protocol that required two way communication (e.g. TCP). Note that this "two way communication" is required at the packet level. You cannot just say "no problem, I want to send requests and ignore HTTP responses." To establish a TCP session, you need to receive data. Your best bet is to use a proxy server.
I am unsure if the IP standard allows for this, but if you are working in a Lab environment, where you don't need internet connectivity during the test, I can see it working under following circumstances:
Basically, I would set the server's network interface to use netmask 0.0.0.0 and flush the rest of the routing table.
Then you could configure a client machine to take on any IP address as long as you use netmask 0.0.0.0. And two-way communication should be possible.
Server[1.2.3.4/0] <---> Client[x.x.x.x/0]
But please bear with me. I haven't tested this, so I could be wrong :-)
If you have access to your infrastructure, you can add an interface off the router and then place a static route on the router to that network.
Server-----Router----Internet
/
Test_PC----/
Alternatively you can look into PBR (Policy Based Routing) and on the routers you can flag source packets and change the source on the fly, so your server will think they are coming from where you'd like them to come from.
Server-------------Router_with_PBR-------------Internet----- PC
SCR:4.2.2.2 Change SCR:6.6.6.6 to 4.2.2.2 6.6.6.6
But you have to ask yourself why do you want to see when packets come from different countries. Some countries have massive proxy servers that filter access ( "Great Firewall of China"), so the above tests will not prove much.
Your best bet then is using proxy servers or if your looking for a long term solution then setup a server (virtual is great for this) and use RDP for testing. I'm sure you can rent a virtual server somewhere for a month or two.
That's not possible. Because when you forge the ip address, the response is never going to come back, which is required for http.
The best way is to use proxies. See also this question on serverfault.
If you change your source IP address, that means no traffic from your web server will be able to reach back to the client.
You might be able to use some kind of proxy and/or address translation filter to do the remapping while still allowing two-way communication.
In short: How to reliably discover a server running somewhere on a (presumably multi-segmented) local area network with zero client configuration
My client application has to locate the server application without knowing the server IP address. It has to work on a local LAN that may be split into segments with hubs or other switching devices.
I already have a working solution, but it is a bit cumbersome to get it working on multi-segment networks. It works as follows:
When the client starts up, it sends UDP broadcasts on its own network segment. If the server is running on the same segment, it works without any issues - the server responds with the appropriate messages.
If the server and client are running on networks separated by a hub / switch that won't forward UDP (the most likely case), then I have a server instance running on each segment, and they forward client requests to each other via TCP - but I need to configure this for the server instances (simple, but still a pain for tech support.) This is the main problem that I need to address. There are sites where we have hundreds of clients running on 5 or 6 separate segments.
The problems I'm facing:
1. Although my application installer enables the appropriate ports on the firewall, sometimes I come across situations where this doesn't seem to happen correctly.
2. Having to run multiple server instances (and therefore configure and maintain them) on hub/switched networks that won't forward UDP
Finally I need a solution that will work without maintenance on a minimal Windows network (XP / 2000 / Vista) that probably doesn't have Active Directory or other lookup services configured.
I don't want to tag on any runtime stuff for this - should be able to do it with plain VC++ or Delphi.
What approaches do commercial apps usually take? I know that SQL Server uses a combination of broadcast and NetBEUI calls (I may be wrong about this).
Thanks in advance.
You have a few terminology issues:
Where you say "network segment" you appear to mean "IP subnet". Devices on the same network segment can see the same IP broadcasts.
Where you say "hub/switch" you appear mean "IP router".
Where you say "won't forward UDP", the problem is actually "won't forward IP broadcasts".
Once we get past that, you have a few options:
Your servers could register themselves under a well-known name in DNS, if you have a DNS server that allows dynamic DNS updates. You should probably use a SRV record as specified in RFC2782. The clients then do a DNS lookup to find the server(s).
You could statically assign your server(s) well-known names in the organisation's DNS, perhaps with a SRV record as with the previous option.
Your servers could join an IP multicast group, if your routers support IP multicast. The clients then send their initial discovery request as a UDP packet to the (pre-ordained) multicast address.
If you have domain server, I would go with small service on it. You can connect with other services to it and use it as distribution point.
Why domain server? It is relatively easy to find it's name (DsGetDcName).
Other choices would include DHCP server, DNS server or something of that kind that needs to be filled by maintenance staff anyhow.