Looked at the update bar on 3.31 recently?

[Bearded Blunder]

Presumably the same "Upgrade available" message also appears using unpatched WinMX.  Clicking the link redirects you to another p2p app's website, I won't post a link.
Just thought I'd mention.

[White Stripes]

unpatched it does... and this is quite interesting ... it looks just like winmx but winmx does not connect when unpatched so im guessing it doesnt use the WPN but something similar... not sure id download this till we know who made it... *combs through the site more*  ....it seems to be related at least in part to tixati?? anyone else had a peek at this? ... yes yes i know no links but it branches right off of winmx.com itself... moniker is used to hide the whois info for who owns winmx.com now so...... yeah....

...kinda nice there is a linux native version tho if this thing really is legit... im tired of wine...


btw, you really shouldnt be using 3.31 .. im not sure the patch is fully compatible with it...

[White Stripes]

more tinkering... this thing is actually legit... its a totally new network and the software is owned by tixati so its the same author as winmx itself ... not many users on right now but... yay.. new toy to play with

[Pri]

For years we've wanted a new WinMX. Well we got one now. It looks almost the same, made by the same guy and with modern feature support like IPv6 and larger than 2GB file transfers.

I hope it takes off, I'd be fine switching over to it if it gains the users.

[GhostShip]

I tested ver 1.12 and found it didnt close when it was supposed to but havent had time to look at the newer versions yet, lets hear some more feedback on this exciting developement and of course report any bugs to kevin using his forum.

[White Stripes]

use the newest version... right click the system tray icon to exit the program... its light blue and barely visible on an xp taskbar if you are still an xp holdout...

i have the linux version (64bit) running just fine on my machine

[GhostShip]

I am not sure why no ones actually posted a link but its always been my view that any software from the WinMx developer is good stuff so please all do take a look, it might be just  what many have been waiting for .

https://www.fopnu.com/

[reef]

i wonder if the name stands for   "for old peer network users"   lol   

[White Stripes]

i wonder if the name stands for   "for old peer network users"   lol   

thats an excellent take on the name lol

a bridge between the chat protocols of wpn and fopnu would be a great, but for now running the two clients side by side sharing your library on both networks would be a great way to get fopnu off the ground... chat admins starting some channels on fopnu and advertising it in their winmx channels would be perfect...

the biggest advantage of fopnu is that its code is actively developed... so defenses against attacks will happen as attack vectors are found...

and of course ipv6 support is icing on the whole cake since the ipv4 address space has been exhausted...

[Pri]

I tried it today the client feels sparse right now but the foundations seem solid. One of the things I find interesting is the channels appear to use a P2P Mesh topology which means rooms cant crash and don't need central hosting, every peer in the channel is responsible for the sending and receiving of their own messages. I think that's smart. Not so great for individual peer security (easy for people to DDoS members of the channel offline I suppose).

A great start

[Pri]

I've opened a Renegades channel on there. Found quite a few chat related bugs, due to the mesh topology it is not very forgiving to clients that have poor internet, you will find yourself missing large swaths of the channels chat messages as they become lost and not re-transmitted.

From what I can see it uses UDP for all chat related activity (messages, joins, parts etc) and the developer has not built in his own packet acknowledgement system (ACK) so if a client doesn't receive your message you will not know it as no acknowledgement packets are sent when messages are received successfully.

This is also the case for joining and parting. It appears the clients ping each other every 40 seconds or so but if a message isn't responded to it is presumed the client has left the channel even if they haven't and only that one packet was lost.

So you can have a scenario where it says a user has left the channel then suddenly they write a message and you receive it even though they're not (to you) in the channel anymore. You can also have multiple leave notices or join notices for people who haven't appeared to have left or entered the channel.

My first impressions of the chat system are pretty bad, it needs a lot of work. I personally think going with the mesh system for the chat was a bad idea, going UDP only without creating their own custom protocol with checksums and acknowledgements was also bad. For sure these things can be sorted out over time but so far, quite buggy and not good for people with poor internet access.

