New Years Focus

[GhostShip]

Folks this year has like last year been fairly quiet and in the main peaceful bar one or two mindless events, however with peace comes forgetfullness and the concept of sitting on our laurels, this for our online community spells bad news in the long run, if no one is bringing initiatives or ideas then others are unable to fit their skills into the jigsaw, thus we all lose out and folks become bored. 

At the core of our community is our usage and enjoyment of the winmx application and the facilities and features it provides, have we reached the pinnacle of what we can acheive here ? I dont think we have but more important is what do the rest of you think ?

What do you all want to happen next year in terms of activity and what should be our key focus, also what are you all prepared to do to help achieve the aims and goals of the rest of the community, if the answer is little then we will see nothing change and a slow rot of our highly skilled userbase, something I have seen a taste of over the last year, such folks need ideas to focus on and those ideas in the main come from yourselves.

If you have a bit of spare time and some ideas please post them here and lets see what folks want and how we as a group can acheive it, many hands make light work so lets put something back if we can even if its just a few words, the future is as its always been, what we make it folks.


Happy new year from all the staff here to all of you our friends and fellow users 

[Pri]

As everyone is aware, WinMX is going to die unless we get a new client. Already most of the people in chat rooms are there for chat instead of files. We need a new client more than ever that has download and upload capability.

I've been thinking for months on how to do it. How to make an improved protocol to support extra functionality that we cannot yet deliver. For example 64-bit addressing for files so we can have over 2GB file sharing. And I've come to the realisation that the only way to do it is to abandon current WinMX Primaries.

At the moment if you have an 'Enhanced' Client one that supports browse windows above 5000 entries, files above 2GB in size and so forth. If that client connets to the network as a secondary peer or attempts to make file communication with another enhanced client that is a secondary peer then they are both connecting through winmx primary clients. And that means their extended protocol is not used because the primary winmx will ignore these extra bytes. Which means both the enhanced clients will lose the ability to browse more than 5000 files in a browse window and wont be able to even view a file thats 2GB as the Primary client wont display them.

The only way around this problem is to axe the ability for WinMX (the default clients) from being able to go Primary on the network. And instead have the new clients take over the Primary job and also setup some kind of new client that is just a network node. A type of advanced dummy primary peer that we can setup on a few dedicated servers which hold hundreds of secondary peers. This is the only way we can allow both WinMX (old clients) and new Enhanced clients with Enhanced protocols to coexsist on the same network.

The alternative to this is to abandon WinMX compatibility entirely and simply have two WPN networks, or we close down the WPN network (current one) and start a brand new one that only enhanced clients can connect with.

I know I'm going on a bit here but I've given this a lot of thought recently and I really cannot see anyway that we can produce a client that can both share files with WinMX on a WinMX (default client) operated network whilst also delivering enhanced functionality for a new breed of client. It's not possible right now.

I think in the future we are going to have to make a tough decision to either abandon WinMX as it is and move to a new client or abandon hopes for a new client and ride WinMX (as it is today) in to the ground.

-------

Apart from the WinMX stuff I intend to release more code in 2010. One of the things I'm writing currently is an Ascii Art displayer which works a bit like Cydia or Apt get if any of you have used these applications. You basically get the software from me and it doesn't contain any art, but you can then add in URL's to repositories of art hosted by the ascii artists themselves (with their logos / copyright intact). This enables people to enjoy artists work on WinMX while giving the artist full control over the art so hopefully it will end the stealing that happens which makes artists rightfully angry. I've already spoken to many prominent ascii artists on WinMX and they are all willing to give it a try. I intend to write it as a Metis script and it will be heavily commented so others can learn from it and mess with it for their own usage. I was thinking about writing it for WCB as that seems quite popular these days but I've yet to see anyone edit WCB plugin sourcode and re-release it or even use it in their own room. I think the fact you need a compiler and proper code experience to even modify WCB plugins has put some people off it, so when I decide to release things with source I will use Metis instead.

That's pretty much all from me at the moment. I hope WinMX goes on I do enjoy the community a lot.

