Author Topic: Waiting for network reply for 97% of files queued (Read 9617 times)

Mike · « **on:** January 24, 2019, 03:49:50 am »

Hi, ive tried using default ports 6699/6257 or 16699/16257 with all combinations of send and recieve on... and unable to send on tcp and udp, and secondary and primary connections and open nap settings. I have all those ports open in my router and the check port sites say the 6699/16699 ports are open but udp ports are never open. Also 97% (guestimate) of uploads will ever start. Any ideas anyone? Tjanks for any help

White Stripes · « **Reply #1 on:** January 24, 2019, 04:04:53 am »

UDP port may look like its not open but if you can get a channel list while connected as primary it is... if only TCP is open you can still use mx on a secondary connection..

i have problems with uploads not starting either, around about 70% of the time, even tho my ports are verified wide open... ...not really sure whats going on lately...

anyone else with problems uploading?

Mike · « **Reply #2 on:** January 24, 2019, 05:37:57 am »

It also seems that i eventually lose a lot of the queued files i do manage to queue

White Stripes · « **Reply #3 on:** January 24, 2019, 06:17:59 am »

if people give up waiting they will disappear from queue

wonderer · « **Reply #4 on:** January 28, 2019, 11:55:18 am »

we may have the upload queue filler active again, sending upload request and then disconnect.?

GhostShip · « **Reply #5 on:** January 28, 2019, 07:38:20 pm »

Have you seen this directly Wonderer ?

wonderer · « **Reply #6 on:** January 29, 2019, 03:36:00 am »

I have no real winmx running but it is something we have seen before, a filled queue and only a few lucky ones that get connected pinging that queue gave many disconnected requests. only way to get some relieve was leach hammer although that is a dragon of a program. set LH for max que of 98 and all other things out of order. don't know if leach hammer will work with our patch though.

White Stripes · « **Reply #7 on:** January 29, 2019, 05:09:38 am »

leechammer isnt really usable if you want to chat at the same time... moni with very lenient settings (blocking only those who dont share) works better at clearing leeches away but doesnt catch bad connections...

wonderer · « **Reply #8 on:** January 30, 2019, 03:48:18 pm »

both leachhammer and mxmoni were taking much resources and not very good to use on a primary connection
you would expect though that these network pirates would be smart enough to have learned that WPN is strong.
Only thing that comes to mind is checking the diverse timeout settings as internet became several times faster in the last 18 years.

White Stripes · « **Reply #9 on:** February 01, 2019, 04:02:38 am »

Quote

both leachhammer and mxmoni were taking much resources and not very good to use on a primary connection

moni doesnt take as much as leechammer so it does 'work' with primary.... add joshes channel rejoiner into the mix and things get really interesting... throw that all on wine on linux and it becomes an exercise of 'keep winmx running' (sometimes up to a month sometimes as little as 2 days)

Quote

to have learned that WPN is strong.

if by population you mean strong ill give you that, as for WPN protocol itself strong... sorry... its far from it...

Quote

Only thing that comes to mind is checking the diverse timeout settings as internet became several times faster in the last 18 years.

several timeout settings need to be able to be set much lower than winmx will allow... pending uploads shouldnt take longer than 10 seconds to start but winmx limits the lower limit to 30 cos of dialup mentality... ...the read and write caches could be better as well... winmx writes fragmented soup to a ntfs drive on windows... ext4 on linux handles that weird behavior much better....

GhostShip · « **Reply #10 on:** February 01, 2019, 01:08:44 pm »

I am aware of many holes and weaknesses in other network protocols and for this one thats getting on to be 15 years old its stood well amongst its peers and many of the supposed weaknesses are not actually protocol weaknesses but instead client side implementational problems, networks like Gnutella are in a worse state than this one is when it comes to garbage and attacks, newer networks are having the opposite problem of attracting users able to comprehend and more importantly trust the network design, many stick to the old favourites simply because they are a known quantity, lets see how things are in another 5 years and what changes we can reflect on in the lay of the land.

We collectively are the network as you know Stripes so whilst its not the newest and the greatest its here and its working, and all yours.

White Stripes · « **Reply #11 on:** February 05, 2019, 06:14:27 am »

its funny you always bring up gnutella when ive never even used it.. i find my way on other networks... winmx becoming less of one due to its constant need for help just running in the background... ...ive switched to using it intermittently... give it a week and it uses 30% of the cpu for no reason...

...give it 5 years that 2gig limit is going to be a pain... the 5000 file browse already is...

GhostShip · « **Reply #12 on:** February 05, 2019, 06:44:47 am »

I didnt target my response to you personally Stripes, I mentioned Gnutella simply because its a large scale network with similar issues as we have had to deal with, I reiterate, what makes this network different is simply the userbase regardless of any client or protocol limitations.

Pri · « **Reply #13 on:** February 10, 2019, 03:07:13 pm »

Quote from: White Stripes on February 05, 2019, 06:14:27 am