Looking past these bugs which are fixable I think it has three major flaws overall that in my opinion should make them switch to a Client<->Server model.

1. Everyone inside the channel is responsible for their own connectivity. If you're in a channel with 1,000 people you have to send your chat message to 1,000 people. That is going to be difficult for someone on dialup or other poor internet. It will create significant lag for people living in remote areas or with poor internet.

2. Everyone inside the channel has access to everyones IP Address, this could allow them to perform attacks on people in the room who share views they don't like. Again a Client->Server model would fix this.

3. It's impossible to innovate in the chat space beyond what the Fopnu developers provide us. If they don't feel like adding colour chat support we don't get coloured chat support. If they don't want granular permissions for our staff of a channel we don't get it. At the moment it is as basic as WinMX self-hosted chat rooms and we created WCS, FXServ, EServ and so on because we wanted granular control and lots of features, the chat on Fopnu will never have these capabilities because the clients themselves are all hosting an individual instance of a channel and merely passing messages to each other.

None of these things can be fixed with a mesh topology except the third one (features) but that will require dedicated work and I don't think they'll ever be able to bring up the in-client chat experience to that offered by a dedicated server that can be innovated on separately to the main client.

But it's not all doom and gloom. I still think the clients browsing experience, ability to share large files, folders of files even and IPv6 support is excellent. Of course I spend most of my time when I'm on WinMX in the chat so that is where I'm concentrating most of my criticism but the foundation of what they've built away from the chat aspect seems solid to me and so I will continue to host my channel on the network there.

[White Stripes]

pri, you should join the fopnu forum https://forum.fopnu.com/support/ and voice your technical critiques there as well. the developer should hear about the flaws so they can fix them

[Bearded Blunder]

btw, you really shouldnt be using 3.31 .. im not sure the patch is fully compatible with it...

I have particular reasons for using 3.31, namely that the HTML logging provided by BendMX works, so 3.31 sits for that reason and produces nicely formatted room logs.
I'd use KM's patch for that instance except I also use it to give my RoboMX a reliable way to connect by specifying that primary. KM's patch resists such connections, and Robo is at best "iffy" at connecting using the peer caches, no matter which ones are specified, at least in my experience.
The sudden appearance of an update bar on 3.31 last time I restarted that client took me by surprise is all.

I am not sure why no ones actually posted a link but its always been my view that any software from the WinMx developer is good stuff so please all do take a look, it might be just  what many have been waiting for .

https://www.fopnu.com/

Basically I got as far as a WHOIS.. found moniker.com and didn't look much deeper beyond a cursory glance at the site, I wasn't about to post links in case it was something that was "iffy".  Hadn't realised it was from the original developer, though perhaps control of the winmx.com domain is a clue.
A new network with a (needed) protocol change does indeed sound like good news if it takes off and the bugs are ironed out.

[GhostShip]

I very much appreciate your caution when it comes to posting links, like yourself I'm hopeful for the future if the developer delivers some of the features we already have in "Mx land" in the new client.

[Pri]

Robo is at best "iffy" at connecting using the peer caches, no matter which ones are specified, at least in my experience.

I've not had any issues with this personally, whenever I launch RoboMX with all the same caches specified as WinMX uses it connects in under a second. I'm using RoboMX v2.08 for the past I dunno 6-7 years and it has always been that reliable for me.

[White Stripes]

「fopnu」のユニコードサポートは、日本市場にとって大きな魅力を発揮します。 誰もここで日本語をネイティブに話す？

[White Stripes]

and Robo is at best "iffy" at connecting using the peer caches

have you connected using the localhost primary option? that always works for me...

[Bearded Blunder]

I've not had any issues with this personally, whenever I launch RoboMX with all the same caches specified as WinMX uses it connects in under a second. I'm using RoboMX v2.08 for the past I dunno 6-7 years and it has always been that reliable for me.

Takes me 10 minutes plus to get a connection that way (if at all).. hence going off into "Expert options" and connecting via a specific primary.  I'm running v2.06 hex edited to specify cache.  Have been running that way since the big shutdown. It's a non-issue since I have a primary I can connect through.

