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...

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

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.

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 .

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...

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).

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.

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 .

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.

Logged

Blessed is he who expecteth nothing, for he shall not be disappointed.

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.

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.

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.

Logged

Blessed is he who expecteth nothing, for he shall not be disappointed.

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.

Logged

Blessed is he who expecteth nothing, for he shall not be disappointed.