linuxdcpp-team team mailing list archive

[burek <burek021@xxxxxxxxx>]

Public bug reported:

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.

** Affects: linuxdcpp
     Importance: Undecided
         Status: New

-- 
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++: New

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.