Making WinMX independent

[sIrMoOn]

Well, here's a possible implementation mechanism for WinMX...

Let the dynamic-host chatrooms register themself like this:

My Chatroom@me.no-ip.org_000000001A2B

If the patch could somehow determine what room was being requested each time WinMX tries to open 0.0.0.0, then could do a DNS lookup and connect WinMX to the right host.  Not that much different from how the patch already maps peer cache access attempts to the right host?

[SamSeeSam]

That has kind of defeated the purpose of looking up the dns...
You hvae both ip and dns, why not use ip and forget about the dns? lol

Cheers

[KM]

then you hit channel name length limit, it also looks rather ugly

with your mention of that idea however it did bring up another idea which would solve 2 issues, firstly dynamic IP Addresses and secondly name cloning, although i'm not sure how practical it would be to set up the general idea is:

have a server that channel hosts can (optionally of course) register with, then clients get the list of registered channels from that server (probably update on startup and every 48 hours or so to reduce load, fast updates aren't essential...), that list contains a list along the lines of:
1=My Great Channel=chat.mygreat.com:1234
2=Some Other Channel=room.other.com:4321
etc
when a client sees a listing for "My Great Channel" with any IP/Port it changes the listing to 0.0.0.1:1234, then when the client tries to connect to 0.0.0.1:1234 it does a lookup for chat.mygreat.com and diverts the connection to there

that would prevent name cloning issues as if someone else listed the channel name it would still go to you anyway, and for users who didn't have support for that feature it would still work just as before (with them still receiving the same listings) and would need no changes to the servers (and would also not have issues such as listing a room that doesn't exist any more or worrying about keeping user counts updated etc)

however it would mean some form of central database of channels registered to use the feature, and that of course opens a whole load of issues with regards to someone trying to register someone elses channel name... so it's probably not a viable option

[sIrMoOn]

For any type of DNS scheme to work, while still keeping the channel ability decentralized, the @ would be essential - there can be no "authority" for channelnames other than the server itself.  This is the same way email works and the same way Jabber IM works - i don't register my name "sirmoon", i give my address + authority as "sirmoon@someserver.com".  So if we're unable to accept adding a server name to the name of a chatroom, then we might as well give up the DNS idea altogether.  I'm not convinced it's such a terrible idea to use the same @ syntax for invoking DNS as pretty much every other system that uses DNS; I don't buy the "ugly" argument.  I do see a minor annoyance in that sorting the list by name might be less effective, as the important part of the chatroom name would probably be after the @.  For example, I host a room called "Anime Root Town"; under this system I'd probably call it "chat@AnimeRootTown.com_000000001A1A" or more likely (to keep it with the other anime rooms) "Anime@AnimeRootTown.com" or some such.  So you do have the issues of redundancy or less effective sorting.  It's not perfect.  But hell, if you don't like it, you could always just call it "AnimeRootTown_ABCDEF012345" like you can now.  The only reason I could see for not doing this would be if you thought that a better solution to the problem might come up - but do you think we can really solve it better than SMTP and Jabber did?

