Author Topic: New Client (Read 120817 times)

silicon_toad2000 · « **Reply #160 on:** August 13, 2014, 07:25:32 am »

They do make a small isolated network now and then, but for a bit of spur of the moment testing when everyone else it AFK it can be difficult to arrange.

wonderer · « **Reply #161 on:** August 14, 2014, 02:59:01 am »

Bad habit of networks, you always need more then one to have a network
may be you should say at least three

RebelMX · « **Reply #162 on:** August 14, 2014, 06:38:17 pm »

Actually you only need 1 pc.
Need a peercache, and 3 VM's running winmx on different ports. Small networks are possible without too much work.

Nevertheless, I'm yet to have any progressive contact from the 2 dev's working on the project, namely Will and GS. Offers been there now for a month as of tomorrow including explanations of what I can offer. I understand that Will's a busy guy, but if you really wanted the extra help that desperately you'd be doing everything to speak to him. I'm man enough for you to decline my offer, but please GS don't tell people publicly that you're "working on recruiting a few more hands" when some have offered for some time now. Unfortunately I'm now back at college studying, and changing jobs at the same time, however if you honestly want the help I will make the time to give you it, but let's not pretend I'm party to anything yet it just gets peoples hopes up that there are new dev's involved.

GhostShip · « **Reply #163 on:** August 14, 2014, 07:10:40 pm »

I am giving the people the impression of seeking specialist help as I am in fact doing so, I hope to be able to announce a new dev joining the dev group in the next few days, I am only looking to increase the number to make up for the lack of time available to Will.

I have my eye on a programmer who has a lot of experience using the specific programming language we are using, I haven't forgotten your offer, i do hope you appreciate however that I myself have been focused on trying my best to move the project along to ensure it does not stall, little time has been spent on other issues that would normally cause me concern.

When I speak to Will I will of course contact you directly.

GhostShip · « **Reply #164 on:** September 11, 2014, 12:21:58 am »

I think its about time I made some sort of announcement on the subject of the next OurMx beta, currently I am awaiting at least one key element from one of the dev team whom hasn't been in contact with me for a while, this is nothing new as he is very busy but it leads me to be very concerned that we may not be able to make the Sept anniversary date, I will of course let you all know if this situation changes in the next week, I have been putting this announcement off but I feel it would be wrong to wait until the release day before mentioning something so important as this, to make up for this negative news I will be posting up some new screenshots for you all to look over and pass comment on.

I hope you will all join me in having our fingers crossed for good luck, we most certainly need some at this time

[Update ] Something to look over

https://www.winmxworld.com/tutorials/ourmx_client_updates.html

Pri · « **Reply #165 on:** September 11, 2014, 05:55:47 pm »

Some nice progress shown in those screenshots!

Plum · « **Reply #166 on:** September 23, 2014, 05:45:07 am »

Why shut down if the ports are in use? Just don't connect but send the user to the port configuration page or automatically attempt another one.

I still see no work involving the ability to connect as primary or any real protocol changes (other than adding Open Nap support).

But it is good to see work is being done.

silicon_toad2000 · « **Reply #167 on:** September 23, 2014, 07:19:05 am »

Maybe I misunderstand, OurMX connects as primary fine, once it looses trhose initial primary it gets lazy and doesn't look for any more.

There's unlikely to be any key protocol changes until OurMX is working acceptably.

GhostShip · « **Reply #168 on:** September 23, 2014, 08:51:17 am »

That is pretty much correct Toad, after doing some research the problem is actually one of program flow, the primary is not actually losing any of the connections as evidenced by using xnetstat and watching the live network connections, what seems to be occurring is that the loop in the program that takes care of connection status is not dynamically updating, i believe this is to do with a lack of internal messaging of the events to the relevant counters, this then gives the impression of the loss of primary connections and the yellow flashing icon etc when in reality connections still exist, its in an area that's time sensitive, as I found out when working on some routine in that area.

One of the other developers is having a go at reworking that whole area to both improve the flow by a possibly different threading mechanism and other code changes to work past what is an annoying bug, due to the interdependency of the code to the rest of the client this is not seen as a simple fix but progress has been made and we do expect to see the end code looking more lean and functional when the rework is completed

