Hub Feature: Passive Hub Connect

Archived discussion about features (predating the use of Bugzilla as a bug and feature tracker)

Moderator: Moderators

Locked
Moch
Posts: 71
Joined: 2003-03-21 22:29

Hub Feature: Passive Hub Connect

Post by Moch » 2003-04-03 13:35

I know this feature sounds 'weird' but I think it would be a good idea.....

I'll explain the feature first then give the good reasons later (for those who read only the first few lines of a message).

The Feature: Have the hubs act as a 'web server' on port 80 or maybe even port 8080. If someone can not connect to the default hub port then they can simply make some sort of request on port 80 on the server. The request would contain a port number that is open on the client side that is accepting hub initiated sessions. Once the hub receives the request on port 80 it connects TO the client. The client would accept the hub connection and from there the protocol stays the same.

I really think this is feasiable (even if I can't spell). The hubs passive request port can even be added to the hub lists in one of those spared delimited spots.

I know we can't change all the hubs out there... but perhaps at least DCH++ can support it.

Now the reasons why:

As everyone knows ISP's just love to block them common hub ports. (412 and sometimes 411 and maybe some others).

Up to now the only real ways to get around that is to be fortunate enough to have access to a Sock proxy, or find a hub that doesn't use those ports (and in rare instances know a tunnel that the hub admin has setup).

Making a way for the hub to initiate the connection to the client is A. simple and B. can get us around this simple form of port blocking.

Let me know what you think!
~Moch

slurm
Posts: 8
Joined: 2003-04-01 17:56

Post by slurm » 2003-04-03 14:05

I don't know whether your idea is technically possible, but even if it is there's another solution: different port number. It is all up to hub owners though, so if they want to allow users whose ISP is blocking 411 or 412 they move a hub to another port - it's more simple than setting up such 'web server'.

Moch
Posts: 71
Joined: 2003-03-21 22:29

Post by Moch » 2003-04-03 14:25

I just used the words 'web server' because ISP's don't block port 80 (at least not many :wink: )

What I suggest is definetly possible, and it is quite easy to do too. At least in C it is easy to do.. and if it is easy to do in C and it has to do with sockets... well I am sure it is easier to do with almost any other commonly used language out there today.

Thanks for your input slurm!
~Moch

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-04-03 20:44

Some hub servers may already be running both a web server and a web cache. :twisted:

Now, you obviously need a standard port to have the hub software also listen on, what's to prevent ISPs from blocking that as well, unless you pick a port used for something else, in which case you might have collisions between services?

Moch
Posts: 71
Joined: 2003-03-21 22:29

Post by Moch » 2003-04-03 21:06

NACK! *L* It looks like you didn't read all of my post.
The point is the port SHOULD be set that would normally be a diffrent service. I explained (I thought so anyway *L*) that a hub would be able to choose the passive port. The clients would know the passive port for the hub by the hublist, which has many spare (reserved for future use) data segmants (you know the server attributes are a | delimited list). The hubs would just report this port to the hublist, and anyone getting the hublist knows what port is configured to be the "passive" port on the hub.

It seems to be straight forward to me. Yes, it would require the hub software, the hub list software, and the clients to be modified, but only slightly. Also, the way things are setup with the DC protocol if any of the three programs don't support it then, yes it won't work but it shouldn't break anything either.. That is what happens to new features, they have growing pains being implemented.. but if it is a good feature (and I think this one is) it would gain acceptance and be programmed into more clients/hubs/lists.

Thanks for your response GargoyleMT, but I really do think I answered your questions in my first post, I just reinstated the answers here, in hopes it will make it clearer if I was too ambiguous before.

~Moch

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Post by sarf » 2003-04-07 11:35

This is a possible solution to the problem. It requires the modification of hub software, the software that interprets the hublist and the software that connects to a hub.

By using "port tunneling" on the server that the hub is run on (so that connecting to, say, port 80 or 21 gets your data forwarded to the hub at port 411 automatically) you need to modify one thing : the computer that the hub is run on (or rather, you need to run another program on it, if the hub software does not support it).

I prefer the solution that means the least amount of work for all involved, especially since there is relatively little gain compared to the additional amount of work. Besides, if hub owners can't get worked up enough to get port-bouncing up and running, they probably don't want my share anyhow. :)

I would appreciate some sort of built-in port forwarding in DCH++, though (off by default) so that the hub owners wouldn't have to do something really advanced, like using bouncer or, Eris forbid, RINETD.

Sorry, I had to get that out of my system. Rant not directed against Moch or arnetheduck (or anyone except those evil, lazy hub operators out there! :) ).

Sarf
---
'Tis an ill wind that blows no minds.

Nazo
Posts: 68
Joined: 2003-04-03 14:35

Post by Nazo » 2003-04-07 15:16

Don't ISPs usually only block lower ports (< 1024)? Perhaps if a higher port were used, it would be less likely to be blocked on most ISPs?

Moch
Posts: 71
Joined: 2003-03-21 22:29

Post by Moch » 2003-04-07 20:33

Sarf, I understand your POV.

I know its a 'bit' of work... but its not alot, just a little in three diffrent places ;) Making things easier for people to use is usally the bulk load of work. However, it is worth it.. there is much faster growth in a system that is easier to use. Look at AOL for example. Ok bad example. Ease of use doesn't mean high quality.. but I think this feature would be a high quality item.

Hehe, hub operators stop being lazy? Why do you think that most of them are operators and the majority of the hubs have <20 users? Laziness my friend.. cause so many people want to be operators and, in my opinion (which surely can be wrong) not have to share because they are hosting the hub. Ok done with my rant hehe...

Thanks for your response Sarf!
~Moch

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Post by sarf » 2003-04-08 10:30