...give it 5 years that 2gig limit is going to be a pain... the 5000 file browse already is...

In my channel we already are feeling the effects of both of these limitations. To try and minimise the effects of the 5,000 file limit we have made available a version of WinMX 3.54 where we've modified it to disable the check it performs for already running versions. This enables the use of multiple WinMX clients on one PC without the need of MultiMX (which I think only works with WinMX 3.53) or Virtual Machines.

To get around the 2GB file limit our own servers now automatically multi-rar any file which is over 2GB into exactly 2GB chunks and then shares those. This is fast as we don't compress anything so it's as fast as a normal copy operation. But this isn't really something normal users can easily setup to be automated and it further increases files shared bringing you closer to the 5,000 file limit.

Coming up with these workarounds is a necessity whilst my community is still living on WinMX. I've been thinking about the future though and how to migrate my community away from WinMX to something that affords us the same creative freedom whilst fixing many of the limitations we are facing today.

It's funny a lot of people in my channel would just be happy enough if they could click links and have them open in their web browser. Something some of the third party clients offer but they also want to be able to download files which none of the other clients can do (or if they do its unreliable).

GhostShip · « **Reply #14 on:** February 11, 2019, 06:15:28 am »

The Emule community have a range of accessories including one that allows downloading via the browser after clicking a special link, most of the problems we face as a community are down to apathy and lack of logical thought, we have the power to swap the whole file transport system for another, we have the ability to bypass any file limits, in fact we have a blank page as far as the future goes,what we dont have are volunteers whom want to work towards any future upgrades, we dont even have any folks whom want to learn how or see if theres something they can help with without learning a lot of coding skills, with few offering to undertake any actual help for the whole community we crawl along when with a bigger team we could fly, its a source of constant disappointment to me.

White Stripes · « **Reply #15 on:** February 11, 2019, 01:46:33 pm »

Quote

I've been thinking about the future though and how to migrate my community away from WinMX to something that affords us the same creative freedom whilst fixing many of the limitations we are facing today.

give fopnu another look... the creation of bots is the one thing that still is lacking, but all other features are taken care of including hotlinking files... ...its basically winmx 4.0..

GhostShip · « **Reply #16 on:** February 11, 2019, 02:26:43 pm »

If Fopnu was ready for users to transition over to Stripes I would have already directed the community en-masse towards it, It is not yet ready although a new update could appear anytime that settles some of its undesirable properties.

The core issues remain the lack of any actual communication channel with the developer and a simple explaination of how the network can operate if the fopnu bootstrap server is shut down, if these critical matters can be addressed the direction of this community might change but the silence from the Fopnu folks is rather a sign of an extremely negative response, we cannot build on sand and expect the technical guys to rescue the community again, I wouldnt presume another miracle and neither should anyone else.

Pri · « **Reply #17 on:** February 11, 2019, 08:02:37 pm »

Quote from: White Stripes on February 11, 2019, 01:46:33 pm

Quote
I've been thinking about the future though and how to migrate my community away from WinMX to something that affords us the same creative freedom whilst fixing many of the limitations we are facing today.

give fopnu another look... the creation of bots is the one thing that still is lacking, but all other features are taken care of including hotlinking files... ...its basically winmx 4.0..

I've already dismissed it due to the way the chat functions. It needs to allow Client<->Server instead of just client meshing. Without that, it will never be what I need it to be. Tbh I'm thinking about just making my own P2P client at this point with a heavy focus on open protocols and extensions, it might be time for some completely fresh ideas.

GhostShip · « **Reply #18 on:** February 11, 2019, 09:19:09 pm »

Theres a raft of material on the net for whatever direction you might want to go in in terms of protocols and conceptual material, I do strongly suggest you steer clear of a client-server only model as there could be potential issues if your userbase decides to involve themselves in sharing copyrighted material.

Other cool mechanisms are "block selection" instead of actual file transfers, three layer networks to support servers as super-super peers, amd of course neighbour peer traffic routing to ensure an actual fileholder is never exposed, theres plenty to investigate thats out there in the open just waiting to be combined into a serious platform.

White Stripes · « **Reply #19 on:** February 12, 2019, 06:05:02 am »

Quote

amd of course neighbour peer traffic routing to ensure an actual fileholder is never exposed,

file sharing networks that do this, while on paper seem a good idea, really arent .. the person 'in the middle' of a file transfer can be targeted as the one doing the actual sharing of that file...

is there no way to just hack out the part of winmx that wont allow browse beyond 5000? i know the protocol is going to limit files to 4gig if it were actually set free but limiting the amount of files browse-able doesnt seem like it would break anything .... just take longer to get the list...

winmx has an entry for users on 14.4K modems so i know -why- its limited but in todays internet such isnt needed.... .....the timeout values could use some hacking as well....

Author Topic: Waiting for network reply for 97% of files queued (Read 9617 times)

Mike

Mike