[Lagerlout666]

The only way around this problem is to axe the ability for WinMX (the default clients) from being able to go Primary on the network. And instead have the new clients take over the Primary job and also setup some kind of new client that is just a network node. A type of advanced dummy primary peer that we can setup on a few dedicated servers which hold hundreds of secondary peers. This is the only way we can allow both WinMX (old clients) and new Enhanced clients with Enhanced protocols to coexsist on the same network.

Thought about that alot too, many nights pondering how to do it. And the simple answer is to make any new client's primary network use different keys. So only new clients will connect to new clients. And also add support for the old network. So in fact you are running on two primary networks. The client will search both both networks and can stay within each networks rules. Until of course the old network becomes too unstable as people move over for encrypted transfers etc to a new client and the old network can be phased out.
This would make it much easier on a coder to jut copy winmx for the support section. and he would do what ever he wanted on the new primary network, ie encrypted transfers newer packets for chat rooms like the who is typing stuff that seems to be popular.

[']['affy]

something needs to be done otherwise the way things are going mx will become another backbencher app, many rooms ive parked in can go idle for days if not weeks, they just park up and say nowt ppl are getting bored of the same ol thing and i doubt i'm the only 1 thinking the same. MX may not be at its height like it was in 2005 but there are still dedicated mxers out there that love MX and would love to see a new client in any shape or form but only prob is is the lack of coders that has enough time to put in the work if none can be found on mx then we need to spread out further afield.

[bu44er]

I know this is not an idea but I have some skills in HTML and CSS coding and have a couple of spare machines that can be used for Peer Cache Servers if needed. Apart from that if anyone needs any help with anything send me a private message or say here and I'll help where I can.

[GhostShip]

Your offer of resources may not be usable just yet but my thanks for making that offer all the same Watcher, the assistant I myself need to make client progress is help with MFC c++ coding, though there are other projects in the pipe that are being written in C# by more than one coder, what we need is folks to match their skills to certain tasks and that doesn't just mean coding it means structural design,flowcharting, documenting, new app ideas, protocol enhancement ideas and even implementations or even just simple links to usable resources that may have been missed.

We also must never forget to let the world know where we are and what we fight for here, word of mouth now brings in a large percentage of users to MX so opportunities exist to help MX in other ways besides the long slog of creating our dream app. What many folks over-look is that we don't just support our own projects, we offer and have delivered help to other sites and users who support WinMX, our message of "united we stand" is the same as it always was, each one of us can make a difference and be more than we thought, I know this through doing activities here myself that seemed impossible to me some years ago, and now I in turn hope to see this concept work for you all, there's nothing better than being respected by thousands of people who will never meet you in real life but who understand your a person they can trust and look up to, this can happen with any of you given enough time and effort. 

Pri:
Its great to hear of some ideas and of course there are ways to enhance the protocol that can be fitted in with our existing network but one point I would be wary of from your post above is server implementation of a primary client, whilst in theory a great idea it leaves the operator firstly open to a shut down order as many open nap operators received when operating their network clustering (judges are not know for their tech savvy) and secondly there will be a ongoing financial cost to such a server operation as well as the risk of losing hardware, whilst I applaud your commitment I would be letting you down if I didnt raise this issue with your idea at this stage, what could be of more use than a server at this time is some actual fleshed out "new" protocols that we can all look over and finalise for a future client implementation , a "community" enhancement set that all developers could include as and when they are able, this gives scope for many fresh conceptual permutations. 

Step out of the woodwork folks, each set of your skills will not be wasted 

[Pri]

When I said about the server nodes that act like a primary for hundreds of secondary users. This would not be a long term thing. This would only be in operation for a few weeks while users move over to the new client which would then take over primary duty and the dedicated servers operating the Primary Nodes could be shutdown.

As in my idea disabling all WinMX clients from being able to act as primaries would leave the network incredibly unstable unless there was something to fill that void whilst people moved over to enhanced clients. Obviously I already thought through the C&D orders and legal issues and shutdown requests that would happen for anyone operating a primary node and it was only intended as a temporary solution for literally a couple of weeks during the transition.

