V E R   3 . 3 1   N O T E S

Firewall/Ports Info | Rogue Nodes


2007/2008 update: The simple 2005 hosts file patch is no longer sufficient to be able to use the WinMX program to connect to its community of file sharers. But the WinMX community remains alive and well. You can find up-to-date winmx resources (patches, info) here and here. You can find a pertty good Feb 2008 list of opennap servers here.

WinMX has long been do-what-you-can-with-it freeware. Some former napster users have had difficulties migrating to it. The WinMX newsgroup was formed to enable the WinMX sharing community to share the knowledge for others to use it more effectively.

With the release of version 3.1, WinMX became far more advanced and a bit more complex. I consider it a major advance over version 2.6, though some folks are still trying to cling to that 2001 release (mainly for reasons of system incompatibility).

I tried v3.1 the first or second weekend it was available, and was immediately confused and impressed. Since then the former has dwindled and the latter has increased... Here are some of my notes regarding the new WinMX.

The thing that makes WinMX so special -- and has for over a year -- is its (proprietary, sadly) WPNP, which stands for WinMX Peer Networking Protocol, a serverless peer-to-peer network. Servers are used so new peers can find the network, but servers do not participate in the network. Instead, some of the sharers, those with sufficient (CPU, RAM, fast 'net connection) resources act as 'server' nodes. These constitute what are known as primary connections to the network. Other sharers can still fully participate as secondary connections, which, as you might imagine, must go through the primary nodes in order to find other connections to the WPNP network.

A few folks have complained that v3.Xx is not as good as v2.6 for connecting to open-nap servers. They worked OK (once I finally got into a few) for me in 3.1 but by the time 3.2 was released I had grown so impressed with WPNP that I saw open-nap servers as decidedly old-fashioned, and haven't bothered trying them in ver 3.2x, so I can't comment on that, personally, except to say that I don't really care about opennap servers at the moment because WPNP is so much better.

Though the open-nap community is largely about file sharing, it is very user-centric. For example, you can be notified whenever a particular user logs onto a particular server. For another, once a sharer has located a file she wants to acquire, she asks the server to contact that user who has the file for that file. A good open-nap program such as WinMX will provide an Auto-Retry feature -- in case the file xfer is broken before the xfer completes -- to keep retrying that user for (the rest of) that file. This feature was abused by some. There was also a feature that facilitated the finding of similar/alternate files/sources by opening a new search window. But WPNP, as implemented in ver 3.Xx, goes further.

The 2 biggest WPNP advantages are that a file can be acquired from multiple sources at once (you can also work your way up better sources' queues while the file transfer is ongoing), and ease of quickly logging into the network (a network devoid of any incompatibilities with other clients [namely AudioGnome]).

WPNP is more file-oriented and less-user-oriented. Instead of Auto-Retry, there is now Auto-Complete. This offers two advantages: WinMX will automatically periodically find new sources as needed, and the program will resume looking for and transferring such incompletely transferred files the next time it is launched.

I still have not yet set up a primary connection (not enough resources -- it takes a lot!), but I have successfully configured WinMX to work properly/fully from behind a firewall (which is easy if you are able to make two tiny openings in the firewall and make sure they line up with the machine on which WinMX is running).

If you're still reading this and wondering where this article is headed, I'm going to maintain my observations regarding the use of WinMX v3.Xx and WPNP here...

Here's what I first wrote about ROGUE NODES:

First of all, compared to my first experience with WPNP as implemented in v3.1 of WinMX, it seems like the network is now under attack, partly from those 'sharers' who do not share (too many leeches), but also most likely from the same corporations that succeeded in legally killing Napster. Given the way the RIAA requested exemption from anti-terrorist-intended anti-hacking legislation, it seems only logical to assume that they have already invested resources in developing hacking-style methods of attacking those whom they mistakenly believe are attacking them (good way to start a war if you ask me), and would probably not hesitate at covertly trying to subvert a network capable of doing something they don't like.

One of the easiest, most direct ways of subverting an open/public network is to infiltrate it, in this case probably by providing 'rogue' primary connections ('server' nodes) to the network. Such a rogue node could act as if it was facilitating file transfers when in fact it was merely a decoy, logging information about network use as it sabotaged the network's purpose.

Now that I've been using the WinMX Peer Network for a while, I no longer attribute the majority of the problems with the network to malice.

Mostly, it seems the problem is due to people who connect to the network as a Primary node when they should not. You should not run as a Primary node if:

When it comes to connection stability, for instance, I've noticed that many bellsouth.net DSL customers have their IP address yanked out from under them (and replaced with a new one) every hour or two! This would be disuptive enough to all the queues you were waiting in and all those waiting in your queue if you were running as a Secondary node. But when such a user runs as a Primary node, the disruption reverberates across the WPN. (Some telcos offer, for an extra $10 per month, a more stable connection -- ie, a steady IP address, but most DSL users are unaware of all this...)

When it comes to bandwidth, Primary nodes share theirs with others, so make sure you have bandwidth to spare/share before you connect as a Primary node. I know of some users who leave their machines on as Primary nodes overnight when they're not otherwise using them, but connect as Secondary nodes during they day so they can determine how their bandwidth is consumed. I've noticed that adelphia.net cable modem users only have a TOTAL of about 12.5 KBps outgoing bandwidth, which is about what a 128K ISDN connection can muster (ie, only 4 times faster than a dialup modem, despite the fact that an adelphia.net cable modem can slurp in data faster than a T1). In other words, while most adelphia.net cable modem users have very stable, fast incoming connections, they don't have much outgoing bandwidth to begin with; they certainly don't have enough to share...

So, without worrying too much about the motives of the owners of underperforming primary connections, I still want to touch on their detection, avoidance, and even logging. The following presumes you are running as a Secondary connection:

DETECTION: If you're seeing an unusually low number of inquiries about the files you are, naturally, sharing, this may mean that the Primary 'node' to which you are connected is misbehaving. Similarly, if there are problems establishing transfers, it could be a problem with the Primary connnection (or with your system, which you can reset/restart...). What can be worse is if the primary connection you are using has insufficient outgoing bandwidth to handle all requests in a timely fashion, which could result in your losing your place in a remote queue. Such situations are usually marked by very sluggish performance when doing searches or browsing others' files.

If you suspect you're connected to a bogus Primary node, get to an MS-DOS command prompt and do a "netstat". Unless you have a lot of other connections established, it should be possible to figure out which one is the Primary node to which you are connected. Look for port 6699 at the tail end of the foreign address. If it shows up with a bogus domain name, you can do a "netstat -n" and do a "tracert" to the numeric IP address. This is how you can find out if you're connected to someone with a lousy trans-oceanic connection or some AOLer with a dialup modem who thought it'd be extra kewl to connect as a Primary node...

AVOIDANCE: This may not be the correct term, for I do not know how to truly avoid such situations, other than to excuse myself from them once I find myself in them. I do this by disconnecting and reconnecting to the WPN, and hoping for better luck on the next connection. (Note that if this change of primary connections does not go swiftly and smoothly, you could lose your place in any remote queues in which you may be waiting.) Just click the Refresh button on the Networks(/WinMX) screen, and then do another "netstat" and see what changed. If the change was not for the better, repeat as needed. Based upon my experiences, you would generally do well to avoid remaining connected to any Primary node at adelphia.net or bellsouth.net.

LOGGING: This works best when you do not have a lot of file transfers (and thus, connections) established. First of all, open a command prompt window, and then type netstat at the command prompt. You will get a list of all connections (winmx and others, if any). It takes a bit of practice to understand what you're looking at, but if you do it when your only connection is to the WPNP network, then there will (eventually) only be one line in the display generated by netstat, and that address/location will correspond to your connection to the WPNP network. Usually you can tell the connection's location by looking at the gibberish name. If the name is bogus, you can use netstat's -n option to get the numeric address, and then use a good traceroute to see where the other machine is located, if you're curious. Bottom line: whenever you feel the need to disconnect and reconnect from WPNP, please do a netstat before and after, figure out which line corresponded to the underperforming primary node, and add it (plus time/date) to a text file list you maintain on your PC. One day, when these lists get compared somehow, any intentional 'rogue' primary connections should stick out like a sore thumb (and then we'll legally go after those who are illegally hacking/attacking public networks).

So if I'm having trouble staying queued or browsing others' files, or if I am seeing an usually low number of inquiries (like, say, zero) regaring the files I'm sharing, I'll change my (secondary network) connection to a different primary connection node. When I see one from another continent, the response will never be the best, but it may be acceptable. I wonder, when I'm connected to such a distant node, if it's because all the nearby ones were full or if some European felt she would get more connections by claiming to be in North America. (probably some of each...)

My connection can remain stable for weeks at a time. It is not uncommon to remain connected to the same Primary node for 24-48 hours (the "Online time in WinMX's title bar; mine's at 28 hours as I type this) once one has successfully avoided the bogus Primary nodes. With this level of stability, WinMX comes much closer to reaching its potential than when too many sharers' connections to the network are in constant turmoil.

Recently, I finally had an opportunity set up a WinMX behind a firewall (NAT router). It's almost too easy.

Basically, hiding behind the firewall/router are any number of computers on a LAN. So what I had to do was to tell the firewall that anything coming in on port numbers X (for TCP/IP) and Y (for UDP) should be directed to the machine running WinMX.

But since the firewall will undoubtedly find that PC by its address behind the firewall, it is important -- if the settings you make to the firewall are to remain valid -- that the computer on which WinMX is running have a fixed IP address on your behind-the-firewall, local (trusted side of the) network. (Something called DHCP automatically assigns LAN addresses that may seem stable but they are only "leased", and they can change depending upon which computers are online when the network's router is next rebooted...)

Like most things in windoze, setting a PC's static IP address basically involves wading through a bunch of grey rectangular windoze until you find the correct checkbox or whatever. Try control panel, Network, TCP/IP->NIC (network interface card), Properties, IP address (tab), and then specify an IP address instead of relying upon DHCP to automatically assign one periodically (this will probably also obligate you to tell that PC's TCP/IP the address of the gateway (NAT router/firewall), which you can easily do on the Properties Gateway tab).

If you're in the dark regarding the IP addresses on your network, bring up an MS-DOS command prompt and type ipconfig (or winipcfg which is fancier and takes some clicking...).

Once the PC running WinMX has a fixed IP address in the same, correct range (but out of the way of the inventory of addresses DHCP assigns) on your network, it should be a simple matter to tell your firewall/router that anything coming in on port numbers X and Y be routed to the WinMX PC('s static address).

And then, in WinMX, go to the proper Settings window and make sure the TCP/IP and UDP port numbers are set to the same values (X and Y, whatever you've selected for them) as you used in the firewall.

Apparently, X and Y get uploaded to the primary connection node, so other sharers can know how to reach you, making huge your range of choices for X and Y. While some port numbers (mainly smaller ones) are used for common services, you can pretty much choose any 4-digit numbers -- or 5-digit numbers less than 30,000 -- you want. No need to conform, though it would be good to not choose a port number commonly used for other purposes.

Of course, what it says, in capital letters at the top of the WinMX settings window, that you must restart WinMX for those settings to take effect, should be believed.








I'm going to try to find the time to make this
site into a useful WinMX(tm)/MP3 resource.

So you might want to bookmark this site...

This page is in no way affiliated with
WinMX or Frontcode Technologies

Copyright © 2001
All Rights Reserved
Updated March, 2008