I was thinking about client sharing for a server that could be accomplished by client side execution with little or no help from the severs end, and came up with this -
Pardon me if it sounds silly, bu here I go -
- The server has a table which stores the fields of server names, server ip addresses and the corresponding Ip addresses MAC ID's (Yes, this is a very Windows centric approach)
- Every time a client logs on to the main server it send out a query to the server which returns the ip address of all the server entries asn their respective MAC ID's it has in its table(im assuming that a single server has multiple rsynced copies)
- The client then implements a traceroute to each of these ip addresses and stores the开发者_Python百科m in an array in order of increasing hopcount.
- Iterate through this array and implement arp to resolve the IP addresses into MAC ID's. Then compare these MAC IDs with those fetched from the main server at step 1. IF theres a match then selection of the server to connect to is based on the number of hop counts+match of MAC IDS+ a metric that signifies the load(number of connections to that server at that instant in time).
Opinions about how this idea sounds are welcome.
I don't think load sharing could be based exclusively on hop count. And why would you need the MAC addresses? If one server is fast to reach but mighty busy it may not be the best choice. Maybe you might add a service to the main server to keep track of the number of clients for every server and use that as criterion... but that sounds a lot like the old, simple and plain load balancing.
精彩评论