I do like Tiny's idea but I've spoken to some people making clients and I suggested that very course of action, having enhanced clients that had their own WPN network where they only engage their Primary/Secondary roles with clients of their own whilst still connecting to the traditional or legacy network to work with legacy WinMX clients but none of them like that idea. I've heard the words 'to much work' and 'not worth the bother'. I think at-least the coders I talk to would rather kill WinMX off than support it properly.

[GhostShip]

I have to say I too have heard that sort of talk, in most cases when questioning the programmer more closely its actually the case that they want to rewrite the whole protocol but when pressed for implementation or fine detail on whats to replace it they are not so forthcoming, what they seem to have overlooked in the main is the many layers of security WinMX brings to the table such as the network encryption, primary double handshaking etc, some have no idea what those do for us all yet they are key components in achieving a stable and secure network.

I,m pleased to hear the Super-Primary would be of a temporary nature  


Is there anyone out there able to bring some intel to bear here on what the new protocol should look like or even better show an implementation that offers an encrypted data stream as a prerequisite ?

[Bluey_412]

Compare the WPN with a VPN across the internet...
The most basic of all comparisons. What keeps the VPN private? VPN is effectively a geographically spread LAD, using the internet for its connections...

Now take that basic premise, and look at what a new WPN could be, can it be built that way?

THEN build your protocols for connecting, encrypting, etc...

The whole thing is just a VPN...

Do i oversimplify? maybe, but maybe i can trigger someone's thinking

look where the old/new WPN's fit into the 7 layers of the network architecture, maybe some are looking too high to find a way to make it work. WPN should operate lower, around transport level...

[GhostShip]

I cant see the need to reinvent the wheel Bluey so what sort of real-world network architectural implementation do you have in mind as making something from scratch will take more time than anyone has to spend.

What I,m asking in short is is there a working model for what you have suggested that can be built upon in timely fashion, the aim here is not complete privacy of IP address on the network but complete privacy from any ISP who refuses to honour their status as a "common carrier", there are other potential implementations that offer extra security but for now I don't see a real reason to go to full obscuration of IP and heavy encryption as to do so would add a burden on all involved that many could not meet in terms of hardware requirements and network demands.

[bu44er]

I am sure given time, something good will happen with Winmx. Please remember that there are still loads of people who love Winmx, people who will help and make the future of WinMx brighter.

[Pri]

The problem with encryption is its to easy to detect. There is always some part of the encryption that can be recognised by the ISP's equipment. Their is an entire industry that produce hardware for this sort of thing.

Some ISP's have even gone to the extreme lengths of throttling connections that are not whitelisted. For example transmissions that do not meet what they call normal encryption types as they believe those to be P2P.

On the one hand Encryption is important, but on the other hand it isn't. We want to hide what it is we are sending/receiving which is what makes the encryption a good thing to use but it won't help us hide the fact that we are running WinMX and it wont stop ISP's from being able to throttle or block our connections from establishing which is where they are headed as time goes on.

But regardless of this I don't think any client makers at the moment do not intend to implement Encryption. I've spoken to one yesterday who said to me 'It would be easy' to implement the same WinMX encryption on 64-bit transfers.

He has also thought about another way we could do an enhanced client within WPN. And that would be by delivering an updated version of the Eagle Patch which when run on a WinMX client that is running as Primary will intercept certain packets from clients running the enhanced protocol and able to forward those on to other enhanced clients and WinMX primaries (which are also running the updated patch). The other alternative he thought of was to have us update our Peer Cache software to dish out primaries to Enhanced clients that support the enhanced protocol while still dishing out normal winmx clients to other normal winmx primary peers.

Both ideas I think will solve the issue as we move forward. I think one thing we definitely need is a forum dedicated to enhanced protocol information and we need to detail the guidelines of what your enhanced client must support otherwise we may find ourselves with 2-3 clients that are incompatible with eachother. Standardisation is important.