Channels could even have seemless redundancy through round-robin DNS and load sharing, but of course that kind of stuff is going to be way above most if not all of the network (certainly you won't get that from no-ip) and probably many of the chat server programmers as well.  It'd be great if we could somehow make that type of feature more accessible, but I'm not sure yet how we could.

[KM]

and I'm sure homer introduces himself as "hi, my name is Homer Simpson@123 Evergreen Terrace, Springfield" - after all names are useless and people should use addresses...

the channel name is just that it is a name not a URL, what good is a URL? people want the name of something not the URL, that's why search engines list the title of a page as the big bold text on the result and not the URL with little text below it saying the name

if you give a channel a URL instead of a name, people will still want a name next to it, and will preferably want the URL completely hidden... the fact winmx shows the hash on the end of the name is not ideal but at least it's out of the way on the end as an apparent short cryptic number/letter combination that they can easily ignore

of course shoving it on the end of the topic in some form (for example if it ends in "[validhostname]" then take that as the rooms hostname) might work, but people are already complaining about topic lengths, heh (and compatible clients could hide it from the list, and it doesn't need to be included on the topic sent when you join for compatible servers)

but any implementation like that would be problematic at best so is extremely unlikely to happen

the only way it could be done well is by modifications to the channel name, and those modifications couldn't add any extra information to the name because 1. the channel name is already limited enough, and 2. users simply don't want a URL they want a name, which is the entire reason channels give a name instead of just it listing IP Addresses hosting rooms for you to search through

[sIrMoOn]

Even in real life, if Homer wants you to come visit his room/apartment/house, he sure does give out his address.  It'd be foolish of him to assume you knew where it was.

I don't understand the argument that this will be a problem with users - they can all use email can't they?

And if anything, the use of DNS would help _prevent_ spoofing.  Because right now you can give a channel the same way as another, and the only distinguishing factor is the numbers at the end - which most of the users don't understand, and which those of us who do understand probably don't remember, and which are apt to change anyway.  But if the name is associated with a DNS registration, it can't be spoofed like that.  You can't list a channel @WinMXWorld.com without it actually _being_ on a WinMXWorld server.  Right?

URL's are a bit different in that there is a lot of extra complicating information - the protocol, colon, slashes, paths.  This isn't nearly that complicated.  And again, users handle this type of name everyday when they use email.

As far as the name length limitation, the whole point of DNS is that the address is a _name_ not a bunch of numbers.  So logically it's part of the name of the room, can be used in a descriptive fashion, and just generally isn't the huge drag you're making it out to be.

[sIrMoOn]

If it's "ugly" KM have your server send a "channel renamed" packet when the user enters the room so the hostname is removed from the window title.  But ideally you'll give chat hosts the choice of whether to do that or not, since as I said the server is likely to be part of the chatroom's name and thus important.

[GhostShip]

Has it not occured to you sIrMoOn that many users like the apparent anonimity that the current system can provide, some rooms thrive on being pseudo anonymous, allowing the users of such rooms to be content to utter the words they choose without fear of public denouncement.

I most certainly do not use email, why ?  Perhaps after the first few thousand junk mails it becomes less of a useful tool, thats something else your likely to have to address should such a system be implemented.

All the above withstanding, using the methods decribed so far I forsee a immediate decline of the decentralised properties of the current system.

What the system really needs is an update to the current search mechanisms and a method to provide folks with a selectable persistant hotlist, many have asked for this feature and I,m sure its within the realms of the possible.

[sIrMoOn]

Has it not occured to you sIrMoOn that many users like the apparent anonimity that the current system can provide, some rooms thrive on being pseudo anonymous, allowing the users of such rooms to be content to utter the words they choose without fear of public denouncement.

You can still host a web site at http://23.1.3.32/, and you can still host a room at My Room_123456789090.  DNS is an optional service, not a commandment to overhaul your life.

I most certainly do not use email, why ?  Perhaps after the first few thousand junk mails it becomes less of a useful tool, thats something else your likely to have to address should such a system be implemented.

That's an odd argument to make - spam is largely a product of the pseudo-anonymity you're afraid of losing.  If anything, you might expect spam to decrease - but I imagine it's more likely it'll stay the same, and hosts will continue dealing with it as they do now.

All the above withstanding, using the methods decribed so far I forsee a immediate decline of the decentralised properties of the current system.

I don't.  Rooms will be as decentralized as ever.  Are you decrying the centralized addressing mechanism?  Surely you know that the IP addresses we use are equally centralized?  Or do you think you can just make up your own IP address?

What the system really needs is an update to the current search mechanisms and a method to provide folks with a selectable persistant hotlist, many have asked for this feature and I,m sure its within the realms of the possible.

Agreed and agreed - which brings us back to my original posts.  Are there any plans to attempt to improve WinMX beyond the current peer cache and fake-filtering mechanisms?

[Bearded Blunder]

Undoubtedly there are plans for improvements, not that they're particularly easy without the source for winmx..
so far as i'm aware they don't include such ornamentation as addressing rooms via dns, which would be useful to only a FEW hosts.. & the default DNS hostname given by the majority of ISPs is not only just as dynamic as the IP addresses they give out.. but also TOO LONG to fit in the roomname length limits imposed by the chat protocol, EVEN WITHOUT adding a recognisable roomname to it.. try to add even a SHORT no-ip hostname along with the std room hash & you'll struggle to name your chatroom anything longer than "CHT_host.name.no-ip.org_123456781234"

Most hosts i encounter have sufficient difficulty forwarding a port for their chatserver & the transient nature of uPnP forwarding makes it unsuited to room hosting.. i hope you aren't suggesting these hosts should also have to jump through the hoops of setting up accounts with the likes of no-ip in addition to the task of getting a room set up? as well as naming their room "Fred" because nothing longer will fit...

[sIrMoOn]

I already have a hostname.  WinMXWorld already has a hostname.  I imagine that there are others.  And I imagine that there are some who'd sign up to no-ip, too.

You make the same point about length that KM made, so I'll repeat my answer:  the hostname is _part_ of the name.  That's the whole point of DNS.  Actually, come to think of it, it may be useful to allow hosts to omit the @ and everything before it and just use the hostname, if they want.  That's more the way I see this being used.  If Billy Bob hosts "Billy Bob's Wonderful Chatroom", they're not going to register aweg23652l3asefasdf.no-ip.org; they're going to register BillyBobsWonderfulChatroom.no-ip.org.  So screw what I said about the @ - just call the room Billy Bob's Wonderful Chatroom.no-ip.org_000000001A2B.  When WinMX tries to connect to 0.0.0.0, strip all the characters that aren't allowed in DNS and do a name lookup.  The @ seemed like a good idea at the time, but on second thought the problem of email is a bit different - every chat host is likely to register their own name, with only one chatroom, so might as well just use that.  If they want to host another, they can use a sub-domain.

[Bearded Blunder]

i could see clients being built with the ability to do a dns lookup if supplied with Roomname_hostname:port in the same way that Roomname_IP:Port is currently converted to a room hash, & this *may* be useful for favourites in some situations, however in many others there's little advantage, for instance typically when the hash of my room changes it's typically because i'm hosting temporarily on a LAN workstation to accomodate rebooting for updates.. in this situation the client would still need to get the hash from channel listing as it's the port that changes....

easy enough to incoporate into a chat client, but you can't make it list that way, not least because you need to preserve compatibility with existing chat clients which can't do the dns lookup & even those would still need the port specified..

[bughunter]

easy enough to incoporate into a chat client, but you can't make it list that way, not least because you need to preserve compatibility with existing chat clients which can't do the dns lookup & even those would still need the port specified

thats always going to be the problem making anything compatable with existing clients.............
since theres no way to force people to upgrade to the latest any improvements have to try and incorporate whats already around.........im sure theres some clever programmer out there who can make it work, i just see a migrain for the poor soul who takes this on.............

[ale5000]

What about using a system like gnutella/ gnutella2/ mute use.  a gwebcache like cache.

I have just read this thread and I think it wouldn't be too hard to use GWebCaches for WinMX.

I'm the developer of Skulls! Multi-Network WebCache, it is just born multi-network, it just need one line of code to enable a new network and the clients just need to follow the specs.
It support all specs but I suggest GWC specification 2.1 currently.
It support both http and https (who host the GWC must choose) and include also an IP blocklist so hosts are filtered.

[GhostShip]

We already have cache software Ale5000, the post you are replying to is very old and we worked our way past the bottlenecks of the time, we did look at gnutella based caches as a starting point but due to the key differences still utilised by WinMx in its connection routines that are hardcoded into it it has to be specific to the WinMx client and thus the cache software would require a serious rewrite, little point in undertaking this until we know where the community is headed in terms of the wider network problems we are facing at the moment.

[ale5000]

Ok but since I'm already into updating the GWC I can make every type of change, since I'm the only developer of Skulls I can make every change that I want in a short time (well it depend by my free time).
The GWC already store things like uptime, connected peers, maximum peers for every host if provided, it basically can do anything you want.

If you need something specific just ask, also if the WinMX won't use it, it still may be a good idea for other networks or for a future WinMX alternative client.
So if it is needed in the future it is already ready.

[GhostShip]

I agree with most of what you have posted and its great to see some positive folks here for a change, I'll converse with you further in PM and perhaps we can add WPN compatibility 

[White Stripes]

can we have a link to this 'Skulls' program plz?

[ale5000]

The forum do not allow me to post links but it is on sourceforge => Skulls! Multi-Network WebCache

[wonderer]

skulls
https://www.openhub.net/p/skulls
http://sourceforge.net/projects/skulls/

another Multi-Network WebCache

http://sourceforge.net/projects/beaconcache/

both php