Author Topic: How can I use WinMX on a large private LAN (no internet)? (Read 10443 times)

Hans-Linux · « **on:** October 17, 2011, 07:23:53 am »

I want to use WinMX on very large private LAN and Virtual Network with about 3,000 Windows and a few Linux users and Linux mail and web servers .

There is no access to the public internet.

What do I need?
How can I set this up?

Hans

White Stripes · « **Reply #1 on:** October 17, 2011, 08:11:29 am »

helluva oddball question... could use the leaked cache server to run on one of your own machines and mode the leaked patch code to point to that address....

theres also a really old cache server buried deep in this forum somewhere... ...if there is no outside internet access the lans dns server could be used to point winmx to the cache server as well without using a patch... (see the hosts fix for what addresses to use)

White Stripes · « **Reply #2 on:** October 17, 2011, 08:21:34 am »

httpss://archive.winmxworld.com/KingMacro/Peer%20Cache/

apparently it got archived.. saved me from searching the forum for attachments

silicon_toad2000 · « **Reply #3 on:** October 17, 2011, 08:43:47 am »

you can point each instance of winmx at the cache IP via the oledlg.ini.

Just comment out the dns entries and add cache xxx.xxx.xxx.xxx.

Hans-Linux · « **Reply #4 on:** October 19, 2011, 12:30:44 pm »

Quote from: Silver Stripes on October 17, 2011, 08:21:34 am

httpss://archive.winmxworld.com/KingMacro/Peer%20Cache/

apparently it got archived.. saved me from searching the forum for attachments

The link is dead. The files linked to are 0 (ZERO) byte length files!

Hans

Hans-Linux · « **Reply #5 on:** October 19, 2011, 12:33:09 pm »

Quote from: silicon_toad2000 on October 17, 2011, 08:43:47 am

you can point each instance of winmx at the cache IP via the oledlg.ini.

Just comment out the dns entries and add cache xxx.xxx.xxx.xxx.

Does not work, I need to install a Cache Server on the LAN.

Hans

silicon_toad2000 · « **Reply #6 on:** October 19, 2011, 12:41:41 pm »

Sorry Hans, Thats what I meant.
Instal the cache on the lan and use the oledlg.ini to point winmx at the cache on the lan.

silicon_toad2000 · « **Reply #7 on:** October 19, 2011, 12:48:39 pm »

On the zero sized file, maybe try navagating there manually.

Archive - king macro - peer cache
archive button should be near the top right

Lagerlout666 · « **Reply #8 on:** October 20, 2011, 09:51:39 pm »

That cache wont work with the community patch, secondry might but primary defo will not.

Km's cache used to skip the primary process keys the community cache and patch does not.

I would also be surprised if it will connect as well in the first place. As KM's patchs and cache had no proper key swop either, it probably wont connect using our caches, maybe hex edit it to point at sabre's. And leave it sitting their for hours and hours till it finds one KM.dll user before it will connect.

White Stripes · « **Reply #9 on:** October 21, 2011, 03:54:33 am »

kms dll is still around somewhere but the addresses would need to be hexedited.... can a 'hosts' patched primary not connect to those cache servers?

Lagerlout666 · « **Reply #10 on:** October 21, 2011, 06:46:28 pm »

If i recall KM blocked access to the hostfile lot, but dont hold me to that, it was a long time ago and was for valid reason back then in a attempt to clean the network.

but to help a fella out the only way i can think of to do it is this

Install httpss://archive.winmxworld.com/KingMacro/WinMX%20Connection%20Fix/Install-3.0-noMX.exe

Edit you hostfile,

127.0.0.1 cache19.winmxgroup.net
127.0.0.1 cache18.winmxgroup.net
127.0.0.1 cache17.winmxgroup.net
127.0.0.1 cache16.winmxgroup.net
127.0.0.1 cache15.winmxgroup.net
127.0.0.1 cache14.winmxgroup.net
127.0.0.1 cache13.winmxgroup.net
127.0.0.1 cache12.winmxgroup.net
127.0.0.1 cache11.winmxgroup.net
127.0.0.1 cache10.winmxgroup.net
127.0.0.1 cache9.winmxgroup.net
127.0.0.1 cache8.winmxgroup.net
127.0.0.1 cache7.winmxgroup.net
127.0.0.1 cache6.winmxgroup.net
127.0.0.1 cache4.winmxgroup.net
127.0.0.1 cache3.winmxgroup.net
127.0.0.1 cache2.winmxgroup.net
127.0.0.1 cache1.winmxgroup.net
127.0.0.1 cache0.winmxgroup.net
127.0.0.1 cache9.winmxgroup.com
127.0.0.1 cache8.winmxgroup.com
127.0.0.1 cache7.winmxgroup.com
127.0.0.1 cache6.winmxgroup.com
127.0.0.1 cache5.winmxgroup.com
127.0.0.1 cache3.winmxgroup.com
127.0.0.1 cache2.winmxgroup.com
127.0.0.1 cache1.winmxgroup.com
127.0.0.1 cache0.winmxgroup.com