[GhostShip]

One form of potentially sound transport encryption is ssl, if we could wrap up the existing client file transport layer using ssl at patch level that would be at least a temporary step in halting one of my main concerns and of course blocking it would something no ISP would propose.

We are aware that in the main much current filtering equipment does not detect winmx network activity due to the proprietory encryption in usage and possible legal issues with breaking a "digital lock" but will detect the unprotected "get" and "send" strings in the current file transfer protocol, this has been confirmed by the DPI vendors themselves, also blocking clients at pre encryption cache stage has been seen in italy and one or two arab states, thankfully this anti p2p route is rare.

Whether new client, patch or any other idea we all agree it seems that some action is required and we need to set to work as a community in finding how best to deliver the action of concensus and in the shortest space of time, on the more mundane side of things this involves planning, design and other boring but vital tasks that then lead on to a proposed implementation in detail and finally a finished specification and that will act as the template for those who want to actually build something in software.

The key ethos is in my view quality work and solid commitment to whichever path is chosen or indeed many paths if thats what is required, nothing less will see us to the end of the virtual arms race we face at this time, we have a lot of brain power folks lets set to work and prove it 

[Bluey_412]

He has also thought about another way we could do an enhanced client within WPN. And that would be by delivering an updated version of the Eagle Patch which when run on a WinMX client that is running as Primary will intercept certain packets from clients running the enhanced protocol and able to forward those on to other enhanced clients and WinMX primaries (which are also running the updated patch). The other alternative he thought of was to have us update our Peer Cache software to dish out primaries to Enhanced clients that support the enhanced protocol while still dishing out normal winmx clients to other normal winmx primary peers.

Pri, that addresses the 'Backward Compatibility' side of things, to a degree, altho the 2 networks would not have intercommunication, but may bring about a hastening of upgrading by users to the new client.

Many ideas are being raised, i think that a better forum is needed to discuss all this, an open room, where ppl CAN sit, comment, brainstorm, toss around ideas...

Certainly my input here is not concrete, alas, i would that i could offer more, but am not sufficiently informed of the design of the current protocols, i am simply offering some 'prodding' thoughts...

All software goes thru a design stage, before the hard coding work, we need to follow that concept, design what is needed, then the 'simple work' of coding can be done

level 1 design would be the roughing out of the ideas, systems, etc, then at level 2 the detail is built, what goes where, how things work, etc, then the final design goes to coders yes, coders plural...

The very decentralised nature of WinMX is what makes it tough. Where is Head Office? we dont have one. Where is our R&D Section? we dont have one. where do we sit and hold our round-tables to toss ideas around? We dont have one (except our individual terminals)

Thats our main challenge, how to work collectively,for it is a collective work

[Ace]

No need for design as such, design basically there look at mx it self
problem is people dont understand how the p2p protocol works and how to write a protocol
 
For example if you would start fresh you could use


ie for the file transfer =  

A user < for example, User1;IPAddress 1,2,3,4   > wants to send a file named FileName.txt  to anther User < for example, User2; IPAddress 3,4,5,6

. User1 sends [file][User1,User2,][Filename.txt] to the server ( ie TCPListener )

. the server sends [file][User1][Filename.txt] to User2 to confirm he wants to receive the file

. if the User2 wants to receive the file he will then send [Send_File][User1,User2] to the  server indicating that he wants to receive the file

.User2 starts to Listen at port 501 for incoming data ( port n0 just a example)

. The server looks up the IPAddress of User2 ( which would be a hash table of ips) and sends [Send_File][3,4,5,6]  to User1

. User1 starts the FTP  ( file transport protocol ) service by sending the file using the IPAddress <3,4,5,6> and port number 501

plz Note that for  file transport protocol  the Actual Transfering of Files takes place between  the ( TCPClient ) clients the server is not involved  it just a echo server and this is just basic protocol of the browse user in a chat room this is not a primary client side


