tracing an ip address

[GhostShip]

Your record indeed speaks for itself as a lesson in hypocricy.

I note you have failed to answer any of the questions put to you, instead thrusting your own personal agenda on us after making a similar post condemning us on a rival site.

We have treated you with honesty and respect, we expect the same treatment Gnarly, your entitled to your opinions and as I made clear to you we listen to any sensible suggestions and ideas as a way for ourselves, you and the community to move forward together, your last post does not fit into the catagory of progress.

I hope you will rethink your policy of implying that we are not being honest or perhaps provide some proof of any open allegations you make.

To do any less is to lose our respect for what has so far been a helpful and considerate user who is asking awkward but fair questions.
The line of course being marked by questions becoming accusations.

[KM]

*psst* still waiting for a reply to explain that one...

[7]

For what it's worth here's my thoughts on cache regionalisation.  Not aimed at anyone in particular here just thinking aloud out of interest for the subject.

*Disclaimer - It's not improbable that I'm incorrect with regards some aspects but the following is as I currently understand the WPNP based on rudimentary learning/observation/testing/etc*

I think it's a popular misconception that there is, or can be, any serious amount of regionalisation between nodes on the WPN.  As has already been mentioned here, the only moment of potential regionalisation that can occur for a client is when it contacts a cache for the first time.  The cache, presumably, does have the potential to return addresses of nodes more local to the requesting client, but, once the client is connected to the WPN it will maintain links with it in a completely ad-hoc fashion irrespective of a node's region.  Everytime a primary client's 'P' links fall below a threshold value the client will automatically locate new peers to connect to without any use of a cache server, as WinMX clients frequently exchange 'node list' packets with each other to keep each client loaded with a fresh local cache of addresses to connect to if and when required.  Similarly, a primary client can and will accept incoming primaries requesting connection to it if the client is at any point operating below its threshold maximum 'value' (actually based on a few internal threshold values) for 'PR SV' links (determined by the 'WPN Allocated Bandwidth' setting in the client) and will not make decisions to accept based on the location of the remote node.

Even if you were to initially fire up a primary connection by connecting only to, say, others peers located in Europe, over a period of time the client will, more often than not, gradually lose those European 'P' links and, in turn, make up those losses with new links pulled from the client's own local cache of nodes.  The client will, therefore, attempt to connect to anything, anywhere, which will gradually nullify attempts at regionalising the network.

Similar thing with secondary clients, too, in that a cache server does have the potential to return addresses of nodes local to that client, but, over a period of time as a client loses its links to primaries it will connect to any primary, anywhere, for reconnection irrespective of region.

Do I think a cache should at least attempt to regionalise nodes initially?  I do.  I think that, even though the WPN will inevitably become one big mix of regions over time, initial regionalisation by cache servers should at least push to initialise a regional bias by grouping users based on their client zone configuration (or, alternatively, IP address), both primary and secondary.  Subtle regionalisation of primaries should, in theory, result in a bias where primaries in that region should generally be connected more with other primaries of the same region than with those of others.

Should a user have the option to be able to manually override the region irrespective of where they themselves are located?  Yeah, I guess, if so desired, though I don't see this point of argument being of much significance overall.  The end result of a user forcing an alternate region to that which they are located could, I guess, provide for a general bias in search results received by the user according to their region selection, though I'd be surprised if there were significant differences in practice.  I guess this would very much come down to just how diluted the differing regions would become over time.

I think it could be argued that overriding the region-selection option in a user client by forcing IP-based regionalisation by the cache would be effectively removing that option, for whatever it's worth (how diluted?), from the end user.  I also tend to believe regionalisation of primaries could be of relative (compared to none) importance with regards how well the network operates overall and so shouldn't be dismissed.

[/theory] :p

[GhostShip]

Hi 7 , its not something that is dismissed as such its just that winmxgroup could implement such a techique only to hear others claim they are stopping them from doing non regional searches, segregating users etc etc, I,m sure you can see the spin anyone who wants to can apply.

My point to Gnarly is that winmxgroup are not denying a choice by offering the same thing they have always offered, a way to connect to the WPN, at no cost to themselves, none of the cache operators are paid by anyone including Gnarly and so his rude and ignorant way of approaching the matter is not helpful.

To begin offering a regionalisation of returned nodes requires programmer time and testing at the cache level, we could  see complaints over that too.

I,m sure winmxgroup has looked into the matter already and that it could be implemented if the userbase rises substancially but in the meanwhile we have a working WPN and no potential legal issues that may arise if they where to operate any sort of filtering at cache level as that would also mean caching IP,s and undermining the privacy that the users currently enjoy.

[KM]

in regards to primaries they typically run for a long period, and the system of finding their own nodes to connect to does make any region selection for caches irrelevant, however having said that i do believe it does automatically try to group itself by region independent of the caches, i can't say for sure but i have noted that when you query another primary for its list of other known primaries there does seem to be some bias in the results - of course that does not come from initial connections being sent to regions as none of the caches do that for primary (ranmas cache software doesn't seem to do any regionalisation at all despite his claims otherwise and mine only do it for secondary)

in terms of secondary users, i think it can help for the initial connection speed, however i am currently working on new cache software which uses other factors of primary stability to decide the best primary to send the user to