Fire up the cache and try connect. I dunno if the cache will automaticly connect to the first connecting primary?? unknown by me. and try adding the other winmx's one by one. I honestly dont think KM's cache was set up that way but it might be.

I dunno if that will work, change 127.0.0.0 to your local IP 192.XX whichever computer has the cache on the network but thats as bout as far as i can think.
Let me know if it works, i set up local networks myself when messing with things often with many verisons of winmx on diffrent computers round the house ;-D but i have the source for thing lol; so i maybe able to help you a little more if that dont work.

Will · « **Reply #11 on:** October 21, 2011, 06:57:00 pm »

You could use drac's tool here httpss://archive.winmxworld.com/Drac/

You need MX open as primary, fill in the text boxes in the app and press run then point the patchs to IP where it's running

Joshua203 · « **Reply #12 on:** October 21, 2011, 09:18:13 pm »

Well here's one that is n't on community patch and still connecting to the comunity caches, I can guarantee that both hexing as well as hostfiling 3.1beta6 patch is possible (I started out hostfiling and learned how to hex it later ...right now it's fully working ..even upto the fast roomlist for sec connections which means I get a full roomlist in +/- 30 seconds if I use a sec connection (if I manually update that list on the www [I haven't found the time or energy to look into getting that list automatically in the way i would like to see it work])

I must admit the old cache stopped working for me and I have not investigated why this happened, it used to work just fine too until a couple of months ago

Joshua203 · « **Reply #13 on:** October 21, 2011, 09:22:48 pm »

PS ..I have often wondered why KM's caches where and are freely available but never the community caches ...eventhough even the source of it has leaked

GhostShip · « **Reply #14 on:** October 21, 2011, 10:28:25 pm »

You might well wonder that but consider this before making up your mind Joshua, firstly the caches in the archive are crippled versions and not able to be used for more than a single user, the src for kms crippled caches is not available here and thus its a hex edit job when you want to adjust them.
The source for his more powerful server versions is also not availabe to the average user from our archives, nor the cache itself.

The community caches are not public or open source despite being released by untrustworthy and selfish individuals, they are also not a "static" application, many changes are regularly made to prevent KM (& friends) attacks from damaging the cache hosters despite multiple attempts this year alone, such attacks where only made possible by KM having the stolen code, something many seem to forget.

I hope this extra information satisfys your enquiring mind

Joshua203 · « **Reply #15 on:** October 21, 2011, 11:58:46 pm »

Quote from: GhostShip on October 21, 2011, 10:28:25 pm

something many seem to forget.

I didn't forget ..that's why i called it "Leaked"

I have used the old cache (both bin and exe version) for more than one but never more than 5 trusted users (simply because i needed to be able to test) .. so "only a single user" might be flexible heheh

Anyway ..yes I'm satisfied eventhough there's always something to wonder about ...it s what keep the mind going huh?

GhostShip · « **Reply #16 on:** October 22, 2011, 10:55:39 pm »

Quote

There's always something to wonder about ...it s what keep the mind going huh?

Indeed

Hans-Linux · « **Reply #17 on:** November 01, 2011, 07:35:28 am »

Decided to go woth GTK-Gnutella.

Finally was able to test GTK-Gnutella to on Windows 7, XP and 2000, Linux 32 and 64 bit boxes connected to a test LAN.. No Windows 64 bit boxes available for test.

Works like a charm with low overheads when run as Leaf Node (secondary). Has more overhead than WinMx when used as Ultrapeer (full Primary) with all bells and whistles such as DHT and doing at the same time Linear (WinMx style) and Swarming (Bittorrent style) Uploads and Downloads. Download speeds from the internet are the same as with a Bittorrent clients. No Torrent files required. Reached on one occasion constantly 2 Megabytes per second from 5 sources located in Japan and the US.

The advantage is there is no central "Authority" (Cache Server) required that if it goes down, the network is dead.

Hans

GhostShip · « **Reply #18 on:** November 01, 2011, 09:15:29 am »

You are misleading folks when you make the claim that Gnutella does not require node discovery exactly the same way winmx does, all p2p clients must know the IP address(es) of existing connected nodes to connect to a network, gnutella may do this in a different form but it does it all the same.

Node gathering has always been a weakness of all p2p networks and various methods have been suggested over time , one being to store old node data from each successful network connection period, another is to use fresh nodes from an online cache as winmx and gnutella both do (ghostwhitecrab) and the other is to use a few fixed addresses to grab node data from that in reality do nothing different than a peer cache.