Once you have got the basic design/code then you use encryption on the primary /secondry
ie add on ado.net or use mircosoft  The Caching Application Block < cache software >
 to build the  search file side of it and primary Node s HashTable


THIS IS JUST A IDEA so people can understand wot is said by a protocol when ppl ask wot is your design of a protocol.


 

[bu44er]

I actually think that is a good interpretation of how it works lol. I never got to know the insides out, that will do for me lol.

[GhostShip]

For much of the secondary side we have the relevant flow chart information and in most programmers vaults many have the primary flowcharts that they keep private for security reasons, the majority of the 4 types of winmx protocol is known bar a few small items that are better off being kept so, we have an area on the site here for programmers to gather and converse but actually getting any of them to do so is a major problem, most are great folks and not heavy industrial coders and I hope its because they are not confident their code is of the best quality that most seem a bit shy, however as someone who has seen a lot of third party src I have to say that if they are thinking this its definitively not the case, most are excellent programmers with a fair degree of skill and neatness in their coding, some of you may be asking why your not using a new wpn client by now then if they are so good ?

The production of a client that all users will adopt is no mean feat and will take more that one or two ppl to produce, most of our coders are either at full time education or full time work so I have been of the mind that I have no remit , consensus, will or authority to demand they work on such a project although I do my best to support those folks who do, this year I would like to make it public that we need a new client and if help is going to come now would be the best time to deliver it, we don't even need "expert" level coders even fast learning beginners can do many of the tasks that non coders have no clue about, and non coders can create specs, designs and implementations there is room for all on such a project if the will exists to get it rolling ,with enough community backing that is.  

We need then at base level some project managers and under them some all round knowledgeable folks to work with the coders and designers, and once both those layers are ready all the plans specs and data that the coders need can be delivered to them and perhaps an area of the client can be assigned to each one of them to ensure they know their "bit" of the clients operation inside out, thus giving an avenue for self publicity, improvements and general updates, the real question then is who is going to head up such a project or projects and who will be the folks to gather and deliver the actual design/implementation (everything possible bar the coding level) to the coders.

Looking over a project such as a gnutella network client it seems the average team size is about 10 folks and of those one or two will do the hard coding and the rest run support around that effort before and after so anything from documentation to testing is done within the project group and the project manager can be someone who orchestrates the whole effort, gives helpful advice when problems hit and more basically ticks the boxes as each task is completed whilst as the same time not directly stepping on the coders toes, this is I think the ideal. we have tried twice to set up a specialist winmx coding only venue but without input from folks it doesn't work and both those efforts proved merely helpful for solidifying some of the information we hold and the generation of a quantity of tutorials for developers that are not in the public areas here, thus we don't have to start from zero, we do however need to start somewhere as I for one am concerned that valuable users and their skills could and have been lost before we can enshrine their input into something tangible that newer community members can carry forward with them, also projects without any oversight often fail for trivial reasons I know many such projects where a coder has hit a snag had no support and the project then hit the dirt, thus a manager is an equal member of a development  group even though they may not be fully clued up on coding techniques or technologies.

Must say this topic is close to my heart so I,ll stop typing for now but I hope I have shared with you all just whats involved and the scale of the effort needed if folks want something more than yet another chat server of chat client.
  

[{MXC}michael]

im on board to help,   been using mx for  7  years now,   known some of u guys  for that length too,  be a shame to see the MX community desintergrate.  how about bring KM  back lol

[GhostShip]

I,m not sure that is either possible or something helpful as we need to stop relying on one or two folks and actually all get our hands dirty, its folks taking the easy route (doing nothing) thats ensured we havent gotten a client already.

KM has done his share of the work I feel, now lets organise so we have some new folks to look up 

[bu44er]

You know what f**k this, for to long I have waited for WinMx to get developed. I aint sitting around waiting for someone or something magically to happen. I am far more than capable of coding HTML and CSS and some basic Java, that I have learnt myself.

I know that I am more than capabe of coding something given time and being pointed in the right direction as I would have to learn as I go. Providing I get the support, something will come of it. ANYONE wanna help me along here.