gfxgfx
 
Please login or register.

Login with username, password and session length
 
gfx gfx
gfx
75899 Posts in 13326 Topics by 2670 Members - Latest Member: pierced3x September 22, 2019, 01:10:19 pm
*
gfx*gfx
gfx
WinMX World :: Forum  |  WinMX Help  |  Upload/Download Issues  |  Post reply ( Re: Waiting for network reply for 97% of files queued )
gfx
gfxgfx
 

Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.
Name:
Email:
Subject:
Message icon:

Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
What year is it next year?:
What's the name of the site this forum belongs to?:
What program is this site about?:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: wonderer
« on: February 19, 2019, 03:47:49 am »

@white stripes, with strong I meant strong in population, not many of of the networks have a steady  base like WinMx.
Posted by: Will
« on: February 17, 2019, 11:31:35 pm »

It's a peice of software described previously that's being worked on by someone for a little fun and experience. I'm sure they will release more information when they feel ready to, but for now I think it's being kept private as it's a personal project.
Posted by: White Stripes
« on: February 17, 2019, 06:53:17 am »

.....well.... what is this new software of which you speak?
Posted by: Will
« on: February 12, 2019, 11:26:06 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.

In any client I would make my intention would be for it to be decentralised as much as possible. There would not be a network for instance. Instead there would be a server browser. You could point the client to a local file or a website which lists "rooms" and then you connect into those rooms. Some may require passwords to enter from the room operator. The rooms themselves would act like a server, everyone inside the room can see everyone else inside the room, browse them, search for files etc - Just like DC++.

So there would be no network to take down. Only individual rooms. But you could host a room behind a VPN acting as a reverse proxy as it can run on any port number, providing some protection. As for the chat itself I'm thinking highly customisable, colour codes, clickable links, protocol for "xyz is typing", in-line media (for example when someone posts an image into chat it would show it in-chat if the user wants it like that).

I would probably make the chat use a WebUI view so that messages are rendered using a XHTML type window. Raw messages sent between users won't be HTML, they'll just be normal basic text but the client will "beautify it" and this will allow CSS files to be used by client side users to customise how their chat looks visually. This is an idea I did not come up with, it's from Textual, an IRC client which already does this and is quite robust in its implementation.

A lot to think about, I have a lot of projects and work where I code full time so need to decide what I'm doing and when but I have a lot of ideas. I would be aiming for full cross-platform compatibility with Windows, MacOS and Linux from the get go but not by utilising any lousy frameworks, I don't want to use C# or Java etc - Something more native and that is preformative.

I've seen early builds of a piece of software similar to what you describe, it appears to be built using vue-electron and has most of the chat functionality (including the typing) already implemented. There's basic file search functionality, you can choose which color "theme" to use and it even has light/dark modes.  There's clearly some work that still to be done but it looks quite promising at the moment from what I've seen.
Posted by: Pri
« on: February 12, 2019, 08:03:06 am »

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.

In any client I would make my intention would be for it to be decentralised as much as possible. There would not be a network for instance. Instead there would be a server browser. You could point the client to a local file or a website which lists "rooms" and then you connect into those rooms. Some may require passwords to enter from the room operator. The rooms themselves would act like a server, everyone inside the room can see everyone else inside the room, browse them, search for files etc - Just like DC++.

So there would be no network to take down. Only individual rooms. But you could host a room behind a VPN acting as a reverse proxy as it can run on any port number, providing some protection. As for the chat itself I'm thinking highly customisable, colour codes, clickable links, protocol for "xyz is typing", in-line media (for example when someone posts an image into chat it would show it in-chat if the user wants it like that).

I would probably make the chat use a WebUI view so that messages are rendered using a XHTML type window. Raw messages sent between users won't be HTML, they'll just be normal basic text but the client will "beautify it" and this will allow CSS files to be used by client side users to customise how their chat looks visually. This is an idea I did not come up with, it's from Textual, an IRC client which already does this and is quite robust in its implementation.

A lot to think about, I have a lot of projects and work where I code full time so need to decide what I'm doing and when but I have a lot of ideas. I would be aiming for full cross-platform compatibility with Windows, MacOS and Linux from the get go but not by utilising any lousy frameworks, I don't want to use C# or Java etc - Something more native and that is preformative.
Posted by: White Stripes
« on: February 12, 2019, 07:54:50 am »

ok, so then another dll injection... modify the client on startup like the community patch does....
Posted by: GhostShip
« on: February 12, 2019, 06:26:19 am »

Of course its possible to undertake such editing however then that introduces another problem, distribution.

Once the files been modified the original author can proceed with legal action if he chooses and there are no resources available to settle any such claim so if that avenue was taken it would lead to the usage of a "rogue" copy passed around the community illicitly with the danger that presents in terms of being able to ensure folks are not being misled into introducing backdoors or malware into their machines.

For the reasons stated above I would suggest no one takes such activity seriously, I understand the frustration but we have to accept our limitations whilst still using the original client.



Posted by: White Stripes
« 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....
Posted by: GhostShip
« 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.
Posted by: Pri
« on: February 11, 2019, 08:02:37 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.
Posted by: GhostShip
« 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.



Posted by: 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..
Posted by: GhostShip
« 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.
Posted by: Pri
« on: February 10, 2019, 03:07:13 pm »

...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).
Posted by: GhostShip
« 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.

gfxgfx
gfx
©2005-2019 WinMXWorld.com. All rights reserved.
SMF 2.0.15 | SMF © 2017, Simple Machines
Page created in 0.066 seconds with 17 queries.
Helios Multi © Bloc
gfx
Powered by MySQL Powered by PHP Valid XHTML 1.0! Valid CSS!