Well since the upstream marked this invalid I'm going to do the same.
Even if I saw a point in this, it would have to be first implemented in
DC++ anyway. So feel free to continue this discussion with them, or at
ADCPortal as Toast suggested.
--RZ
** Changed in: linuxdcpp
Status: New => Invalid
--
Multiple hubs hosted on the same ip:port
https://bugs.launchpad.net/bugs/674536
You received this bug notification because you are a member of LinuxDC++
Team, which is subscribed to LinuxDC++.
Status in Linux 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.
_______________________________________________
Mailing list: https://launchpad.net/~linuxdcpp-team
Post to : [email protected]
Unsubscribe : https://launchpad.net/~linuxdcpp-team
More help : https://help.launchpad.net/ListHelp