the only factor regionalisation has on users is initial connection speeds as it can be slightly quicker to connect to closer primaries, search results are not effected by it (as you'll notice you seem to get the same search results no matter if you are on a japanese primary an italian one or even an american one) so an option to select a region would offer no benefits to the user, but selecting the wrong one could cause small delays connecting

btw, the major thing i noticed when i first put regionalisation online on my caches was that it slightly sped up connection times for secondary users in most regions, however asia (and new zealand which the caches classed as asia) got slightly slower connection times, this was because it seems that asian primaries are blocking much less than others, with an abnormally high number of asian primaries not blocking this meant many were full so it was taking additional attempts to locate a primary with free slots on it - karmic you could say (actually ranma said it... lol). if the users had been able to override and pick their own regions then they would just select a different region, which would mean that the other regions would have lost the speed benefits of not having to use those asian primaries, making the regionalisation completely irrelevant and eliminating it entirely

[7]

Complicated subject really (for me at least).

I don't know for sure about how regionalisation could affect things, it's all just theory here, and I hope what I wrote isn't taken as anything more than general thoughts about the subject.  Personally I've never noticed any degree of regionalisation with WinMX in all the time I've used it, though neither have I specifically run any tests to look for signs of it.  It's always appeared to operate much as a random mix of nodes from anywhere and everywhere to me.

To begin offering a regionalisation of returned nodes requires programmer time and testing at the cache level, we could  see complaints over that too.

Wouldn't it just be a matter of directing requests from clients based on their region selection to an appropriate cache configured to operate for that region?  I'm not aware of the difficulties you're mentioning there but then I don't understand to a useful degree how things are setup at present to know.  With regards potential complaints about having users who have selected a particular region actually being directed to cache software operating for that region... yeah, I tend to believe you, but then... [nods off]

the only factor regionalisation has on users is initial connection speeds as it can be slightly quicker to connect to closer primaries, search results are not effected by it (as you'll notice you seem to get the same search results no matter if you are on a japanese primary an italian one or even an american one) so an option to select a region would offer no benefits to the user, but selecting the wrong one could cause small delays connecting

I tend to agree that a secondary's search results would probably be barely, if at all, affected according to where its primary happens to be located in the world.  Search results are not really my thoughts about regionalisation, I'm thinking about primaries in particular, e.g. a U.K. primary, having zone set to Europe, contacting a cache and having that cache bias its returned node addresses towards other European primaries.  I wanted to put forward the argument for this as an idea relating to network efficiency, but, do realise that after an amount of time said U.K. primary would blend into all regions of the world as its 'P' links come and go.  I don't know if this is what FC at one point aimed for, thought about and ditched, or didn't do at all, but I tend to think any such initial regionalisation would prove to have negligible, if unnoticable, effects on an end-users experience of WinMX with regards search results and such.  I'm just hinting at the potential for a tad more network efficiency initially with regards to how nodes are allocated IP addresses (I really don't see this as anything like a big issue though, just an interesting subject).

Enough from me.

[GhostShip]

Wouldn't it just be a matter of directing requests from clients based on their region selection to an appropriate cache configured to operate for that region?  I'm not aware of the difficulties you're mentioning there but then I don't understand to a useful degree how things are setup at present to know.  With regards potential complaints about having users who have selected a particular region actually being directed to cache software operating for that region... yeah, I tend to believe you, but then... [nods off]

I dont believe I said as your stating that they would complain over making a regional selection, I was however indicating there would be complaints over any testing.
May I suggest you dont read the forum enought 7, virtually all changes in the cache operations have so far been met with doom and gloom from certain users.

At the moment the patch will direct you to the peercaches in the list nothing more and those are using unfiltered active primary adresses, there was talk over six months ago on this matter and we then saw a campiagn launched by the same rabble indicating that this would delay their connections to the network, I for one am bored stiff with the ignorance meeting any progress that is made, and for that reaon alone I dont see the need for this option at the present time. 

I am sure when the network has grown a little more other cache operators will make their prescence known and the scheme can be gently manouvered into place, unilateral action by winmxgroup is not something that makes for a quiet life whatever the good reasons behind it.

[KM]

I tend to agree that a secondary's search results would probably be barely, if at all, affected according to where its primary happens to be located in the world.  Search results are not really my thoughts about regionalisation, I'm thinking about primaries in particular, e.g. a U.K. primary, having zone set to Europe, contacting a cache and having that cache bias its returned node addresses towards other European primaries.  I wanted to put forward the argument for this as an idea relating to network efficiency, but, do realise that after an amount of time said U.K. primary would blend into all regions of the world as its 'P' links come and go.  I don't know if this is what FC at one point aimed for, thought about and ditched, or didn't do at all, but I tend to think any such initial regionalisation would prove to have negligible, if unnoticable, effects on an end-users experience of WinMX with regards search results and such.  I'm just hinting at the potential for a tad more network efficiency initially with regards to how nodes are allocated IP addresses (I really don't see this as anything like a big issue though, just an interesting subject).

for primary users i think the results returned by the cache as really irrelevant, any attempts to force them to connect to specific nodes would fail completely, however for secondary connecting to a local node was my initial regionalisation, however for this i feel it is better if the caches just return local primaries to you (ie if you query it from europe then it returns a list of european primaries, if you query it from asia you get asian primaries etc) which is the system currently used on 2 of the caches, the users selection is of course ignored here and they are merely routed to a nearby primary, having different caches for different regions would just be limiting a user to only use some of the caches (those assigned to that region), it wouldn't help with regionalisation just give them less backups to use in case of failure

for network efficiency it would be useful if winmx itself was arranging itself to group together with local primaries, however i am not sure if it is doing that or not, perhaps at some point i may map out the primaries and the connections between them and compare it with locations to see if it is the case however i think that's a minor point, we can't do anything about how they arrange themselves anyway as that is all post-cache, and i don't think having a patch block it from connecting to certain primaries to force it to localise a bit would be wise (because that could go badly wrong)