Moch wrote:[snippity]I know its a 'bit' of work... but its not alot, just a little in three diffrent places ;)
Ah, but this means three places to update/change whenever something merits it. It is not feasible to try to get people to update three things every time something changes (and please, do not try to make the case that if it "was done right" it would never need to change - I know that sooner or later, someone, somewhere will change the way it works :) ).
There is also a problem of abuse - once you can request the hub server to connect to you, you can easily tie up its resources.
Another problem is that the lusers^H^H^H^H^H^H^H less computer-wise users would probably find a way to whine about this ("waaah! why cannt i cnnct to uber-leet hub #23! it says im firewalled! waaaaah! help me NOW dammit!! plz").

So. This feature is not, in my opinion, easy to implement, it is not easy to use (it requires people to know if they're firewalled or not, and as can be seen daily on the boards, they don't, and they definitely do not know what to do about it nor want to do it themselves) and it brings, currently, too little benefit compared to the use of a simple port forwarding proggy.
While coding "for the future" sounds fine on paper, I have converted to the following of the maxim "if you ain't gonna use it, don't do it". If (and, according to some, when) we need this functionality, let us add it then. Until that time... let's make an easy to use Nullsoft Installer that installs a port forwarding program, setting it up to run when the hub runs and to open a specified port to another specified port. Preferably by checking what port the hubs is set up to run at.
If the hub users won't use that, they sure won't be using another, new hub software, learning how it works and setting it up to run with some strange "blocked user port" activated. At least, that's what I think. I may be wrong.

Hope you understand why I consider this a waste of time... that said, just submit a patch to DC++ which supports this and arnetheduck may incorporate it... submit a request to sandos so that he allows hubs to send their "blocked user port" and you have two out of three... then convince the PtokaX gang to implement the "blocked user port" as well as submitting that information to their hub lists, and your idea will become a standard. :)

Sarf
---
"I've realised that users are not just a good way of holding down office furniture which might otherwise blow away." - Daniel Rutter

CarXor
Posts: 11
Joined: 2003-04-07 18:09

Post by CarXor » 2003-04-08 14:04

What you might be forgetting is that most ISP redirect traffic going to destination port 80 to their http cache proxy. And if the traffic does not correspond to the http, then most of ISP cache's will close the connection.

Also, like said, asking a hub to connect to you is a bad choice for many reasons.

So for that to work in all cases, a new protocol should be re-written (dc over http), and even then, the ISP could block the connection by using a cache rule (altought unlikely). Unless the ISP blocks all ports except HTTP, FTP, etc... is far more difficult for them to control at which ports you can't connect.

In conclusion: If you can, change to a ISP that doesn't censure traffic :?

Moch
Posts: 71
Joined: 2003-03-21 22:29

Post by Moch » 2003-04-08 14:18

Sheesh next time I won't use port 80 as an example! Also I will try not to post so much explanation because it doesn't seem like anyone reads it all before they reply *shakes head sadly*

However, as always, thanks for the reply anyway! *L*
~Moch

CarXor
Posts: 11
Joined: 2003-04-07 18:09

Post by CarXor » 2003-04-10 17:44

I don't know, maybe I didn't understood you, but I took the time to re-read your posts and if you didn't meant the http port (or protocol for that mater) then I really can't see any advantage in what you suggest.

What you described is in fact part of the file transfer protocol (FTP):
  • You connect to the server and the server connects back to you to a port you specified.
    Problem: It won't work for users behind firewalls
Also if you cannot connect to the hub default port, why do think you could connect to that other port?

Keep in mind that the hub owner could easily choose another port (like 80 although in that port it might not work because of transparent http caches)

I have read your posts, and I really would like to understand your idea.

Perhaps what you would like is that hub owners install a port converger (every traffic coming to the machine, in any port, goes to the default port)
that way, you could connect to any port in that machine and it would work, but I believe that many would not like to do such configuration.

Moch
Posts: 71
Joined: 2003-03-21 22:29

Post by Moch » 2003-04-10 19:17

The point of saying port 80 was to get the idea across that it should be a port that would not commonly blocked by an ISP, so if it was setup (by the hub administrator) to a port like this not many people would have a problem. I just picked port 80 becasue I couldn't imagine what ISP would block connections to this port. The web caching is a problem, but lets just say that if this was implemented to emulate a connection with a webserver, than shouldn't the cahce not affect outgoing (emulated) post data from the client so the hub would still know how to connect back to the client.

Yes, I am proposing something very similar to what FTP does for passive transfers... That is the same to comparing this to the passive transfers already in the DC protocol though. This is slightly diffrent as in it is a method to tell the hub to connect to you that would hopefully not be an easy thing for an ISP to block.

Yes, it wouldn't work for NAT users that DO NOT know how to configure NAT to forward their ports.

Yes there are no guarantee's that I would be able to connect to any ports at all. I am just trying to think of ways that would make it so more people would have the chance to connect though.

I really liked your suggestion about a "port converger". That is an idea, but not so that the hub manager would have to configure a router or NAT tables to do it.... Instead of my unpopular idea of setting it up as a passive connection request through a port.. what if the hub software would just open 2 or 3 random ports that also accept connections? These ports would have to be reported to the hublist and the clients would have to be able to parse the new hublist (not to mention the hublist software would have to be changed to accept the multiple port list).

I know what someone will say... they will say why not just make the hub open one random port and use the current system? Well.. because there should be one 'default' port for a server to always run on, that way people who are not being blocked on that port can still use the favorites *L*

Well, sorry if I came off sounding a bit harsh, I get kinda grumpy sometimes :D

Thanks for the response CarXor,
~Moch

Locked