have you connected using the localhost primary option? that always works for me...

If I ran primary on my main machine.. however I specify a primary elsewhere on my network (that 3.31 instance since it runs 24/7) and that *is* reliable and fast connecting.  Can't remember what it is now, but there was a specific reason I stuck with 2.06 rather than going to 2.08.

[White Stripes]

downloaded this; httpss://archive.winmxworld.com/MxControl/RoboMx/RoboMX208_en.exe

edited RoboMX.ini to change the peer caches listed to better match whats in oledlg.ini (the eagle patch)...

it connects as soon as it starts... heres the list for handy drop-in-place use...

Code: [Select]

[PeerCache]
Count=61
Server_000=cache0.winmxworld.net
Server_001=cache1.winmxworld.net
Server_002=cache2.winmxworld.net
Server_003=cache3.winmxworld.net
Server_004=cache4.winmxworld.net
Server_005=cache5.winmxworld.net
Server_006=cache6.winmxworld.net
Server_007=cache7.winmxworld.net
Server_008=cache8.winmxworld.net
Server_009=cache9.winmxworld.net
Server_010=cache0.winmxcache.com
Server_011=cache1.winmxcache.com
Server_012=cache2.winmxcache.com
Server_013=cache3.winmxcache.com
Server_014=cache4.winmxcache.com
Server_015=cache5.winmxcache.com
Server_016=cache6.winmxcache.com
Server_017=cache7.winmxcache.com
Server_018=cache8.winmxcache.com
Server_019=cache9.winmxcache.com
Server_020=cache0.winmxconex.net
Server_021=cache1.winmxconex.net
Server_022=cache2.winmxconex.net
Server_023=cache3.winmxconex.net
Server_024=cache4.winmxconex.net
Server_025=cache5.winmxconex.net
Server_026=cache6.winmxconex.net
Server_027=cache7.winmxconex.net
Server_028=cache8.winmxconex.net
Server_029=cache9.winmxconex.net
Server_030=cache0.winmxcache.net
Server_032=cache1.winmxcache.net
Server_033=cache2.winmxcache.net
Server_034=cache3.winmxcache.net
Server_035=cache4.winmxcache.net
Server_036=cache5.winmxcache.net
Server_037=cache6.winmxcache.net
Server_038=cache7.winmxcache.net
Server_039=cache8.winmxcache.net
Server_040=cache9.winmxcache.net
Server_041=cache0.winmxconex.com
Server_042=cache1.winmxconex.com
Server_043=cache2.winmxconex.com
Server_044=cache3.winmxconex.com
Server_045=cache4.winmxconex.com
Server_046=cache5.winmxconex.com
Server_047=cache6.winmxconex.com
Server_048=cache7.winmxconex.com
Server_049=cache8.winmxconex.com
Server_050=cache9.winmxconex.com
Server_051=cache0.mxpie.co.uk
Server_052=cache1.mxpie.co.uk
Server_053=cache2.mxpie.co.uk
Server_054=cache3.mxpie.co.uk
Server_055=cache4.mxpie.co.uk
Server_056=cache5.mxpie.co.uk
Server_057=cache6.mxpie.co.uk
Server_058=cache7.mxpie.co.uk
Server_059=cache8.mxpie.co.uk
Server_060=cache9.mxpie.co.uk

others may find this useful as well?

[Bearded Blunder]

Others may, I'd need to change to 2.08 to use it, and I know there's some reason I don't currently remember that I stuck with 2.06 which is pre frontcode shutdown and therefore doesn't support dropping this in, thanks for suggesting it though.

I'd never recommend anyone to set things up as I have, I probably wouldn't myself if I started from scratch, but I have a system that suits me and no desire to mess with it or reconfigure all my custom right click stuff in a new version of robo.  The result would be whatever drove me to stick with 2.06 on my main box would break or be wrong again and just drive me back.  I use 2.08 on my laptop when I'm away, and that's fine.

There isn't a "problem" here needing to be solved, the old workaround that's been in place for over a decade is just fine for my purposes.