peer cache hostname calls

[GnarlySnarly]

ok, there are 120 hotsnames for the winmx.com peer servers..
like this:
c3310.z1301.winmx.com

there seems to be some sequetial numbering.  how does winmx call them, in what order?

random?

are there certain groups for certain regions, like NA, AU, EU, etc?  each assigned xx of these hostnames?

does winmx stop at the first live IP and get a list of xx primaries to try?

When it loses connection to primary, or some secondaries, does it start at the top of the list of peer servers? pick another by random?  use last successful Ip first?

Is there any tutorial about this peer redirect process?

[KM]

the peer caches are broken down in to 10 for each region, then by version as well... you'll notice the 352 hostnames covers 3.52-3.54 for some reason

each version has 6 regions, and each of those regions then has 10 hostnames in it and it will pick a random number for that

each request to the peer cache returns 12 the details of primary users, because if one fails it prevents having to return to the peer cache to get further details... although primary users once you have one connection it will use the data on that connection to locate primaries rather than the peer cache

[Anonymous]

the peer caches are broken down in to 10 for each region, then by version as well... you'll notice the 352 hostnames covers 3.52-3.54 for some reason

each version has 6 regions, and each of those regions then has 10 hostnames in it and it will pick a random number for that

each request to the peer cache returns 12 the details of primary users, because if one fails it prevents having to return to the peer cache to get further details... although primary users once you have one connection it will use the data on that connection to locate primaries rather than the peer cache

Now we are getting somewhere.. thanks..  If they had used v331x instead of c331x, i prolly would have seen that before

What about the region codes.. in the order as listed in settings?
1= NA  2= EU  3= AU/NZ
4= SA  5= Asia  6= AF   ???

it seems most lists assign all cache servers to all regions.. I suppose this helps keep a single interlinked grouping.  that seems to nullify the regional settings.  when winmx.com ran the cache servers, did they really creats 6 different, unlinked WPN pools?  I can see some advantage, especially for local language groups.  i.e. for those using chinese or japanese or ? characters, filenames etc.. that would seem to benefit greatly from having the regional pool concentrated in that area, and as winmx gives user the option, anyone anywhere can select a region to attach to.

Any online links about this?  or is it all stored in your memory bank?

btw, I really liked the 10 hosts per line idea in the early hosts file, even if it had a few typos :p  actually it was the neat table like structure that made the typos stand out..  kudos on that.. never knew you could have 10 hosts per line..  Is that documented anwhere?  what is the limit to # of hostnames or character per IP?  I tried M$ but couldn't get any clear hits on my searches there.

[KM]

the frontcode peer caches added primaries to memory after receiving a request from them, so if you were set to one region then you'd only be "known" to the peer caches for this region, this does allow grouping together of hosts (although you'd have to have some overlap of caches so the different regions do have primaries linked to each other)

the new peer caches however source their primaries directly from the WPN, by monitoring data traveling over it - so this doesn't really apply, the peer caches should see all users not just ones using that cache... as well as being better off while the caches were getting started (ie. they don't need a flood of primary users for it to start working) it also gives much better results (because it only gets online primaries, rather than anybody that wants to send a UDP packet to it with a spoofed source address...)

[Anonymous]

What about the six zone codes..
does winmx call them based on the order as listed in settings?
cachezone 1= North Am
cachezone 2= Europe
cachezone 3= AU/NZ
cachezone 4= South Am
cachezone 5= Asia
cachezone 6= Africa

I understand that using only 4-6 IPs now does not allow for regional support.. but was wondering about the concept.
???

Q2: any links for info on that multi-host format you used in the hosts file?


Q3:  does winmx ever call "winmx.com"  or only www.winmx.com and err.winmx.com ??

if not, does a line for "winmx.com" need to be in the hosts list?

[KM]

1. i haven't looked at which numbers are which region so can't answer that

however the idea of different peer caches for each reason only works if you only send results containing primaries set to use that cache... which of course means that the cache has to return results from primaries that have "checked in" with it... that is how frontcode did it, and that is why an average of about 50% of the results from the froncode peer caches failed...

2. it simply aliases the extra ones to the first, ie. 1.2.3.4 hostname1 hostname2 sets hostname2 as an alias for hostname1 (sort of like a cname)

3. not that i have noticed...

[GnarlySnarly]

1. i haven't looked at which numbers are which region so can't answer that

however the idea of different peer caches for each reason only works if you only send results containing primaries set to use that cache... which of course means that the cache has to return results from primaries that have "checked in" with it... that is how frontcode did it, and that is why an average of about 50% of the results from the froncode peer caches failed...

I don't have any sniifer.. last time i checked the source page for it was down..

but I am assuming that calls for connecting to each selected region/zone are redirected to one of the 10 random cache servers assigned to each zone

i.e. if you selected to connect to africa, under the full winmx.com system of 120 different?cache servers, you would get connected to one of the 10 hosts in the *. z1306.winmx.com list, assuming z1306 = zone 6 and zone 6 is africa.

[KM]

yes, something like that

that is also something i didn't realise before all this happened, didn't realy look in to it too much... and you'll notice that as a result most of my software used the caches for a single region only

