Multiple hubs hosted on the same ip:port

[burek 0]

Hi again,

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):

Host: www.example.com

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.

[Guest Toast]

This post is awfully wasted at this forum cause this is not that much of a techical forum for direct connect development

[burek 0]

?

well, ok.. my bad, I shouldn't have suggest this idea to you anyway.. so many times I've seen negative replies here, I'm really starting to doubt if you are even interested in making progress or you are scared to break things that work so far or you just don't know how to implement something.. I dunno and personally I don't care anymore..

I've being recommended apexdc++ for so long, but I think I'm not gonna do it anymore.. There are a lot of other dc++ developers, making effort to actually improve some things in dc world in contrast of apex..

Anyway, you can delete that post of mine.

cheers

[Guest Toast]

well if you just wanna piss away any future interest in anything you post go ahead and keep on giving ****ty comments the matter of fact is that all the major/minor developers are apart of the dc++ team we all share the mutual goal of improving direct connect but we are not all here and not on the bug tracker where you posted your next message (go figure). If you was apart of the direct connect community or had any real interest you would know from reading all the post on various places that for development issues such as protocol changes or ideas for enhancement whether it be hub or client adcportal is the official place of dcdev not apex forum nor the dcpp bugtracker.

again not my fault that your not that in-tuned with development on direct connect but your sure giving me **** for your ignorance thats for sure.

there was even a blog post on the official blog for dc++ about adcportal being the official forum

https://dcpp.wordpress.com/2009/08/31/adcportal-the-frontpage-for-advanced-direct-connect/

[Lee 84]

again not my fault that your not that in-tuned with development on direct connect but your sure giving me **** for your ignorance thats for sure.

Yeah, it's not his fault. But as the owner of ADCPortal, you should send people to it rather than scare them off. That attitude of yours does not help any of us - why not just forward them on politely to ADCPortal? That blog post was made 31/08/2009, you can't expect everyone to have read it and understand where to go for suggestions.

burek: interesting post but I would recommend posting it over at ADCPortal if Toast hasn't annoyed you too much.

[burek 0]

well, the reason i've posted it here is because i prefer apexdc++ client because of the range of its features, in contrast to other dc++ derivatives.. but the toast replied the way he replied, not helping at all nor showing any interest, which actually pissed me off.. also this topic doesn't have anything to do with nmdc/adc protocol at all.. it is a very low approach (on IP level) and that's the 2nd thing that annoyed me..

anyway, no offence, but toast .. if users of your dc client care enough to come here and offer you a nice new feature, which should help all of us, especially your dc client, the least you could do is to show some interest in it or politely deny that feature, explaining why it is not the good choice.. you could also just post the topic in the right place and give me the link to further follow the conversation.. after all i'm giving you a suggestion and its up to you if you need it or not.. and judging by your reaction i figured you're not interested at all in such a feature, which i really couldn't understand, since so many hub hosters are eager to have something like this..

lee, thanks for your comment, i'll calm down and post this on adcportal.. after all, we all need this, not just me..

P.S.

I need to add one more thing.. I went to adc portal, just to register, and copy this topic, but what I've encountered

"Confirmation of registration

Which of these are ADC compatible DC clients

Please drag the options with the mouse to the correct list, to avoid automated registrations."

I'll just say lol at this and stop trying to please all your wishes.. I gave you the idea, if you need it, go ahead, implement that single setsockopt() and make us all happy. If you don't want, I really don't care.

Also, toast, i'll reply to you here instead of bugtrack:

"Well if you took the time to actually read more of the post you would see that not all developers are here and if you really wanna reach out to em instead of trying to pick a fight with me you could clearly see that we are working on something simular at adcportal called failover but if you dont wanna reg and talk to the devs im totally fine with that.."

I had good intentions, but I don't have time to play games, just to be able to "really reach out to" you, developers, as some kind of ultimate gods or such sh.t, i don't need that in my life, i've got better things to do.

Cheers.

Edited November 13, 2010 by burek

[Guest Toast]

I need to add one more thing.. I went to adc portal, just to register, and copy this topic, but what I've encountered

"Confirmation of registration

Which of these are ADC compatible DC clients

Please drag the options with the mouse to the correct list, to avoid automated registrations."

Whats so hard about that captcha ? simple yet good to keep spambots out of the forum. (btw that captcha was crise choice he also made that question since he is the webmaster of adcportal)

I'll just say lol at this and stop trying to please all your wishes.. I gave you the idea, if you need it, go ahead, implement that single setsockopt() and make us all happy. If you don't want, I really don't care.

Again with the attitude this does not help you futher your proposals.

Also, toast, i'll reply to you here instead of bugtrack:

I had good intentions, but I don't have time to play games, just to be able to "really reach out to" you, developers, as some kind of ultimate gods or such sh.t, i don't need that in my life, i've got better things to do.

you dont play games the first thing you did when i told you the post was wasted here was to insult me, with comments like i hope your not the only dev etc. so you picked a fight and now your trying to take the high road.. sure proposals are always welcomed but in the proper content and place.

and no we are not above status of anyone else but the community thinks that everything should go according to thier plans without prior knowledge of whats happening on the development side.

1. no more nmdc extensions (period).

2. keep updated with our blog about new ideas and features (we dont post there for fun).

3. propose protocol stuff where it belongs same goes for clients and hubs.

4. if we tell you this is not a suitable place to reach out to developers dont be pissy or go for rude comments.

we wanna help but ppl tend to forget that we have alot of others things around development so we cant be on 1000 sites to get every little idea thats out there thats why we created adcportal to have a collected site for ideas.

[OCTAGRAM 0]

Whats so hard about that captcha ? simple yet good to keep spambots out of the forum. (btw that captcha was crise choice he also made that question since he is the webmaster of adcportal)

Well, I can tell the difference between MediaInfo implementations in Shareaza, GreyLink and FlyLink. Shareaza has pretty full metainformation gathered in a single file. This allows browsing filelist as either folder hierarchy or medialibrary grouped by artist and album; season and episode and so on. GreyLink doesn't build such file, but it is possible to send a query for a single file. FlyLink includes metainformation into filelist, but this metainformation only tells about audio and video quality. E. g. no artist name. I can tell which clients support .dcls metafiles (sublists) in which way. Historically, the first evidence was IceDC++ that has sublists named ".DcLst". GreyLink (being the most advanced in many ways) names sublists as ".dcls". It looks like independent implementation, so .dcls was chosen independently. GreyLink supports recursive sublists. Recursive sublist has a metafile virtually put in the directory it describes. This is not important when someone uploads a metafile to a website, because metafile remains available on a website. However, it makes big sense when metafile and the directory it describes are being spread via magnet link to metafile. Availability of the small metafile becomes vital to downloading the virtual directory it describes. Finally, FlyLink developers were forced to implement dcls because users demanded. However, in order to be distinguished (they knew for sure that GreyLink uses .dcls) or maybe they have a wisdom overflow (не знаю, как по–английски «от большого ума»), either way FlyLink uses .DcLst.

I can tell for another features of modern DC++ clones. But the ones listed in this question are often I've never heard of, and I've never seen non-ADC-compatible DC++ clone. .PDC++? What is this? Never heard of. iDC++? What's the hell is this? Never heard of. Why are we talking about ADC support in 2011? It's a checkpoint that was passed long ago.