I do often feel a disconnect between what I know works and what people have been saying works or does not but I fully understand this is a problem of having so few beta releases to fall back on and build user confidence, the attitude atm amongst those who have tried it seems to be mirrored by the following observation: that its a beta so a lot of stuff dont work and theres little patience to test further, when the reality is that once a few annoying bugs are put in context we have something powerful to build on. Under the hood the majority of the core functions are fully working, both primary and secondary client types work as does the inbuilt chat server and many of the key areas necessary to file share, beta one has a major issue in downloading files in primary mode due to a bad handshaking mechanism , but downloading and uploading work at a basic level in secondary, we have then the bones of whats necessary and theres been a lot of time spent working on filling out the further areas of the client to bring you nearly every function that you are used to , at the present time further reworking is taking place to standardise some area of code following on from a review of the client globally after many individual area have been completed. It makes sense i hope to use the same successful routines program wide when looking back at what we have in hand shows major variation in what should be identical routines, this is an issue of the scale and bit by bit construction method used, it is being approached in a professional manner and commenting of the src code has increased to bring us further along in making the whole codebase ready for open sourcing in the future, this is then the rationale behind what will be critical network changes, to get further developers involved whom may not come from within our community pool we have to have our code open to all to bring more spare hands to bear on both minor and major code areas, and with the current protocol making this a fruitless exercise ie the trade off between hoped for developer interest versus the risk to the networks users given the scope of exploitable knowledge available in the client src we have reached a stalemate in terms of making anything public until key changes are agreed and actioned.

At the current time there are still areas of the client that need completing and finalising but once those have been completed I will look to the community for both serious discussion of any proposed protocol level changes and what form they should take given the current wish not to publicise in fine detail the exploitable areas of the existing network, I am sure there is a sensible balance to be found in having such a discussion but make no mistake we do need to have it and reach a conclusion on the way ahead, the developers cannot build on sand and all should devote some time to researching technical methods and networking idiosyncrasies to assist with the effort of both stabilising our current protocol and looking deep into the future for the way ahead.

In response to Plum

Work goes on each day to try to add, improve and in the end deliver OurMx to the community, the bottle neck is as always coder time and we do our best to tackle this using organisational strategies such as assigning selected areas to individual developers but there are only so many hours in the day, I had wished to show the community the major sized amount of work that has been delivered over the last year but having had a year to read through much of the commentary of those using OurMx for the first time is was felt that perhaps we need to nail a lot more areas before casting the program to the wind, there was ans still is a lot of negativity and little grasp amongst the community of the huge constructional milestones that where delivered in beta 1, I agree it wasn't fully completed and had many bugs to contend with but we are addressing the majority of these areas of discontentment in beta 2, much will be new and fully functional upon release time to ensure disappointment levels do not reach the same numbers originally seen following the initial burst of positive commendations.

Plum · « **Reply #169 on:** September 23, 2014, 11:49:24 am »

I asked about the primary because it didn't work for me last time. I forget if it never connected, or just wouldn't search and download. Yes, I know all about firewall settings, ports, exceptions, etc., so it wasn't any of that. WinMX runs perfectly for me except the flooding issue.

Yes, using a "runtime library" approach makes sense to me. You should have a lot of standardized subroutines/functions and call them, except in time-critical places where using it inline or even abbreviating it would make sense to get rid of the overhead of the prologue/epilogue conventions. And if you prefer to work in a compartmentalized way, then you can document your APIs so others can use them without having to see them.

I am not sure the protocol details should be shared, but you could open the rest of the interface to open source. Then if someone wanted a G2 client that looked like WinMX/OurMX, they could make one - just take your interface and maybe the Gnucleus library (GnucDNA or whatever they called it) and add the routines to call in the GnucDNA code. The nice part about that approach is if there are problems with the protocol, one replaces the protocol DLL without recompiling the main executable. And you might want to try that approach of putting the protocol in a library and distributing just the blob to those who want to use the protocol, and thus one group maintains the protocol, thus conformance and patches are insured.

I hate what happened with a lot of the good networks that used non-Gnutella protocols. Kazaa was a good network, but its client contained spyware. I don't remember if the original Shareaza used its network or not, but once Kazaa went under, I think Kazaa quit working, and then both the recording industry and an open source group got the source code. I was trying to find it to install it after not having used it for a while and I downloaded a fake version of "Shareaza" where it said I had to pay to use it. I removed it and then found it on SourceForge. But it was not as robust as the usual. Then the Gnucleus guy invented the G2 protocol, and Shareaza used G1, G2, eDonkey2k, and Bearshare as its protocols. Then there was WinMx, but we are taking care of that situation and filling the niche.

Then there were filesharing clients that disappeared because of lawsuits, threats, or political pressures. There was once an Aimster, where some gal named Amy came out with a client until AOL threatened to sue over the name. So it became Madster until it went under.

GhostShip · « **Reply #170 on:** September 23, 2014, 08:15:01 pm »

This network wont go under without a fight, even the attackers know that no one here will ever give up, we might come and go but we are patient.