if you had enough peer caches then if those peer caches advertised primaries that have "checked in" with it then you could improve routing on the network a bit by having 9 seperate caches for each region, then a tenth that sits in all regions - so a few of them get connected to multiple regions to avoid seperation... however as i said the current peer caches source directly from the network so regionalising it wouldn't work too well, however the caches could impliment something simmilar based upon the source IP of the request... but that would add a bit of load to the caches

[Stealth]

Hi KM I think you might find it to be 9 separate caches for each region and that the preferred peer cache setting is meant for secondary connections and with the preferred peer cache setting for primary connections to make secondary connections connect to it in that region.

Also each of the 9 caches uses a set of ports all the time.
 
Connection table for WinMX 3.53 (including beta 4)

North America
c3521.z1301.winmx.com   ;s=tcp 7950   p=udp 7940
c3522.z1301.winmx.com   ;s=tcp 7951   p=udp 7940
c3523.z1301.winmx.com   ;s=tcp 7952   p=udp 7941
c3524.z1301.winmx.com   ;s=tcp 7950   p=udp 7941
c3525.z1301.winmx.com   ;s=tcp 7951   p=udp 7940
c3526.z1301.winmx.com   ;s=tcp 7952   p=udp 7940
c3527.z1301.winmx.com   ;s=tcp 7950   p=udp 7940
c3528.z1301.winmx.com   ;s=tcp 7951   p=udp 7941
c3529.z1301.winmx.com   ;s=tcp 7952   p=udp 7941

South America
c3521.z1302.winmx.com   ;s=tcp 7950   p=udp 7940
c3522.z1302.winmx.com   ;s=tcp 7951   p=udp 7940
c3523.z1302.winmx.com   ;s=tcp 7952   p=udp 7941
c3524.z1302.winmx.com   ;s=tcp 7950   p=udp 7941
c3525.z1302.winmx.com   ;s=tcp 7951   p=udp 7940
c3526.z1302.winmx.com   ;s=tcp 7952   p=udp 7940
c3527.z1302.winmx.com   ;s=tcp 7950   p=udp 7940
c3528.z1302.winmx.com   ;s=tcp 7951   p=udp 7941
c3529.z1302.winmx.com   ;s=tcp 7952   p=udp 7941

Europe
c3521.z1303.winmx.com   ;s=tcp 7950   p=udp 7940
c3522.z1303.winmx.com   ;s=tcp 7951   p=udp 7940
c3523.z1303.winmx.com   ;s=tcp 7952   p=udp 7941
c3524.z1303.winmx.com   ;s=tcp 7950   p=udp 7941
c3525.z1303.winmx.com   ;s=tcp 7951   p=udp 7940
c3526.z1303.winmx.com   ;s=tcp 7952   p=udp 7940
c3527.z1303.winmx.com   ;s=tcp 7950   p=udp 7940
c3528.z1303.winmx.com   ;s=tcp 7951   p=udp 7941
c3529.z1303.winmx.com   ;s=tcp 7952   p=udp 7941

Asia
c3521.z1304.winmx.com   ;s=tcp 7950   p=udp 7940
c3522.z1304.winmx.com   ;s=tcp 7951   p=udp 7940
c3523.z1304.winmx.com   ;s=tcp 7952   p=udp 7941
c3524.z1304.winmx.com   ;s=tcp 7950   p=udp 7941
c3525.z1304.winmx.com   ;s=tcp 7951   p=udp 7940
c3526.z1304.winmx.com   ;s=tcp 7952   p=udp 7940
c3527.z1304.winmx.com   ;s=tcp 7950   p=udp 7940
c3528.z1304.winmx.com   ;s=tcp 7951   p=udp 7941
c3529.z1304.winmx.com   ;s=tcp 7952   p=udp 7941

Australia and NZ
c3521.z1305.winmx.com   ;s=tcp 7950   p=udp 7940
c3522.z1305.winmx.com   ;s=tcp 7951   p=udp 7940
c3523.z1305.winmx.com   ;s=tcp 7952   p=udp 7941
c3524.z1305.winmx.com   ;s=tcp 7950   p=udp 7941
c3525.z1305.winmx.com   ;s=tcp 7951   p=udp 7940
c3526.z1305.winmx.com   ;s=tcp 7952   p=udp 7940
c3527.z1305.winmx.com   ;s=tcp 7950   p=udp 7940
c3528.z1305.winmx.com   ;s=tcp 7951   p=udp 7941
c3529.z1305.winmx.com   ;s=tcp 7952   p=udp 7941

Africa
c3521.z1306.winmx.com   ;s=tcp 7950   p=udp 7940
c3522.z1306.winmx.com   ;s=tcp 7951   p=udp 7940
c3523.z1306.winmx.com   ;s=tcp 7952   p=udp 7941
c3524.z1306.winmx.com   ;s=tcp 7950   p=udp 7941
c3525.z1306.winmx.com   ;s=tcp 7951   p=udp 7940
c3526.z1306.winmx.com   ;s=tcp 7952   p=udp 7940
c3527.z1306.winmx.com   ;s=tcp 7950   p=udp 7940
c3528.z1306.winmx.com   ;s=tcp 7951   p=udp 7941
c3529.z1306.winmx.com   ;s=tcp 7952   p=udp 7941