Printable View
Hey all,
I have a simple TCP Client/Server application that ties two pcs on a lan together. This has worked great for many job sites but the most recent has an IT manager that will not allow me to set a static ip address on the server pc.
Basically, I was wondering if there was a nifty way to have the client find the server. (I guess I could go through and try to connect to every ip address on the sub net but I was hoping there was an easier/faster way)
- Nick
If he wont let you set a static IP on the PC itself (which I too would be against) then ask him if he will set a reservation in DHCP for that PC's MAC address to always get a specific IP - that way he will not have any of the problems that you get with a static IP on a PC (having to keep track of it, having to exclude that IP from DHCP, worrying about someone changing the IP etc etc).
Failing that, you can do what is called a Broadcast. Not sure if you can do it in TCP, I've only ever really seen it used with UDP but I cant see why you wouldn't be able to do it in TCP. This basically just sends a message to every IP on the subnet (I think you just use 255.255.255.255 as your destination address when sending the packet) and then your server can respond when it receives this message, to let the client know its address.
You could use a hostname. Try this:
Code:Dim IPs As System.Net.IPHostEntry = System.Net.Dns.GetHostEntry("ComputerName")
For Each IP As System.Net.IPAddress In IPs.AddressList
Debug.Print("IP Address: {0}", IP.ToString)
Next
Thanks guys; these are great ideas.
I'm going to try both of these out.
(set up as a redundant check)
I'm still open to other solutions/ideas if anyone has them.
- Nick
HairyMike,
I tried your technique and it worked fine when I was on the computer that was to be the server. (looping back on myself)
But when I went to another PC on the lan it couldn't find a computer by my computer's name.
is this a windows networking problem?
Or did I do something wrong?
Thanks,
Nick Spencer
If you just open command prompt and ping the other machine by name does it resolve it to the correct IP?
I get a Could not resolve Host error.
Sorry actually it's Could not find Host.
This link shows how to send a UDP broadcast
http://msdn.microsoft.com/en-us/library/tst0kwb1.aspx
This will probably be your best bet. You can either have your server send a broadcast periodically that the client see's, or have the client send a broadcast that the server watches for.
Yeah that is a windows networking issue then and not something you can do anything about in your program. Are you running this on the live network that you were talking about or is this just on your own home/test network? On a 'proper' business network you should not have problems resolving host names but working with the IP would usually be preferable if you know it will always be the same IP.
You could also check out
http://msdn.microsoft.com/en-us/libr...verstream.aspx
Chris,
Could very well be the network; I'm at a buddy's house trying it out.
Thanks,
I'll send a test app to the IT manager for him to try out.
dbasnett,
I'll take a look over both of those. Looks like UDP may have some advantages as long as I'm willing to sacrifice a small amount of transfer reliability.
- Nick
Just use UDP to get the IP address, then use TCP / IP.Quote:
Originally Posted by nickwrs
If it were me, and I knew that DHCP was involved, I would simply have the server broadcast a packet every 10 seconds or so. What happens if one or more of the DHCP leases expire while your application is running?
With a DHCP reservation that doesnt matter as the client will always get the same IP, the DHCP server will not assign that IP to any network card other than the one that has the MAC address that the reservation was set up with.
To be honest even without a reservation it is extremely likely that a device will get the same IP when its lease expires because when half of its DHCP lease has expired it will begin to request a renew from the DHCP server (and the default DHCP lease time is 8 days so you have got 4 days for the client to be booted up at least once for that same IP to be leased to the same client). Also I think DHCP servers are encouraged (by the DHCP RFC) to give a client the same IP that it had previously when it requests a renew.
Anyway, geek talk aside, why have the server cluttering up the network with broadcasts every 10 seconds when you could just have the client application broadcast when it starts up and then have the server respond when it receives this broadcast... 1 broadcast each time the client app launches sounds much better than a broadcast every 10 seconds to me :)
Why do we so fundamentally disagree about so much? Unless you KNOW that the IP's will NOT CHANGE while your program is running then you should program like they will. One 64 byte packet every 10 seconds on a LAN is what us old network guys call noise.Quote:
Originally Posted by chris128
Sure hope they are not doing ping-then-do (AKA 2-64 byte packets).
I do totally agree with that, I was just pointing out that a DHCP reservation (which is what I suggested) would not have that problem. Then at the same time I also just mentioned that they are not likely to change anyway, I was not meaning that you should count on them not changing in a standard DHCP config.Quote:
Originally Posted by dbasnett
I dont understand though how you can say that sending a broadcast every 10 seconds when you could just send one when its actually required (which would be what, once or twice a day perhaps?) is the correct way to do something when you are pointing out that sending a ping before attempting to connect to something is inefficient... Based on my scenario above (once every 10 seconds vs once a day) you would be sending something like 8000 packets more than you need to every single day... now THAT is inefficient ;)
Quote:
Originally Posted by chris128
8640 packets to be precise. But it means that the app will work without changing the DHCP reservation, and not be dependent on ANY IP address.
Wow, 8640 looks like a lot, but... 8640 packets = 4,423,680 bits per day out of a possible 86,400,000,000,000 bits per day on a 100 Mbps ethernet(0.00000512%). Like I said, noise.
The ICMP traffic on the internet is 2%, and ping-then-do isn't making it better, and it isn't required.
I was looking at TCP/IP networks in the late 1970's.
Wow... looks like I have a lot to read/look at.
Thanks for all the help and info.
- Nick
Both of those things would be true if you just did it once when the client starts though :SQuote:
But it means that the app will work without changing the DHCP reservation, and not be dependent on ANY IP address.
Perhaps you dont understand what I am suggesting - what I am suggesting is that instead of the server constantly broadcasting, the client just broadcasts when it needs to locate the server and when the server receives this broadcasted message it replies to the client that sent it to let it know what IP address the server currently has.
I also dont understand how 8640 packets is "just noise" but a couple of packets from a ping is a huge waste...
How convenient to ignore the numbers I posted. If you want I can do the math for you again.Quote:
Originally Posted by chris128
If it was just you doing ping-then-do then it would not be a problem. But then it is you, and you telling other people it is a good practice, and then them telling other people, and then 2% of the traffic on the internet is ICMP.
That depends on what the dhcp server is, if it's a basic router then the default is 5 minutes, I've set my home router for 1440 minutes (1 day/24 hrs) but I do believe both my jobs have their dhcp server (and actual computer) set for 5 days and with the computers being turned on every work morning they never make it to the half way point of requesting a lease extension because the extension happens every morning.Quote:
Originally Posted by chris128
Also when it comes to servers and dchp and what not you should always have the server(s) be assigned a static ip (reserved ip) even though they run 24/7 so the lease never expires but what it does is allow them to be a constant on the dhcp table and they're also excluded from the assign ip range (as in if you have a range set up for 50 comps, the servers being static means 50 comps plus the servers still) makes things easier to manage.
I'm not ignoring the numbers, I dont care how much you say that sending packets every 10 seconds is 'just noise', it is still a complete waste of time if the client will only ever need to receive those packets when it starts up... Just have the client send the broadcast when it starts up. Why cant you agree that 1 broadcast a day is better than 8640 broadcasts a day!Quote:
Originally Posted by dbasnett
I like a good debate, so long as it is about facts.Quote:
Originally Posted by chris128
1 - I don't see where the OP indicated that the client only starts once a day. It may be the case, but only the OP knows at this point.
2 - 0.00000512% of the total bandwidth (which is based on a assumption of only one server) is insignificant, in my opinion.
3 - Both methods would, I believe, work. However what I proposed is a tiny bit simpler, a UDP transmitter at the server, and a UDP receiver at the client.
4 - Why don't you agree that ping-then-do is a complete waste of time, and it should not be encouraged.
My point is not that the bandwidth is significant, just that broadcasting all day is totally unnecessary. I know the OP did not say the client would start once a day, but even if it was starting 20 times a day it would still require thousands less broadcasts than your suggested method. Its similar to saying in a VB.NET program you should use a timer to constantly check if an event has been raised when you could just use an event handler instead. Yes using a timer would work and it probably wouldn't cause any issues but its just completely unnecessary when you could use an event handler to only have your code be executed once and at the correct time.
If we are going to make "what to do on the LAN" v. "what to do in my app" comparisons I guess you have a lot of code that looks like:
You said, I think, that the bandwidth is not significant. If that is the case, and broadcasting from the server is simpler, then what is your objection?Code:Dim tb As New TextBox
If TypeOf tb Is TextBox Then
tb.Text = "ping-then-do"
End If
Of course, if you are going to use UDP, then you better not assume that it will be delivered, and if you are only sending one packet then that might be a problem.