linuxdcpp-team team mailing list archive

[Toast <674530@xxxxxxxxxxxxxxxxxx>]

How is being rude gonna help you in any case ? it isnt my fault that you
dont know where to post your messages. told you where you should post
and if that doesn't suite you then dont propose anything but dont troll
the tracker with idiot comments..

-- 
Multiple hubs hosted on the same ip:port
https://bugs.launchpad.net/bugs/674530
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.

Status in DC++: Invalid

Bug description:
Hi,

(this is a feature request)

Yeah I know, most of you are wondering right now am I such a n00b or a crazy one, for mentioning something that "just can't be done" :) For those of you who have a patience to read this message, I think it will be worth of your time spent reading it.

Let's begin. Apache web server hosts multiple domains (hostnames or just hosts) on a single ip address with the same port (80) for all domains. Now, in DC world, we have a problem. When a hub owner wants to get his hub hosted on some server, a hub hoster (server owner) asks the hub owner what is the port of his hub, so he can see if that port is available on his server, to host that hub. If the port is already occupied by some other hub, too bad.

Now, I think I've found solution for this. Let's first see how apache server does this. Let's suppose we have a domain named 'www.example.com' and the ip of the hosting server is '1.2.3.4', and web port is 80. When we open up the browser and type in the address 'www.example.com', our browser quickly finds (using dns) that the ip address assigned to that domain is '1.2.3.4' and opens a tcp connection to 1.2.3.4:80. After the browser connects to the web server, it sends a HTTP request, that also contains something like this (in the header):

[code]Host: www.example.com[/code]

That line helps web server to understand what website (of all those websites hosted on that server) should be fetched and displayed to our browser.

Now, many of you believe this is impossible with dc, simply because of the fact that, once the tcp connection is established with the server, the only way to "switch" the connection to the correct hub is to redirect a user (using NMDC command) to the correct hub. But let's see a different approach on this.

I'll suppose you are familiar with NAT and port forwarding. Shortly, on all major Operating Systems, programs exist that can reroute an incoming connection request (aimed at some port) to another ip:port or just to another port. For example, you could forward your local port 120 to your web server port 80 and that way all tcp connections to your ip at port 120 would also be replied by your web server, even though it is not directly listening on port 120.

The idea is (maybe not so) simple. Let's assume hub hosting machine hosts several hubs at ports 1234, 1235, 1236.. Also, let's assume that port 411 (the default dc server's port) has got port forwarding rules, that redirect traffic from the internet, aimed at the port 411 to the correct local port (1234, 1235, ...). Then, DC++ clients would all connect to the default port 411, for all localy hosted hubs, not even knowing that those hubs are running on different ports (1234, 1235, ...).

Simple, right? Now, before you start yelling at me asking "how can NAT know which incoming connection to forward to which local port/hub?", let me say for now, there is, relatively easy way to determine this. And it's a low level solution (on IP level), which doesn't require messing around with higher level protocols, like NMDC. So, how does it know how to redirect connections correctly?

First, take a look at http://en.wikipedia.org/wiki/IPv4#Packet_structure
There you can see an IP packet structure layot. Take a look at the offset 160 (IP Options). If you know what this is, you also know that you can implement your own (custom) option, that you need.

Now, let's finish the idea. If we could make DC++ clients send just the first TCP SYN packet (in a 3-way handshake) configured with a new, custom, TCP Option, "hubname" (for example), then we can practically send the hub name we want to connect to, even before the TCP connection has been established. So, our port forwarding utility, can now understand where does it need to port forward this connection (at which local port), using a list of rules that will say what hub is located at what local port. Now, isn't that cool? :)))

Shortly, DC++ clients could send an extra TCP Option, in the first TCP SYN packet only, that contains a hub_hostname (dns hostname), to inform the iptables (or some other NAT tool) how to correctly forward the incoming tcp connection to a local port, where that hub is located. An important thing here is, we didn't break any standards/protocols with this. Older hub hostings, that don't implement such a NAT tool, will still work without problems, not even knowing that some change has occured. And older dc clients that connect to newer hubs, will simply get connected to a default hub, that's on port 411 (because it will not send TCP OPTION in SYN packet and will not get redirected anywhere).

Sorry for the amount of the text written here, but I think it's a very interesting thing, especially because the implementation of this feature takes just the adding of the hub's address into an extra tcp option field, and on the server side, a proper port forwarding tool with custom rules, that's all.

And what we get with this? A single server that hosts many hubs, all of them using the same (default) port 411. Well, isn't that what was needed for so long, so far..?

b.