I have looked at other network architecture's and protocols and in the main they fall into a few camps with kazza and Gnutella 6 being the most similar to the WPN, I don't think theres the wish to create an entirely new primary networking system so the way ahead is to fix the weaknesses in the upper tier backbone, there are a few ways to achieve this but all will entail an increased network cost, we can no longer rely on the honesty of previously trusted developers who have a bad day and want to trash the entire network for what amount to pathetic personal reasons, a new protocol should be safe to use against even the most knowledgable developer, only with this level of protection can we finally say never again, so far we have lost hundreds of thousands of users because of Michael Jones tantrum, at the time I told folks it was necessary to block him distributing the hitherto securely held information across the network, many of his fanbois copied the data and shared it with literally anyone who wanted it breaking the chain of trust and responsibility built up over many years, the root of all our problems lay with his traitorous act against this community,

I mention all of this as I have now always to consider a rogue or disgruntled developers capabilities when judging the potential success of otherwise of any anti attacker mechanism, this is the new "level" of secure decentralisation we have to achieve if we are to regrow the network and ensure finally that no one is in charge of it, its not a simple solution we seek but we must endeavour to deliver it and to share the mechanism openly for others to employ also , there can be no "winmx gods", all are equal and all should remember they also hold the same community responsibility to keep this network alive as the skilled developers who work towards those aims, free riding should be a dirty word when the community needs urgent help.

Plum · « **Reply #171 on:** October 04, 2014, 11:21:45 am »

Any more news?

White Stripes · « **Reply #172 on:** October 04, 2014, 01:14:40 pm »

Quote from: Plum on October 04, 2014, 11:21:45 am

Any more news?

honestly? not the best kind... but its still moving along...

GhostShip · « **Reply #173 on:** October 04, 2014, 03:51:40 pm »

Indeed it is.

When its possible to gather all the ourmx development folks together for a code merging event you can all get your hands on the next beta, until then I can only ask for your patience, no ones more eager than myself to enjoy the fruits of such labour

Plum · « **Reply #174 on:** October 11, 2014, 07:57:09 am »

Just checking in...

GhostShip · « **Reply #175 on:** October 11, 2014, 09:02:38 am »

No problem Plum

Things are still progressing well and I have a few days booked off from work to try to regain some ground, while I wait till the other devs are able to bring their work to the communial table further bugfixing feature placement and improvements will continue, we have a nice mound of code at this stage and it can only get better with time, I received a message recently suggesting we could have the next beta done within a matter of weeks but atm thats not firm but I will from this end treat it as firm when deciding on what work is to be prioritised, the opennap version is scheduled for beta 3 after all so that will be shoved to the back of the pile and other wpn specific areas will be focused on with a view to making things smooth and fully operational.

As always cheers for your patience and interest.

Plum · « **Reply #176 on:** October 16, 2014, 02:06:47 pm »

Quote from: GhostShip on October 11, 2014, 09:02:38 am

No problem Plum

Things are still progressing well and I have a few days booked off from work to try to regain some ground, while I wait till the other devs are able to bring their work to the communial table further bugfixing feature placement and improvements will continue, we have a nice mound of code at this stage and it can only get better with time, I received a message recently suggesting we could have the next beta done within a matter of weeks but atm thats not firm but I will from this end treat it as firm when deciding on what work is to be prioritised, the opennap version is scheduled for beta 3 after all so that will be shoved to the back of the pile and other wpn specific areas will be focused on with a view to making things smooth and fully operational.

As always cheers for your patience and interest.

Yes, I'm still around waiting for something more usable. In the mean time I use Shareaza. Another project I am following is ReactOS. It is slowly coming into shape.

White Stripes · « **Reply #177 on:** November 18, 2014, 10:44:53 pm »

i hate to stir this thread but its been a while since the last post.... how is the new client coming along? things going good? bad? indifferent?

GhostShip · « **Reply #178 on:** November 18, 2014, 11:49:05 pm »

Anytime is good for me Stripes

I have successfully added the browse filter window feature many have requested and have made a lot of barely mentionable bug fixes but I am currently fighting with one particular area of code thats used ( and failing

) in 3 places and would be a decent bug to resolve, as usual a lot of redundant code has been removed and work is going on to update and smooth over many other functions, I got bored last month so I have also embarked on a major rewrite of the upload download engine to follow the design model, it was originally legacy code and whilst it works its not offering the functionality we need and with time to spare until another of the programmers appears I thought I need to get on with that also, feel free to ask about any specific issue that has your interest as so much goes on I often forget whats been done across this year.

The user experience is a lot smoother but I could do with with some assistance from the community elves *cough*

GhostShip · « **Reply #179 on:** November 26, 2014, 09:37:48 pm »

Added a few more updates to the usual location displaying recent OurMx development progress, I hope those of you who requested browse filtering will be pleased and reassured we are listening to your requests.

https://www.winmxworld.com/tutorials/ourmx_client_updates.html