J
Jim
Hello,
I am working on a system of distributed robots running XP Embedded all
communicating over an ethernet TCP/IP network. This distributed system
should allow:
- robots to be added and removed from the network at any time
- allow auto configuration of networking parameters so robots can
dynamically join and leave the network without user intervention
My problem is (one of them anyway) that I can't have an external DHCP server
box on the network, so the robots themselves need to work out IP addressing
conflicts. I'm trying to figure out the best way to do this using C# and
..NET technologies (if possible).
Static IPs won't work because the robots can't be configured before hand.
They all must be running an identical software configuration on startup.
Initially I was thinking of hosting a DHCP server on each machine, and
having the first machine on the network declare itself as the DHCP server.
Subsequent robots joining the network would then see that a DHCP server is
already on the network and become a client rather than a server. If the
robot hosting the DHCP server leaves the network, through some random
selection process another machine would take over DHCP responsibilities.
This has some complications since every machine would have to know which
addresses were already leased out so when a new DHCP server takes over, it
can continue without problems. However, I can't find any free windows DHCP
implementations around (in c# or anything else for that matter) that I can
hack up to do this. Besides, this solution seems kind of bulky because DHCP
has many more features than I need.
Next I was thinking about perhaps implementing a simple address resolution
protocol using the .NET sockets API. Mabye a protocol that would have all
machines broadcast all current MAC address to IP address mappings, and allow
individual robots to decide their own ip addresses based on the current
known mappings. I feel strange about implementing an address resolution
protocol though, since its totally reinventing the wheel.
So my question is, does anybody know of a better way to do this? Am I aiming
in the wrong direction here? Does this question make sense?
Thank you for any ideas!
-Jim
I am working on a system of distributed robots running XP Embedded all
communicating over an ethernet TCP/IP network. This distributed system
should allow:
- robots to be added and removed from the network at any time
- allow auto configuration of networking parameters so robots can
dynamically join and leave the network without user intervention
My problem is (one of them anyway) that I can't have an external DHCP server
box on the network, so the robots themselves need to work out IP addressing
conflicts. I'm trying to figure out the best way to do this using C# and
..NET technologies (if possible).
Static IPs won't work because the robots can't be configured before hand.
They all must be running an identical software configuration on startup.
Initially I was thinking of hosting a DHCP server on each machine, and
having the first machine on the network declare itself as the DHCP server.
Subsequent robots joining the network would then see that a DHCP server is
already on the network and become a client rather than a server. If the
robot hosting the DHCP server leaves the network, through some random
selection process another machine would take over DHCP responsibilities.
This has some complications since every machine would have to know which
addresses were already leased out so when a new DHCP server takes over, it
can continue without problems. However, I can't find any free windows DHCP
implementations around (in c# or anything else for that matter) that I can
hack up to do this. Besides, this solution seems kind of bulky because DHCP
has many more features than I need.
Next I was thinking about perhaps implementing a simple address resolution
protocol using the .NET sockets API. Mabye a protocol that would have all
machines broadcast all current MAC address to IP address mappings, and allow
individual robots to decide their own ip addresses based on the current
known mappings. I feel strange about implementing an address resolution
protocol though, since its totally reinventing the wheel.
So my question is, does anybody know of a better way to do this? Am I aiming
in the wrong direction here? Does this question make sense?
Thank you for any ideas!
-Jim