Please try to stick to the facts.

Gnutella is not just the name of a client its the name of a network and not just any network, its the most media company friendly network with fake files galore and media companies monitoring your every action 24/7 , I warn anyone against using the gnutella network unless a variant of the gnutella protocol is used to add further security for its users.

The reason for the increased bandwidth is the size of the ultrapeer bonding group (primary equivalent) in winmx we usually like to see 7-8 primaries supporting us but in gnutella this figure is up to 32 other ultrapeers, this of course is reflected in its search mechanism , the size of the ultrapeer groups are a trade off taken by the networks designer when he created this and in my mind a smaller group size would provide a more efficient network overhead.

Hans-Linux · « **Reply #19 on:** November 02, 2011, 06:07:37 am »

Quote from: GhostShip on November 01, 2011, 09:15:29 am

You are misleading folks when you make the claim that Gnutella does not require node discovery exactly the same way winmx does, all p2p clients must know the IP address(es) of existing connected nodes to connect to a network, gnutella may do this in a different form but it does it all the same.

Node gathering has always been a weakness of all p2p networks and various methods have been suggested over time , one being to store old node data from each successful network connection period, another is to use fresh nodes from an online cache as winmx and gnutella both do (ghostwhitecrab) and the other is to use a few fixed addresses to grab node data from that in reality do nothing different than a peer cache.

Please try to stick to the facts.

Gnutella is not just the name of a client its the name of a network and not just any network, its the most media company friendly network with fake files galore and media companies monitoring your every action 24/7 , I warn anyone against using the gnutella network unless a variant of the gnutella protocol is used to add further security for its users.

The reason for the increased bandwidth is the size of the ultrapeer bonding group (primary equivalent) in winmx we usually like to see 7-8 primaries supporting us but in gnutella this figure is up to 32 other ultrapeers, this of course is reflected in its search mechanism , the size of the ultrapeer groups are a trade off taken by the networks designer when he created this and in my mind a smaller group size would provide a more efficient network overhead.

Quote from: GhostShip on November 01, 2011, 09:15:29 am

You are misleading folks when you make the claim that Gnutella does not require node discovery exactly the same way winmx does, all p2p clients must know the IP address(es) of existing connected nodes to connect to a network, gnutella may do this in a different form but it does it all the same.

Node gathering has always been a weakness of all p2p networks and various methods have been suggested over time , one being to store old node data from each successful network connection period, another is to use fresh nodes from an online cache as winmx and gnutella both do (ghostwhitecrab) and the other is to use a few fixed addresses to grab node data from that in reality do nothing different than a peer cache.

Please try to stick to the facts.

Gnutella is not just the name of a client its the name of a network and not just any network, its the most media company friendly network with fake files galore and media companies monitoring your every action 24/7 , I warn anyone against using the gnutella network unless a variant of the gnutella protocol is used to add further security for its users.

The reason for the increased bandwidth is the size of the ultrapeer bonding group (primary equivalent) in winmx we usually like to see 7-8 primaries supporting us but in gnutella this figure is up to 32 other ultrapeers, this of course is reflected in its search mechanism , the size of the ultrapeer groups are a trade off taken by the networks designer when he created this and in my mind a smaller group size would provide a more efficient network overhead.

With version 0.97.1 of GTK-Gnutella according observation on my test LAN which is not connected to the internet, every Ultrapeer acts as a DHT server, cache server and responses to broadcast pings by Leaf Nodes during the discovery process. Older documentation says there are a few permanent Ultrapees online as fall back if automatic discovery through DHT and broadcast does not work because of Firewalls, etc..

My point is that it is very simple and without hacking to set up and operate a completely independent p2p network with Windows, Mac and Linux boxes.

The GTK-Gnutella installation default as Ultrapeer is 45 to 50 connections to other Ultrapeers and 150 Leaf Nodes. This can be changed on the advanced configuration menu.

The Fake Files and Honey Pods problem are the same with GTK-Gnutella and WinMx. GTK-Gnutella has automatic Flood Protection.

Problems caused by downloading copyrighted material can only be avoided by either NOT downloading such material or NOT using P2P software WinMx, Gnutella, Bittorent, etc. etc, that directly transfers packets between the Source and the Client. This allows the Source to identify the IP address of the Client and in reverse. This and only be avoided by using Gnunet, Darknet, Freenet, or working through a tunnel like I2P with several intermediaries or paying to use a proxy located in a friendly country.

It is easy to encrypt the GTK-Gnutella traffic. This will only solve possible "Man in the Middle" but to "Honey Pod" problems.

Hans