This page contiues on from the previous one and here we will examine what is meant when people talk about the WinMX Protocol, it is actually not a single protocol but a collection of different protocols used within the one client.
Let us look at what we need the protocols for firstly at a model level and later on we will look at specific implementational details.



This is the most commonly used and well documented part of the WinMX protocols and basically covers all traffic between a chat client and a chat server or chat room hosted using WinMX.
This protocol is TCP based and will need updating to handle some aspects of the future but in the main is pretty much best left alone, new packets are added by specific developers at intervals usually to deliver a new function on a specific chat server.



This is the protocol as used by WinMX clients operating in "Secondary" mode,  most of the
common p2p functions are referenced in this protocol and its the largest protocol out of all of those we will look at for reasons I will explain later. This protocol is also TCP based.



This protocol is a multi-part mechanism featuring a gnutella style network format and various sub packets consisting of the numerous network communications including node discovery, search and chat support for the lower tier secondary clients.
Multiple Security mechanisms exist within this level of operation but we will not be discussing any of those here as the idea is that we work on new models and better security afresh.



This Protocol is the larger of the two primary protocols and forms an important part of the networks ability to handle a lot of fast traffic, TCP usage would not be acceptable for many of the operations undertaken by these specific packets such as search results and chat list results.
Security mechanisms exist within this level of operation also.





The file transfer packets themselves are very minimal and limited to individual file transactions between users however some interesting aspects of the general filesharing protocol are to be found in the que management area.
The actual transfers are broadcast in plaintext unfortunately and based mainly on the Napster/OpenNap Transfer system with some small additions.
The Secondary Protocol contains the majority of the management overlay used by the transport/filesharing layer.



Earlier I said I would explain why some protocols are larger and some smaller, the main reason is the type of network they are required to service, this alone dictates the level of packet complexity.
On a fully decentralised network the packets have to protect the entire network against any single client issuing defective traffic so they have to be very strong or the entire network is lost, converely if we look at the OpenNap Model with a simple server client arrangement the security needs are very much reduced as there are only two parties in the arrangement.

The WPN being a hybrid mixture of both systems requires a mixture of both levels of security , also a decentralised network with a large overhead would quickly melt down under its own weight so for such networks the approach is to have fewer packets at the network level and bigger and more types of packet at the lower traffic levels.

I hope its been helpful to some of you to see how much there is actually to learn regarding how the
WinMX/WPN network operates and further understanding will I hope allow for us to create something new and special to replace the broken parts.